Identification of phases and sub-processes: to use numbers or not?

[InKyungChoi]

Feedback from Hungary (similar to ILO, below)
 to remove the numbering from the model. The use of the model should not be linear, this is communicated in the GSBPM: „The GSBPM should be applied and interpreted flexibly. It is not a rigid framework in which all steps must be followed in a strict order, instead it identifies the possible steps in the statistical business process and the inter-dependencies between them”. Numbering

Feedback from ILO

Current identification of Phases and Sub-Processes

Since Version 5.1, GSBPM Phases are identified only by their names. The numbers “1.” to “8.” that used to accompany these names until version 5.0 have been removed in order not to imply any kind of sequencing of the Phases.

However, two-level numbers conformed by the former Phase number, a dot (“.”) and a sequential number assigned top-down as per its position in the GSBPM diagram have been kept as part of the name for Sub-processes.

The current structure of GSBPM 5.1 is as follows:

Keeping the two-level numeric reference as part of the name of the sub-processes, generates the false idea of precedence or sequencing order for the level 2 steps.

Identification of Phases and Sub-Processes: Proposal

In order to avoid any perception of precedence or sequencing order among any of the components of the Model, this proposal assign an alphabetic mnemonic code to each one. This code will be composed of one letter for the level 1 (Phases) and of two letters for level 2 (Sub-processes), the future level 3 (Tasks) and the Overarching Processes.

Level 2 and 3 codes will be qualified by the upper level(s) code(s) separated by dots (“.”).

Following these simple rules, the GSBPM structure with the proposed code scheme will be (letters taken for the codes have been underscored for easy understanding):
• S. Specify Needs Phase
• S.IN. Identify needs
• S.CN. Consult and confirm needs
• S.OO. Establish output objectives
• S.IC. Identify concepts
• S.DA. Check data availability
• S.BC. Prepare and submit business case

• D. Design Phase
• D.DO. Design outputs
• D.VD. Design variable descriptions
• D.DC. Design collection
• D.FS. Design frame and sample
• D.PA. Design processing and analysis
• D.SW. Design production systems and workflow

• B. Build Phase
• B.CI. Reuse or build collection instruments
• B.PA. Reuse or build processing and analysis components
• B.DC. Reuse or build dissemination components
• B.CW. Configure workflows
• B.TS. Test production systems
• B.TP. Test statistical business process
• B.FS. Finalise production systems

• C. Collect Phase
• C.FS. Create frame and select sample
• C.SC. Set up collection
• C.RC. Run collection
• C.FC. Finalise collection

• P. Process Phase
• P.ID. Integrate data
• P.CC. Classify and code
• P.RV. Review and validate
• P.EI. Edit and impute
• P.DV. Derive new variables and units
• P.CW. Calculate weights
• P.CA. Calculate aggregates
• P.FF. Finalise data files

• Analyse Phase
• DO. Prepare draft outputs
• VO. Validate outputs
• IO. Interpret and explain outputs
• A.DC. Apply disclosure control
• FO. Finalise outputs

• R . Disseminate Phase
• R.US. Update output systems
• R.DP. Produce dissemination products
• R.RP. Manage release of dissemination products
• R.PP. Promote dissemination products
• R.US. Manage user support

• E. Evaluate Phase
• E.GI. Gather evaluation inputs
• E.CE. Conduct evaluation
• E.AP. Agree an action plan

• Overarching Processes
• QM. Quality management
• Metadata management
• DM Data management
• PM Process data management
• KM Knowledge management
• SM Provider management

[FlavioRizzolo]

At first glance, I wonder whether we need the phase as a prefix. Other than that, I like the two-character encoding for sub-processes.

I'm also wondering whether this might be a good chance to distinguish between "change work phases" and "ongoing work phases", and keep the numbering within each, e.g. CWP-1, CWP-2, CWP-3, OWP-1, OWP-2, OWP-3, OWP-4. There is some natural ordering within each work phase type, and perhaps it might be nice to keep it. Or not.

[egreising]

Sorry for the belated reply. I don't see the value of identifying the subprocesses as "change" or "ongoing" and, on the other hand, it might be risky since whether a subprocess is of one or the other "type" will depend on their usage. For example, in an Agile environment, revisions might be part of the work cycle, so coming back to "Build or enhance process components" and "Build or enhance dissemination components", two subprocesses of a "change" phase, would be "ongoing" for this particular process.
Besides, numbers will always put certain sequence idea on the spot, and after evaluation it is likely to go back to re-design or re-built, but not necessarily to re-specify the needs, so that no sequence is followed once that the business cycle starts to "move".

Regarding the phase qualifier, my first idea was not to include them, but it becomes difficult to have an homogeneous 2-character or 3-character set of unique mnemonic codes for all the 44 sub-processes, so that I added the phase as qualifier to simplify.