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?



  • No labels

4 Comments

  1. 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

    :

     

  2. 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?)

  3. 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.

  4. 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: 

    Describing Statistical Production

    47.       A central aim for CSPA is to enable more efficient and flexible support for statistical production as described by the GSBPM.  Future versions of CSPA will provide more guidance on how CSPA can be applied when designing, managing and performing statistical business processes.  However, the initial focus in the development of CSPA has been to clearly and consistently define (both conceptually and in practice) the Statistical Services which support statistical production.  The aim is that equivalent business functions (such as imputation) within many different statistical business processes will be able to reuse (or share) the same Statistical Service in the implementation of the business service.

    Service Assembler Story

    190.     The Assembler will take the Statistical Service and integrate it according to the understanding of the needed business process, as expressed in the design documentation. This might take place within a process management environment. There are two cases for the Assembler: one where the required Statistical Services would be entirely assembled within the local environment, which provides a high degree of confidence in their compatibility. The second scenario involves the use of external Statistical Services, which might require extension or modification. In this latter case, issues would be communicated to the Designer and Builder for further development.

    Configurer Story

    191.     The Configurer takes the assembled process, and makes it suitable for use in the intended statistical domain. Parameters are specified according to the domain knowledge of the Configurer. Any issues with the assembled Service are communicated to the Designer, Builder, or Assembler.

    The Assembler will take the Statistical Service and integrate it according to the understanding of the needed business process, as expressed in the design documentation.