18th International Roundtable on Business Survey Frames
Beijing – China - 18 – 22 October 2004
Session No 2
Paper No 3
Nicolaes HEERSCHAP, Statistics Netherlands
Co-ordinating role of the Business Register in Economic Statistics
The role of the Business Register in a changing environment at Statistics Netherlands1
Introduction
Since the beginning of the nineteen nineties Statistics Netherlands (SN) has been in a state of
continuous change. That also accounts for the Division of Business Statistics. The main
reason for this is that the way of producing statistics is not in line anymore with a changing
environment. To adapt to new circumstances, an alternative way of producing statistics is
necessary.
In the context of the Roundtable, the question can be asked if this new way of producing
statistics effects the role of the Central Business Register (BR) of SN?
The outline of this paper is as follows. First the old way of producing (business) statistics and
the reasons to change are described. Then, given the new circumstances, a new way of
producing (business) statistics is proposed, followed by a strategy for the short and medium
term, which is embedded in all day reality. Ending with a discussion whether these new
circumstances effect the role of the BR.
So, this paper does not focus on the structure and maintenance of the BR of SN, but on the
new environment and the related requirements.
Old situation
Until recently the situation of the statistical processes at SN could be described as a pure
product stovepipe model. See Figure 1. Every single product stovepipe corresponded to a
particular theme of related statistics with its own specific production line. All of the
processing from collection to publication took place within the stovepipe. They had their own
customer base and their own data suppliers. In fact they lived in their own small world
supported by their own information systems which were specifically tailor-made. The data
collection was based on own surveys, the use of administrative sources was marginal. At the
end of the chain National Accounts (NA) merged and integrated the results of some of these
product stovepipes, sometimes repeating a part of the stovepipe process in a slightly different
way.
In the beginning of the seventies ideas emerged about the development of a coherent system
of economic statistics. To develop such a system, coordination between the stovepipes was a
prerequisite. Besides unambiguous defined variables and comparable research periods, this
meant setting up a central Business Register (BR) with possibilities of:
1
The views expressed in this paper are those of the author and do not necessarily reflect the policies of Statistics
Netherlands.
1
-
the derivation of unambiguous defined (statistical) units about which data are collected
and
consistent classifications (e.g. size and activity code) and the unambiguous allocation
of the derived units over the classes.
Although a central BR was set up and has become one of the key systems in the production
process of business statistics, a situation of total coordination was never really reached. Most
statistics used the BR as their sampling frame, however, later in the production process some
of them used a copy of this frame (CR in Figure 1), which was updated with frame errors for
their own purposes. Also they often maintained their own database with contact addresses.
Although the classifications of the BR were widely used, with this way of working problems
with coordination only became visible at the end of the production chain, in the integration
process of the NA. Quality and timeliness of updating of the BR were crucial aspects.
Because the BR was only based on institutional units, functional statistics, like trade and
transportation, used and maintained their own register with their specific units.
Figure 1. Product stovepipe model or product view (with no overall coordination)
Product view



Output
CR1
CRx
CR2
CR3
Throughput
Input
S tatistic 1 S tatistic 2 S tatistic 3 S tatistic x
BR
   
Changing environment
If there would be no change in the environment, maybe there would be no need to change the
situation within SN. However this is clearly not the case.
First, there are the changing needs of the customers. As the world becomes more complex and
interrelated, there is an increasing need for integrated and consistent data. Customers also
want data quickly and often new themes emerge, like the new economy, globalisation or
environmental issues. This means that there is a growing need to integrate the data across the
borders of the stovepipes.
Not only have customers become more demanding, but, second, in a changing market SN is
2
loosing its monopoly position in many stovepipe domains. Nowadays individual statistics can
easily, and often more quicker, be produced by other institutions outside SN as well, because
data is mostly electronically available.
Third, there is a strong pressure to reduce the administrative burden of enterprises. The total
administrative costs for enterprises in the Netherlands are estimated at around 17 billion euro
each year. Reducing this burden is a major policy issue of the current government.
Fourth, there is a continuous pressure on SN to reduce staff, but still produce the same or even
more output. This wish for lower costs and more efficiency increases now the government
wants to tighten budgets. This will likely persist in the future, if the trend towards a smaller
government with a smaller budget will continue.
And, finally, there is the pressure from new developments in the information technology and
statistical methodology. As new techniques become available, there is always an urge to
deploy them (push), especially in the case of the strong wish for more efficiency (pull).
All these changes in the environment of SN make the disadvantages of a product stovepipe
model, as a way of producing statistics, increasingly visible.
For example, it is rather difficult to maintain coordination between the different statistics of
the product stovepipes. In fact there is a natural tendency for them to drift apart more and
more. Also, there is no integration of data from different areas and sources. This means that
there is no consistency between the data on, for example, production, trade, investments and
financial aspects of an enterprise. The fact that there is no integration of data often also
implies that different figures are presented about the same phenomenon.
Furthermore, in a product stovepipe model or more broadly within the Dutch government as a
whole the way the information needed is collected is not organised very well. In fact every
organisational unit or stovepipe collects the information on its own and for its own purposes,
approaching an enterprise with the same questions, often with just slightly different
definitions. This makes the survey burden higher then necessary. So, reducing these costs is
not only of interest for the continuing cooperation of Dutch enterprises, but also for SN itself.
Besides the bad image, duplicating activities for every stovepipe on the inputside is also
costly.
And last but not least, a product stovepipe model is not very efficient. Every statistic has its
own way of organising things. The processes and supporting software are often reinvented,
duplicated and tailor-made. This also implies doubling the automation work when developing
and maintaining the systems, therefore the costs are relatively high. The advantages of
economies of scale are not exploited.
So, the feeling that the disadvantages outweigh the advantages of a product stovepipe model
in a changing environment caused a series of reorganisations within SN, starting in the early
1990’s and continuing until the present day. It is very likely that reorganisations will be a
permanent feature of SN in the years to come, as is the case in many other companies and
institutions.
Main corporate strategic goals
In a process of change, organisations usually have a strategy for the long run where they
position themselves in the market place. Besides the mission, main markets and core activities,
this is described in the strategic corporate goals. Through all the last reorganisations, the main
strategic corporate goals of SN have been:
-
to further strengthen the relationship with its main customers. Serving its customers in
3
-
-
-
a better way with useful statistical information is, at the end, crucial for the survival of
SN. As SN is in the unique position to integrate the different sets of data to an
interrelated knowledge base, the extra value added of SN can then be defined as the
integrating crossroad on the information highway. To take advantage of such a
position (new) networks with other organisations and institutions must be developed
and maintained.
reducing the survey burden of enterprises. Besides further coordination between
statistics and questionnaires, this can be realised in two ways:
o to optimise the use of administrative sources, as the replacement of total
surveys or questions in surveys. In line with this, SN should use the general
infrastructures, which are put in place for business-to-government
communication.
o to approach the respondent in its own environment, meaning, for example, (1)
using definitions which are understandable for the respondent and which are
harmonised with business or tax administrations instead of enforcing
definitions of output variables on the respondent or (2) giving the respondent
the option to respond in different ways (a multi-channel approach).
more efficiency by redesigning the current situation towards more standardised
statistical processes with the optimal use of new information technologies and
statistical methodologies (e.g. generic tools and solutions).
and finally, the adaptation of the structure, management and staff to the new situation,
especially when it concerns the mismatch between existing and needed skills.
Figure 2. Old and desired situation
Old situation
E
N
T
E
R
P
R
I
S
E
S
E
N
T
E
R
P
R
I
S
E
S
A
Survey
burden
Unanswered
needs
B
Desired situation
Survey
A
B
burden
Unanswered
needs
C
U
S
T
O
M
E
R
S
C
U
S
T
O
M
E
R
S
Arrow A = size of SN-staff; Arrow B = the effort to translate the input to the desired output.
In pure business terms this means, that a changing environment has pressed SN for better and
quicker output, i.e. statistics, for less input- and process-costs. Less input and process costs
can then be translated to another way of producing statistics with less but more professional
staff (leaner organisation). This implies a higher productivity through increased economies of
4
scale. See Figure 2.
New way of producing statistics, the point on the horizon
The development towards an optimal situation starts from the disadvantages of a product
stovepipe model and follows a more or less natural evolutionary path of improvements.
To satisfy the strategic corporate goals, a first step is to concentrate the separate and
duplicated activities at the input- and outputside of the different stovepipes, as a result of
which:
-
-
one contact centre is set up to approach and answer questions of all respondents of all
stovepipes, also resulting in more coordination of all the data collection. Respondents
are bothered only once.
one output window is set up to answer and coordinate all data-needs of all customers
of all stovepipes. For the dissemination of data through the Internet an improved
customer service is already created through the Internet database of SN, StatLine.
Then - especially for efficiency reasons - there is, as a second step, the tendency to merge
similar production processes, which function now as isolated stovepipes, into as few
standardised production lines as possible, supported by generic (software) tools in every step
of the production chain. If isolated production lines are merged the advantages of economies
of scale can be applied.
From an organisational point of view, the shift from a product stovepipe model to a process
driven model becomes then almost a natural step. Such a process driven model means
separate units for all input activities, all throughput activities and all output activities,
disregarding the product stovepipes. With this the organizational structure of SN was turned
over 90 degrees. See Figure 3.
Figure 3. First steps towards a process driven model

  

One windo w for data dissemination services
Merge
Output
P
R
O
C
E
S
S
Merge
Throughput
V
I
E
W
Merge
Input
Merge
Theme 1
Theme 2
Theme 3
Theme x
One windo w for data-collection services
    
5
In fact, this is the current situation in which the business statistics of SN find themselves at
the moment, although with the annotation that in parts of the organisation the different
product stovepipes are still visible.
If the goal is to strive for as less production lines as possible, the ultimate goal, as a third step,
would then be to have only one single standardised production line for all business statistics.
The core of such a production line would be one central data repository that functions as the
transactional as well as the analytical database.
Such an ‘ideal’ process can be described by the following steps (see Figure 4):
1. One contact centre. All data collection activities are coordinated from one point in the
organisation, also meaning, for example, that respondents are not approached with the
same question twice.
2. Then, all data, registers and surveys, which come in are directly loaded into the central
data repository and connected to the statistical units of the related and coordinated
backbone or population. The coupling takes place on the basis of identifiable keys.
The result of the coupling process is recorded, meaning that at any time the population
coverage can be calculated. At the moment in most cases it is necessary to make a
translation of the data from the observation unit to the statistical unit. So, for smaller
and medium-sized enterprises extra efficiency can be gained by ensuring a one-to-one
relationship between the statistical and the observational unit or the unit used in, for
example, tax registers.
3. All the backbones or populations are made available through the BR, meaning the
delivery of ‘frozen’ frames (monthly, quarterly and yearly).
4. After the data are linked to one of the backbones, a process of checking, editing and
also micro-integration takes place. For this step the frontside of the central data
repository, the transactional database, is used as the core. The processing of all the raw
data cannot be done simultaneously, because the data come from different sources with
different quality and timeliness and they are obtained differently. Therefore, the
processing takes place on the basis of clearly defined datasets or views. This also
coincides with the fact that in the case of micro-integration, it is clear that it will be
impossible to check and edit all available variables against each other.
5. When (parts of) the data are considered to be ‘good enough’, they are copied to the
outputside of the data repository, the data warehouse. Mostly this will be microdata.
The transformation from input to output is recorded by transformation rules for the
variables and units and matching rules in the case of integration.
6. The data warehouse is then the basis for consistent and integrated datamarts of
microdata, aggregates or time-series, which can be made available for the different
expert groups within SN. These expert groups are based on coherent themes, like the
domains of care, production, tourism or agriculture.
7. Expert groups can then use the data in two different ways:
a. (standard) publications or the dissemination of data to the different customers.
This way of using data is strictly controlled, authorized and fixed, thus always
transparent and reproducible. Data confidentiality is a major issue here.
b. information development. This is an internal process, where the statistical
analyst can manipulate the data without limitations. It is his or her
experimental garden. Information development can lead to new statistics.
Finally, the system helps the statistical analyst to translate the outputdata to different
formats, such as the format of the Internet-database of SN (StatLine), the format of
6
Eurostat (GESMES) or formats such as ASCII, XML, SPPS, Excel etc.
All activities in the different steps of the process are supported by standardised and generic
(software) tools, which are contained in centrally maintained libraries (in Figure 4 represented
by the boxes with an ‘L’). These libraries can easily be updated with the newest technologies
and methodologies, often without bothering the users.
Figure 4. An output drive process, supported by a workflow and metadata system
Customers / data-users
Internal analists
One window for all output services
7b
L
Output
7a
Information
development
Output for
customer
Datamarts
Making of datamarts (selection,
aggregation etc.)
6
Transfer data to
Data warehouse
5
L
Throughput
4
2
Input
L
Output driven
process
Checking, editing
and micro-integration
Coupling data
to the backbone(s)
W
O
R
K
F
L
O
W
M
A
N
A
G
E
M
E
N
T
M
E
T
A
D
A
T
A
B
A
Data warehouse
C
K
B
O
N
Transactional dbase E
S
S
Y
S
T
E
M
Knowledge institute
- (integrated) publication
- information development
- customer base
Data production
factory
Data
repository
3
BR
External
SBR
One window for all data-collection
1
All input, primary and secondary
   
Although there is only one standardised production line, that does not mean that all data
follow exactly the same path through the chain. There can be differentiation in the workflow
for different datasets, especially as it concerns the step of checking and editing. In fact, the
data is not routed (it stays in the database), but the activities of the different actors in the
production chain are scheduled. This scheduling must be managed by the deployment of a
central Workflow Management System (WMS), otherwise it becomes too complex.
The central data repository is the core of the imagined single standardised production line,
supporting both transactional as well as analytical processing, however clearly separated from
each other. The data repository has three related dimensions:
-
the coordinated backbones of units (or populations). The statistical units can be, for
example, the enterprise group (financial aspects), the enterprise (production process),
the local unit, a functional unit or a spatial unit. But backbones can also consist of
observational units, including tax- or register-units. There can be relationships
between the different units. For example an enterprise can have more than one local
unit, or, a statistical unit can be derived from more than one observational unit. A
backbone is longitudinal and cumulative in time with periods of validity for all the
units. The maintenance is event-driven. Especially for reasons of coherence and
integration, it is essential that these backbones are coordinated (between statistics).
7
-
These coordinated backbones do not only have a function for the output, but also for
sampling, matching and statistics, that is the demography of enterprises. The
responsibility for the structure and maintenance of these backbones lays with the BR
of SN. However, the compilation of the BR is based on an external business register
(SBR), which has a national scope and is a cooperation of different organisations (e.g.
SN, Camber of commerce, the Tax office and the Social security funds).
the attributes of these units, the variables.
the time dimension.
So, the central data repository will, in principle, store all data from all business-related
registers and surveys at the level of individual enterprises or other (functional) units, although
also aggregates and control information can be added. Backbones and variables are fully
coordinated, standardised, mutually related and documented.
Such a system can only work if it is supported by the deployment of a fully-fledged
metadata-system, which functions as the necessary glue between the different steps in the
production chain.
Finally the process is strongly output-driven. Activities should only be performed when they
serve the production of the information needs.
A process with only one single standardised production line for all business statistics with a
central data repository supported by generic (software) tools and metadata and workflow
management systems has many advantages. The main impacts of such a optimal situation can
be characterised with the notions of increased efficiency (e.g. economies of scale), quality,
flexibility, accessibility and coherence, as well as the implementation of optimal data
collection techniques, the optimal use of all information, full possibilities to produce
integrated statistics, highly standardised and sound documentation. Fully implemented and
managed, at least in principle, this bears an immense efficiency potential. It is a key
component in achieving the strategic goals of SN. It presents a valid business case. Especially
it provides possibilities to reconcile, often opposite, goals, such as a leaner and cheaper
production process and less survey burden on the one side and better and more integrated and
flexible output (customer service) on the other.
Strategy for the short and medium term
The statistical process, which is described above, is an ideal target to aim at for the long run.
We even may actually never reach such an optimal situation, as many statistical and technical
problems still remain to be solved. For example, the step in the beginning of the process
where data are connected to the backbone, checked and edited and where micro-integration
takes place can become very or even too complex. A major problem concerns the process of
flexible and consistent weighting from the total set of microdata to aggregate datamarts.
Although a crucial element of the proposed situation, it is not very easy to get consensus over
how to deal with the metadata, that is: how to set up an infrastructure, what should be part of
this system and what not and how this fits day-to-day reality (e.g. coordination, maintenance /
change management and ownership). At a technical level, there is still little experience with
the building and the maintenance of big data warehouses. Or more general, can the IT and
methodology support the new situation that will serve integration, workflow management,
flexibility and both real-time transaction processing and analysis? Also still questions can be
raised about the controllability (the main reason for the existence of stovepipes) and
vulnerability (complexity and greater dependency on administrative sources) of such a
process.
8
And last but not least, we have to reckon with the existing situation. The investments in and
the results of the reorganisations of the last 10 years must also be taken into account. On the
input and throughput-side redesigning projects have already been underway. At the moment
almost all the production of institutional statistics is already handled through one production
line (the Impect project), limiting the number of stovepipes considerably. Also the processing
of secondary data, such as registers and administrative sources, is already handled for some
years through one production line (the Baseline project). This project is closely linked with
the BR. Recently, some sketchy ideas emerged to further minimise the other still existing
product stovepipes. This especially concerns the functional statistics or statistics which do not
fit into the Impect production line. And, finally, also the BR of SN is under revision. Main
reasons behind this revision are the link with the new external SBR, new information
technology, user friendliness and more transparency (e.g. events) and efficiency.
Taking all these factors into account, for the development towards a new situation a
step-by-step approach was chosen. The described optimal situation is (only) seen as the
guiding light on the horizon. Cathedral building is avoided. For the short and medium term,
the following strategy is set:
-
one centralised BR for (the maintenance of) all backbones (coordination).
one contact centre for all the input (coordination).
as less production lines (stovepipes) as possible.
as much standardisation and generic tools as possible.
one output data warehouse for all business statistics.
the way data is stored in the production lines (transactional database(s)) is geared to
the structure of this data warehouse as much as possible.
optimal use of administrative data. Surveys are additional, preferably carried out
electronically.
and one centralised metadata infrastructure (coordination).
In practice this means, that the ongoing redesigning projects on the input- and throughput-side,
such as Impect, Baseline and the BR-revision, can continue, because they fit the general
strategy. The Business Architecture, which was drawn up recently for the business statistics,
should play the coordinating role, between existing and new projects. Furthermore two key
projects were set up:
-
-
building a first version of the central output data warehouse. This project was
christened the ESB-Basis. For all business statistics this means a central storage,
archive and outputtool, with microdata as the basis.
besides the development of the infrastructure and functionality (e.g. tools), to
concentrate on the real integration of (economic) datasets (content). Not directly in the
beginning of the process, but more at the end (end-integration). The main goal of the
end-integration is not to reach overall consistency (e.g. repeating the work of the
stovepipes in a slightly better way, but slower) or to have only one figure for every
phenomenon, but mainly to produce new statistics which cannot be produced with the
current stovepipes (e.g. productivity, effects of investments on production, effects of
human capital and better time-series). Results and concepts do not have to be
consistent with the results of the stovepipes immediately. This also coincides with the
method of working of an already existing integration frame (Micronoom). It also fits
the wish to optimise the use administrative sources.
Finally, it is important to push for the realisation of a centralised metadata infrastructure that
9
can be used in all the steps of the production chain and, foremost, fit the development of the
output data warehouse. The starting point is the coordinated description of the variables,
classifications and units as well as the methods used.
So, for the medium term, for the business statistics there should be a situation (see Figure 5):
-
-
-
-
with three (or close to three) production lines. One for all institutional statistics
(Impect, already realised). One for all administrative sources, including tax data
(Baseline, already realised). And one (or several) for all other (functional) stovepipes
(sketchy ideas).
where these three production lines deliver clean and authorised data to the output data
warehouse, the ESB-Basis. All dissemination and publication of all business statistics
takes place through the ESB-Basis, which is also the experimental garden for
information development. Integration of datasets is a crucial element in the ESB-Basis,
however this is slowly developed.
where the BR, based on the external SBR, takes care of all backbones, at least the
institutional backbones, meaning that the real coordinating role of the BR is strongly
increased. Besides information about the units, information about the relationships
between the units (longitudinal as well as transversal) becomes more and more
important. Also the backbones for functional statistics should be included or, at least,
they should be stored (one infrastructure) and put available centrally.
with a centralised metadata infrastructure.
Figure 5. Situation for the short and medium term
Customers
ESB-Basis
Publication layer
(incl. statistical disclosure control
Data manipulation layer
Integration layer
Statistical
Backbones
Input layer
Approach registration holders
SBR
Registrations
Determine
Statistical needs
Functional
statistics
Clean (micro) Clean (micro)
data (meta)
data (meta)
Institutional
statistics
(Impect)
(secundair)
Baseline
BR
Clean (micro)
data (meta)
Metasystem
Data repository layer
Process meta system
Information
development
Approach companies
Multi-channel
Enterprises
The (changing) role of the Business Register
Now the main question for the Roundtable is whether the role of the BR will change because
of this new way of producing statistics?
In general, the functions of a BR can be described as:
10
1. determination and derivation of the statistical units and relevant attributes based on
external and internal (administrative) information. The result should be comprehensive
(statistical) backbones which cover and represent the (different) populations. The BR
is the bridge between the external, administrative or observational, units and the
internal statistical units. This is supported by a central system with contact addresses
(CRM).
2. sampling and weighting frame for all business surveys.
3. overall coupling / matching frame (coordination), especially as it accounts for
(micro)-integration of datasets, including administrative sources. In this case the BR
can also function as the central benchmark.
4. enrichment of other sources with data of administrations, for example tax or social
security data.
5. source for economic demography.
6. monitoring system to manage the survey burden of enterprises.
7. information source for analysts and statisticians.
In the old situation the role of the BR at SN was mainly a central sampling and weighting
frame for business statistics, with an institutional approach (functions 1 and 2). Although
some coordination was reached (e.g. classifications), later in the production process some
statistics used a copy of the BR frame, updating it with their own frame errors based on their
own information and slightly changing it for their own purposes. With that the desired
coordination was lost.
Now the number of production lines has decreased, the coordinating role of the BR has
increased. The role of the BR is further increased since the functioning of the Baseline system,
which translates administrative data to statistical data, tax data being the main source. This
system is closely linked to the BR. All functional statistics, like trade and transportation, still
maintain their own registers outside the BR.
Although the BR already has become a key system in the production process of the
institutional business statistics and with that the National Accounts, in the new situation the
role of the BR will be more prominent. Key elements are:
-
-
(outputside) Integration of datasets over the borders of the stovepipes will be
increasingly important for the output of SN. To make integration possible and easier,
two prerequisites are: (1) unambiguous defined variables (metadata) but foremost (2)
unambiguous defined and coordinated backbones of units. In this context, the BR does
not only play a role in the beginning of the process (sampling), but also in the other
steps of the production chain. It also functions as the matching frame between the
different datasets and is the central benchmark. Integration does not only mean that
(the data of) the same units are linked to each other, but also (the data of ) related units,
like an enterprise group and the underlying enterprises or an enterprise and its local
units. A problem can be that there is not too much overlap between economic statistics
and that (smaller) enterprises are not observed every time. A solution lays partly in the
coordination of the observation strategy, that is: the same units are included and
observed in the different surveys.
(outputside) The growing need for consistent time series (longitudinal, dynamics), also
in understanding that the trends reflect real world developments while the effects of
changes in the population can be shown separately. This includes the possibility to
track individual enterprises (e.g. the Top xx enterprises) over time, as well as specified
panels of enterprises, which is important for specific types of longitudinal analyses. It
11
appears that researchers, who use the economic microdata of SN, mostly use this data
for time-series, but, at the same time, they also mention the many problems they
encounter with the continuity of units in the datasets (size class, activity-code, but also
the structuring of enterprises) during their analyses.
- (outputside) Besides integration of datasets, also the regional aspect of statistics is
getting more attention, including the aspect of GIS (Geographical Information
Systems). The BR can play an important role here. A problem is that local units in a
BR are not always maintained very well.
- (inputside) The wish to optimise the use of administrative sources as a replacement for
surveys or questions in surveys will also further increase the role of the BR as the
bridge between administrative units / data and statistical units / data (see also the
Baseline project). The growing use of administrative sources will also increase the role
of the BR as a benchmark.
- (process) The need to include the units and their specific attributes of functional
statistics in the BR, or at least to have only one central infrastructure available by
which information is accessible for everyone in the organisation.
- (process) Quality and timeliness (of the updating) of the BR become more crucial
(quality indicators). It is important for the overall coordination that the construction
and maintenance (updating) of the BR are handled in one place, but also meet the need
of quality and timeliness, often the reasons for the existence of decentralised copies of
the BR.
- (process) In line with the last point, the growing need for more transparency and
reproducibility in the processes of the BR. This includes the need for metadata (e.g.
events) as the output of the BR. The main feature of this approach is that all
information related to an event is registered in a consistent and a complete way. In this
context the dual-time principle can also be mentioned. The dual-time principle means
that two dates are registered in relation to an event, that is (1) the real date when the
event occurred and (2) the date when the event was registered in the BR. If used in a
right way, it is then always reproducible on the basis of which frame or backbone a
certain statistic was made at a certain moment.
Another step forward is the development towards more coordination within the total Dutch
Government and not only within SN. Important drivers are the pressure to reduce the
administrative costs of enterprises, coordination (ask a question only once, one window), the
increasing need to be able to connect different data sources and more efficiency. This has
resulted in the creation of an (external) Single Business Register (SBR), which is a
co-operation between the Chambers of Commerce, SN, the Tax Office and the Social Security
Funds (BBR, Basis BedrijvenRegister). The processing will take place through a central
Governmental Portal (OTP). The pressure for more coordination between governmental
institutions will enlarge the role of the BBR. Besides the BBR, the goal of the government for
the coming years is to set up the following national basic registers:
-
The Central Population Register (GBA, exists).
Central Register of Buildings and Dwelling (in construction).
Central Register of Addresses (in construction).
Central Register of Real Estates (Land Registry Office, exists).
Geographical map of the Netherlands (Land Registry Office, exists).
The ultimate step of course is as BRs are coordinated over the borders of countries, which is
important to provide better possibilities to follow international developments (see the
12
European Business Register, EBR).
A final issue that can be mentioned is the growing need to connect economic data with social
data. In this paper a redesigning process is described for the Division of Business Statistics,
but a similar process is carried out within the Division of Social Statistics. This raises the
question if the BR can be linked with the Central Population Register.
Scheme 1. Old and desired elements of the BR
Old situation
Desired situation

Functions especially as the sampling frame for
surveys of institutional statistics. Foremost, a role at
the beginning of the process.

A crucial role in the coordination of all (business)
statistics. Resulting in unambiguous backbones, which
play a role in all the steps of the production chain.

The updating of the BR is not always to the
satisfaction of users, resulting in the creation of
decentralised BRs (and systems for contact
addresses), which are often a near copy of the BR.

Integration. A matching frame with the necessary
attributes. A benchmark.

Output of information to follow businesses over time
(time series). Not only longitudinal but also transversal
(relationships between units).

Specific attention for (the structure of) the bigger
enterprises (Top xx enterprises). Profiling. Grouping
criteria.

A bridge between administrative and statistical data
(use of secondary information). Enrichment of datasets.

For the compilation the use of external sources,
however coordinated through the external SBR
(leading) with all relevant parties.

Timeliness in the updating of the BR. All frame errors
and updating managed from one point in the
organisation.

The inclusion of the units and attributes of functional
statistics.

Better regional aspects.

Quality:

Coordination on the basis of classifications (size and
activity code), but less on the unambiguous allocation
of the units over the classes.

Overall coordination is not reached.

For the compilation, the use of external sources,
however not coordinated. Processing mainly within
SN.

No output of metadata and quality-indicators.

Units of functional statistics not included. They
maintain their own register.

Not easy to access without specific knowledge.

Basis for economic demography.

System to manage the survey burden.

Quality indicators (e.g. existence
especially for the smaller enterprises)

Comprehensiveness / coverage (e.g. government,
agriculture and enterprises without employees)

Correctness. Valid derivation rules. Accuracy in
the allocation over the classes.
codes,

Reproducible and transparency. So the inclusion and
dissemination of metadata (e.g. events).

Improved accessibility for users (user friendliness).

Basis for economic demography.

System to manage the survey burden.
Conclusions
Developments in the environment have forced SN, in this case the Division of Business
Statistics, to change its way of producing statistics and thereby to redesign its statistical
processes. The current product stovepipe model is not in line anymore with new
circumstances, such as the changing needs of customers, the growing competition, the wish to
reduce the response-burden for enterprises, optimising the use of secondary information,
availability of new information technologies and statistical methodologies and, above all, the
pressure for more efficiency. To survive, SN has to adapt to these new circumstances and
foremost must reposition itself in the market place by adding value to its output.
13
Changing the processes of SN, also has a major influence on the role of the BR. More
attention must be given to its coordinating role, its role as a matching frame, the developments
in time (continuity) and relationships between units (longitudinal and transversal, top xx
enterprises), the translation of (information of) administrative units to (the information of)
statistical units, metadata (e.g. events, but also quality indicators) and further cooperation with
all relevant parties (the external SBR).
It should, finally, be realised that all the mentioned developments have a price tag. As budget
and capacity (e.g. for maintenance) is limited, choices have to made.
Some references
Heerschap, N. and L. Willenborg (2004), Towards an integrated system for business statistics
at Statistics Netherlands, still in concept, Voorburg.
Gillissen, H. (2004), Het hart van het ABR beschreven in Kenniskunde (The hart of the Dutch
Business Register described on the basis of knowledge methodology), internal report,
Voorburg.
Demollin, F., F. Hermans, W. Heijnen and H. Van der Ven (2004), Herontwerp ABR, visie op
het nieuwe ABR-systeem (A vison on the new system for the Dutch Business Register), internal
report, Voorburg.
Dutch Parliament (2004), Op weg naar de elektronische overheid (On the way to an electronic
government), The Haque.
European Union (2003), Business register – Recommendations Manual, Brussels /
Luxembourg.
Website (www.ebr.org) of the European Business Register – Open Network.
14