The question arises which GSIM object or set of objects actually describes the building block (Lego brick or Service) as defined in CSPA? It seems that the ProcessStep is the logical choice. As a consequence, it must be possible to combine a particular ProcessStep with any other ProcessStep into a Process. This means that there is no up-front fixed relation between ProcessSteps, and this relation should certainly not be made based on the ProcessStepDesign. It must be possible for one ProcessStep to be followed by multiple ProcessControls, but only one within the context of a particular Process. There is no direct relationship between Process and ProcessStepDesign, a CSPA Assembler creates a new Process by combining available ProcessSteps and ProcessControls.
Are then both ProcessStep and ProcessControl the CSPA building blocks?
Do we need a mechanism to express the specific relationship between a ProcessStep and a ProcessControl within the context of a Process?
4 Comments
user-8e470
To inform discussion in this group:
CSPA definition of Statistical Service: A service is a logical representation of a repeatable business activity that has a specified outcome and is self-contained, fulfils a business need for a customer (internal or external to the organization) and may be composed of other services. Source: Statistical Network BA definition)
Relevant GSIM definitions
Object
Group
Definition
Explanatory Text
Process Control
Production
A decision point which determines the flow betweenProcess Steps.
The typical use of Process Control is to determine what happens next after a Process Step Design is executed. The possible paths, and the decision criteria, associated with a Process Control are specified as part of designing a production process. There is typically a very close relationship between the design of Process Steps and the design of Process Controls.
It is possible to define a Process Control where the next Process Step that will be executed is a fixed value rather than a "choice" between two or more possibilities. Where such a design would be appropriate, this feature allows, for example, initiation of a Process Steprepresenting the GSBPM Process Phase (5) to always lead to initiation of GSBPM sub-process Integrate Data (5.1) as the next step.
This allows a process designer to divide a business process into logical steps (for example, where each step performs a specific Business Function) even if these Process Steps will always follow each other in the same order. In all cases, the Process Control defines and manages the flow between Process Steps, even where the flow is "trivial". Process Step Design is left to focus entirely on the design of the Process Step itself, not sequencing between steps.
Process Step
Production
One in a series of tasks which comprise a statistical business process
A Process Step implements the Process Step Design specified in order to produce the outputs for which the process step was designed.
Process Step Design
Production
Defines how a Process Step will be performed. This includes specifying the Process Inputs to that work and the Process Outputs that will be produced.
A Process Step can be as big or small as the designer of a particular business process 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,using a particular Business Service, to produce particular Process Outputs. The flow between a Process Step and any sub steps is managed via Process Control.
Business Service
Production
A defined interface for accessing business capabilities (an ability that an organization possesses, typically expressed in general and high level terms and requiring a combination of organization, people, processes and technology to achieve).
A Business Service may provide one means of accessing a particular Business Function. Requesting a particular service through the defined interface may result in a business process (workflow) being executed.
The explicitly defined interface of a Business Service can be seen as representing a "service contract". If particular inputs are provided then the service will deliver particular outputs in compliance within specific parameters (for example, within a particular period of time).
In the case of GSIM, a Business Service typically implements a particular Process Method to perform a particular Business Function.
Note: The interface of a Business Service is not necessarily IT based. For example, a typical postal service will have a number of service interfaces: - Public letter box for posting letters - Counter at post office for interacting with postal workers
:
user-8e470
Discussion 2/10:
Al says it is a business service or one step below a business service (a way of implementing it). A business service should be able to support process steps across production areas (common services across agencies). Services go away and perform process steps.
This is a touch point between GSIM and CSPA.
A business service is not always performed by automated service (that is, a person could do it). there is contract with something/someone who does the work (process).
Perhaps we can make it clearer in the document (but maybe more in CSPA?)
Dick Woensdregt
There are two sides to this. Yes, is should be possible to express the inner workings of a service in terms of GSIM, which means is should be possible for a service to have a process internally. This is for service Designers and Builders as meant in CSPA. On the other hand, and that was my original point, an Assembler as meant in CSPA should be able to "string together" a number of services into a process. I assume that GSIM should support this, which means GSIM must allow a service to be a process step in a process.
user-8e470
CSPA makes a distinction between business function, business process and business service in a manner that is aligned with GSIM (this is discussed in Section III A of CSPA v0.8). The
I think that an Assembler as meant in CSPA should be able to "string together" a number of services to support the process you want to undertake. A service supports a process but is not the process itself. A configurer would then take the suite of services that the particular business area intends to use in order to undertake their business process.
I think that the phrase in red in CSPA should be changed to provide extra clarity. GSIM should add a mention of Statistical Service either to the description or examples of a Business Service
CSPA v0.8 says: