Closed FlavioRizzolo closed 3 years ago
I would also add that Processes can be viewed as a "contextualized" Activities, i.e. with flows and inputs/outputs.
Activities seem to be one of the building blocks of Processes.
According to ISO-9000:2005, in Section "2.4 The process approach":
"Any activity or set of activities that uses resources to transform inputs to ouputs can be considered a process"
I fully agree with the way activity and process were defined in metadata glossary as well as with the points that "process is a contextualized activities" and "activities are the building blocks of a process". But I don't see how it creates major inconsistencies.
Based on definitions/interpretation above, here is how I define activity and process :
With this set of definitions, I see "production" in GAMSO as an activity. GAMSO does not provide structured way "how we produce". It only talks about "what we do" - production. This is true for other activities described in GAMSO. They only enumerates what we do, not really show how we do (e.g. GAMSO Manage Quality).
On the other hand, GSBPM provides structured way "how we produce" official statistics, it shows how we carry out "production activity". Although we emphasize non-linearity of GSBPM (i.e. that we don't need to follow from phase 1 to phase 8 linearly), there is clear sequence we want to follow within the whole production at higher level (e.g. design then build, but probably not the other way around) as well as within sub-processes (e.g. how to check data availability before design, how to prepare business case, how to proceed with it). I agree that some sub-processes in GSBPM make them more like an activity rather than process but I still don't think this creates major inconsistencies because GSBPM is about statistical production process, so the elements consisting the process can be "activities". When we talk about GSBPM, it is more about structured way of activities to produce official statistics, not just a simple collection of activities that are related to production of official statistics.
So, I think how we call depends in which context we talk about, GAMSO is about "production activity" while GSBPM is about "production process".
Decided during July 2 meeting: Dan is lead on this issue. Send contribution to him so that he can make a synthesis here.
The concepts that are used by GSBPM, GSIM and GAMSO for process/activity are different. In order to speak the same language in this project those have to be harmonised. The concepts for this issue used by these standards are as follows.
These concepts also need to be linked logically to the activity definition of PROV-O (if we understand correctly). That is: An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.
GSBPM: The GSBPM comprises three levels: • Level 0, the statistical business process; • Level 1, the eight phases of the statistical business process; • Level 2, the sub-processes within each phase. Statistical business process is a collection of related and structured activities and tasks to convert input data into statistical information. In the context of the GSBPM, organisations or groups of organisations perform statistical business processes to create official statistics to satisfy the needs of the users.
No further definitions can be found in the documents, such as activity
GSIM • Process Design: A Process Design specifies delivery of Business Functions. A Process Design is the design time specification of a Process Step that is performed as part of a run-time Business Service. A Process Step can be as big or small as the designer of a particular Business Service chooses. From a design perspective, one Process Step can contain "sub-steps", each of which is conceptualized as a (smaller) Process Step in its own right. Each of those "sub-steps" may contain "sub-steps" within them and so on indefinitely. It is a decision for the process designer to what extent to subdivide steps. At some level it will be appropriate to consider a Process Step to be a discrete task (unit of work) without warranting further subdivision. At that level the Process Step is designed to process particular Process Inputs, according to a particular Process Method, to produce particular Process Outputs. The flow between a Process Step and any sub steps is managed via Process Control. • Business Process: The set of Process Steps to perform one of more Business Functions to deliver a Statistical Program Cycle or Statistical Support Program. For example, a particular Statistical Program Cycle might include several data collection activities, the corresponding editing activities for each collection and the production and dissemination of final outputs. Each of these may be considered separate Business Processes for the Statistical Program Cycle. • Process Step: A Process Step is a work package that performs a Business Process. A Process Step implements the Process Design specified in order to produce the outputs for which the Process Step was designed. Each Process Step is the use of a Process Design in a particular context (e.g. within a specific Business Process). At the time of execution a Process Step Instance specifies the actual instances of input objects (for example, specific Data Sets, specific Variables) to be supplied.
No further definitions can be found such as activity.
GAMSO GAMSO breaks down its scope to activity areas and activities. No further definitions can be found in the documents e.g. for process.
As it is not clear which concept is the right one to choose (process or activity) let’s see a generic definition for that.
ISO 9001:2015 definition for process: A set of interrelated or interacting activities that use inputs to deliver an intended result • Note 1 to entry: Whether the “intended result” of a process is called output (3.7.5), product (3.7.6) or service (3.7.7) depends on the context of the reference. • Note 2 to entry: Inputs to a process are generally the outputs of other processes and outputs of a process are generally the inputs to other processes. • Note 3 to entry: Two or more interrelated and interacting processes in series can also be referred to as a process. • Note 4 to entry: Processes in an organization (3.2.1) are generally planned and carried out under controlled conditions to add value. • Note 5 to entry: A process where the conformity (3.6.11) of the resulting output cannot be readily or economically validated is frequently referred to as a “special process”. • Note 6 to entry: This constitutes one of the common terms and core definitions for ISO management system standards given in Annex SL of the Consolidated ISO Supplement to the ISO/IEC Directives, Part 1. The original definition has been modified to prevent circularity between process and output, and Notes 1 to 5 to entry have been added. According to the ISO definition process and activity are in subordinate relation so that the activity is a more generic term, than process. Also process definitions in GSBPM and GSIM also suggest that process is a unit that is of more interrelated units (process phases, sub-processes, process steps). Therefore the terms used in GAMSO (activity area and activity) are not adequate compared to the ISO definition and the other standards (GSBPM, GSIM) as activity areas and activities are rather processes. Activity is also far too generic in this case as well. From our point of view process term should be used (business, process, process phase and sub-.processes) and task should the lowest level of hierarchy. That is a kind of unit that cannot be further broken down (e.g. making a decision on a statistical program that means a yes or no nothing more). But in the scope of this project task should not be taken into consideration as GSBPM’s lowest unit is sub-process and so we could remain in line with the standards that are of interest in this project. Conclusion and suggestion: In this meaning the scope of these standards are rather processes than activities in general. The term task is specific to a certain organisation how they conduct their processes therefore out of scope as standards are generic. We cannot solve all of the issues that might come up during national implementation as that would take decades. The work done by the Linking GSBPM-GSIM Task Team uses process step (GSIM object) in their work going down only to sub-processes (GSBPM concept) and we should be in line with their deliverables, so that the different deliverables of different UNECE Task Teams can be used together when deciding so. We suggest that the activities referred to in the ontology should be StatisticalBusinessProcess (level 1), ProcessPhase (level 2), Sub-process (level 3) and Task (level 4). That means that we basically deal with processes (on different levels) when we mention prov:Activities
For completeness, I think we need to introduce the notion of Capability as well, since it's a key pillar of any business description together with Activity and Process. In addition to being heavily used in GAMSO, which is part of COOS already, it's also at the core of CSDA and has even been included in the Metadata Glossary:
https://statswiki.unece.org/display/hlgbas/Statistical+Metadata+Glossary
No activity on this issue -> closing
As Dan pointed out, activity, process, and capability can be distinguished informally as follows:
Activity – What we do Process – How we do it Capability – What allows us to do it (we need to look at CSDA for this one)
GAMSO is centered around the idea of “activity” wheras GSBPM is centered around the idea of “process”.
However, when you look at the wording in GSBPM, that document discusses processes as activities. GSBPM does not talk about how steps are to be done, just that they are to be done – the “what”. Plus, the “process” model of GSBPM is incorporated into the “activity” model of GAMSO.
As a result there are a number of inconsistencies between the two specs. The metadata glossary group is aware of these.