Skip to end of metadata
Go to start of metadata


From Statistics Finland:

 Better incorporate different types of statistical production processes.
- Currently processes relying on administrative, aggregated or model based
data (such as used in National Accounts and Greenhouse gas statistics) do not fit very well to the model.
- In monthly production processes some phases such as "update sample" might
only be repeated yearly.


I hesitate to mention "Big Data" since I'm not sure that a place can be found for it but again it might be useful to keep in mind to ensure the model doesn't date too quickly. 

Admin Data


Finally, we think GSBPM can be slightly improved for the description of processes using administrative data. For example, administrative data can be used, also using integration technique, to build better frames. In GSBPM “integrate data” is only under phase “6.process”. We think that in phase 3. Build, an additional subprocess could be added as “Build frame” or the description of “3.1 Build data collection instrument” can be changed to include this activity. In addition, in setting up the acquisition of administrative data, it is very important to establish and maintain good relationships with the data providers, thus we suggest to mention this activity in 4.2 description


Statistics New Zealand response to GSBPM v4.0

Statistics New Zealand uses a great deal of administrative data and has mapped the various activities associated with its use to the processes and sub-processes of the BPM reasonably successfully. For example, the investigation of the quality and possible uses of particular administrative data sources, which is a large part of acquiring and using administrative data, fits neatly into the Design process as a series of activities within each of the sub-processes. It may be useful to check that the wording used for the sub-processes applies to data from different sources. At the activity level there are common activities associated with our use of administrative data. For example, 1.5 “Check data availability” includes ensuring we have decided to seek new data only when we are confident there is no data like it available within the wider NZ context, i.e. that we have examined all administrative data possibilities. Similarly, at the activity level we would expect to see an assessment of cost/quality/timeliness/respondent burden trade-offs, either in 1.6 under "Prepare business case" or in 2.3 “Design data collection methodology”, or both.

Statistics Sweden

Enhance in the descriptive texts that the use of administrative data and registers are included in addition to the direct data collection, which is more visible now.


One thing that would be really useful is a clear understanding of where "Admin Data" might fit in. I have been told that the model covers this aspect of producing statistical outputs but remain to be convinced so either some clear guidance of where it fits in or some tweaking of the model or descriptions would be most welcome.








  • No labels


  1. GSBPM should be generic; it should be able to describe production processes based on different types of sources (and combinations). Collect formulated very much from an survey methdology perspective. Please also note that Eurostat reuses data produced by the national statistical offices. Still there is a collection process of the data produced by the national statistical offices.

    For me this raisses the issue of scope. Probably this is more an implementation issue. For instance, if Eurostat would like to describe the internal production processes, it might use the collect step to describe the data collection from the national statistical offices. In case we would like to describe the total process, the description should start from the national survey design, or even from the data collection at the national administration (which would then be largly given, and not designed by the statistics system).

  2. GSBPM should be neutral to the types of data sources. We should not imply a classification of sources (source dependent process should be avoided).

    So we are suggested that we should change the descriptions, rather than change to model

    Paragraph 4 says GSBPM says it should be source neutral. Remove any last survey centric mentions. Collect for example is quite survey centric. Perhaps move towards language from GSIM which tends more towards Acquire. 

    There are still some sub process which are survey centric. You can skip sub processes if they are not relevant.