The objective of the modeling project was to describe the processes and their context. The blue print had identified 10 core business processes aggregating 129 processes. The required level of detail for a process description varied from an abstract, “black-box” process description just defining the context to very fine granular descriptions e.g. system operations. The contextual information defines the organizational unit owning the process, the roles responsible for the execution of the involved activities, and the specific documents used or produced within the process.
These objectives pose many requirements to the chosen modeling technique.
It should support structuring of the processes at different levels of abstraction combined with the possibility to drill-down into a single process, thus moving from an abstract level to the details.
Apart from the workflow itself the description of further aspects, such as orga- nizational and information related aspects, should be supported, thus allowing the modeler to define who works on an activity and which items are produced within an activity.
The decision was made in favor of BPMN, the new OMG standard for busi- ness process modeling [2]. BPMN amalgamates best practices within the business modeling community. However, its focus is on the description of activities and their control flow dependencies. A variety of modeling elements can be combined in many different ways, thus providing much freedom in defining the actual pro- cess flow. Regarding BPMN’s support for other aspects, such as the information and resource perspectives, BPMN’s performance is not so good. Although the BPMN provides some concepts for their description, the modeling of an organi- zational structure, an extensive role concept or a distinct document landscape is beyond BPMN’s means, c.f. [2,9,7].
Defining rules for the use of BPMN within the gematik transformation pro- cess, these shortcomings were also felt by the gematik process architecture team.
To exploit the BPMN for the business transformation project two lines of cus- tomization were followed:
Adaption of native BPMN constructs. To define the actual process flow and the interfaces between processes, and to provide an adequate drill down mechanism, the rich set of BPMN modeling elements and their combination possibilities had to be adapted.
Extension of BPMN via UML. The organizational structure, the artifact landscape but also the high-level process structure is modeled using UML-concepts. Here the interface between the provided BPMN-concepts and the separately used UML-models had to be defined.
The necessary customizations are described in more detail in the following sections:
1. Process architecture 2. Organization structure 3. Artifact landscape
Each section is described in identical format: First the gematik requirements are given. Then the chosen BPMN-concepts are listed and the linkage to the used UML mechanisms is described. Finally examples are provided.
2.1 Process Architecture
The new structure of the gematik is process-oriented. Starting form their needs for resources and with the proviso that interfaces should be reduced the new structure focuses on the core processes essential for the value creation of the company. The departments are defined along the core processes, ensuring that each process is owned by exactly one department. The core processes are made up of processes and their interfaces. Only at the level of processes the actual workflow is defined.
BPMN’s highest level of abstraction is the workflow. A concept to describe process layers at a higher level is not provided. To reflect the structure of the process landscape the UML-package concept is used.
Core process. Each core process respectively department is modeled by an UML package. These packages are denoted with a special stereotype “core pro- cess”. In the repository these packages are contained in a super package called
“departments”. The department package is one of the two main packages of the repository. The second top-level package “cross-process information” contains information relevant to more than one core process such as process interfaces, artifacts and roles.
Process. A core process aggregates a set of processes. Processes are depicted by business process elements1. Obligatory information on this level is a precise and unambiguous name and a short textual summary of the process, outlining the process goal, the critical success factors and the risks. The summary is provided using the notes-field of the model element. To reflect dependencies between the processes, they can be grouped (model element group or package) or connected using control-flow arcs or message flow arcs.
1 In the BPMN Adopted Specification [2] there is no distinct notation for business process. The distinct activity type “business process” originates from the modeling set provided by the chosen modeling tool.
Workflow. The processes are refined describing the actual workflow. The re- quired level of detail for a process description varies from quite abstract descrip- tions just defining the context to very fine granular descriptions of e.g. system operations.
For the description of the workflow a subset of the BPMN modeling elements was selected. In general all basic flow elements (events, activity, gateways) can be used. For the drill down the BPMN-hierarchy concept is used. Different ab- straction levels are supported by the two activity types “sub-process” (which can be refined) and “task” (which is atomic).
On the first level the workflow description is complete, but not detailed. On this level possible start events (process triggers) and possible end events, as well as involved roles and interfaces to other processes are reflected. Participating parties (modeled by BPMN pools and lanes) can be described both using a white- or black-box approach. For white box descriptions, the organizational unit, involved roles and process steps are visible. A black box description only discloses the involved organizational unit—such elements must have a white-box description elsewhere in the model. It is clear that the part of the process owner is always modeled white-box. A further requirement is, that the elements of the process owner are all connected, i.e. they are all on a path from a start event to an end event.
A white-box description of a third party (not the process owner) can be re- fined. Concerned organizational units can decide to provide their own (enhanced) process description, thus over riding the pre-defined interface. Requirement for the re-definition is that the initially provided modeling elements (and their de- pendencies) are part of the redefined process. An example for a workflow con- taining white and black-box descriptions is provided in Figure 1.
Here, the part of the “Expert” is modeled white box. This means that the predefined tasks “comment document” and “send review comments” (and their order) are obligatory for every refinement. The process of the author is modeled black box. Except for the defined interface2, no restrictions are made to their workflow.
Sub-process refinement. Any sub-process can be refined into sub-workflows.
All modeling constructs available to process workflows are also available to sub- process workflows. The only restriction is that the sub workflow always starts with one start- and ends with one end event.
Note. The hierarchy must be strictly met. Link model elements from different levels via flows is prohibited—elements are linked to their parent element by containment and can be connected to elements at the same level via flows or messages. Moreover, every flow element should be part of a desired execution path. In fact, mapping the requirements to possible correctness criteria [6], only relaxed soundness[4,5] is applicable. Well-structuredness [1,3,8] is not required.
2 An interface between different organizational units is always modeled using a message flow pointing to a message event.
Fig. 1.The workflow within the review process
Soundness [1] cannot be guaranteed, because of the OR-gateway, which is allowed to reflect optional flow.
2.2 Organization Structure
Tasks are executed by responsible actors (mostly persons). Responsibilities are summarized in role(description)s which are assigned to positions within an organization. In our context3this relationship was condensed to roles that belong
3 We only consider the description of processes and not their instantiation at run time.
So we do not need to reflect the relationship between roles and concrete actors.
to organizational units. Several roles can be involved within one process. One distinguished role is said to be the process owner.
The BPMN provides model elements to organize and categorize activities.
These are groups, lanes and pools. Pools are used to represent participants of the process. A lane is a sub-partition of a pool.
In the gematik process landscape roles are modeled using the model element lane. Organizational units are modeled using the model element pool. Every task has to be assigned to a role, that is the corresponding model element (activity or sub process) is contained in a lane. Every role is assigned to an organizational unit. Therefore every lane is contained in a pool.
The organizational structure of the gematik and the set of possible roles has been modeled separately using UML-class diagrams. The class diagrams describ- ing the organizational structure do not only contain class representations for concrete organizational units (e.g. “Test-Department”, “Quality Management”) but also for abstract generalizations, e.g. classes “Organizational Unit”, and
“Department”.
Associated to the organizational units are the available roles. As the set of classes, the roles are divided into generic and internal roles. The first describes roles that can be applied to people in potentially all organizational units. Ex- amples for such roles are “Author”, “Expert”, “Project Manager”, “Head of Department”, “Process Responsible” or “Employee”. The internal roles are spe- cific to a certain department. Examples for the latter are “Employee of Quality Management Department”, “Review Owner”, or “Head of Test Department”.
Figure 2 shows an extract of the metamodel describing the gematik’s organi- zational structure. It is important to note that every role or organizational unit contains a detailed description which is aligned to the authorized definition in the organization manual.
In order to guarantee consistency between the BPMN process models and the UML-class diagrams the following convention must be followed: Every lane and pool within the process model (BPMN) has to be linked to one class (either generic or specific) of the organization model (UML). The compliance with the defined rule is checked with the help of a validation script. Regularly invoked it checks whether the roles defined in the gematik organization model (UML classes) are well-defined. It then verifies that every lane used in the process model has its counterpart within the organization model. If so, a link is set between the two elements. Otherwise the mismatch is reported.
Figure 1 shows the process model describing the internal review procedure.
It involves up to three different organizational units, and four different roles.
The “Review Owner” (process owner) and the “Proof Reader” are specific roles in the quality management department. Therefore the corresponding lanes are contained in a pool representing this specific department. The “Author” of the reviewed specification can come from either a department or from a project.
The class (respectively pool) generalizing both is the “Organizational Unit”. The technical reviewing (role “Expert”) is a task that belongs to the responsibilities
Fig. 2.Organization model (extract): The generic organizational structure
of the line structure. The corresponding role is therefore associated only with departments.
2.3 Artifact Landscape
Artifacts, in particular specification documents, play a prominent role in the gematik context. These documents constitute the actual “product” of the com- pany. Most of the processes are centered around their development, respectively improvement, and their publication. Correspondingly, the artifacts used and pro- duced within the processes must be modeled within the process descriptions.
Two aspects are modeled: the document type and the progression of a single document instance.
The only elements BPMN provides to depict information related aspects, are the model element “data object” and specific connectors to depict data flow.
Detailed data and information models are beyond the scope of BPMN.
To overcome this shortcoming, we followed a similar approach as sketched for the organizational modeling. The gematik artifact landscape had been described with an UML-class diagram. It contains a generalized class “gematik artifact”
with common attributes, such as state, status, scope, storage type, and stor- age place. Derived classes are e.g. “document”, “form”, “document template”,
Fig. 3.Information model: The gematik’s artifact landscape
“source code”, “binary”, “model” and an aggregation, the “artifact collection”.
Figure 3 shows the information model describing the gematik artifact landscape.
In order to use the different artifact types within the process models, the UML- diagram was transformed into an UML-profile with corresponding stereotypes.
This profile was imported into the EA, enhancing the set of possible stereotypes for the model element Artifact.
Artifacts are built and stored independently from the process models in a super-ordinate package “Artifacts”. Creating an artifact, its type has to be de- termined, applying one of the pre-defined stereotypes. Every artifact contains a textual description outlining its specific purpose. Further information about the artifact can be given using the attributes provided. Corresponding tagged values can be set to denote e.g. the state, the status, the scope and its storage location.
In the process descriptions, instances of the artifact are linked. The handling of an artifact within a process can be documented using (respectively overwriting) again the mentioned attributes.
Examples for the use of artifacts are provided in the Review Process in Fig- ure 1. Here the “review protocol” is the main document. The process is triggered using the interface “Request: initiate internal review” and transferring a certifi- cate referring to the artifacts to be reviewed. During the first activity “prepare review” the frame of the review is fixed. This includes determining a dead- line and the circle of reviewers. This information is noted in the review protocol (state:instantiated). In parallel, the documents to be reviewed are converted into a line numbered pdf-format. For reporting purposes a record is created in the in- ternal planning list. In the next step, the review protocol and the pdf-documents are transferred to the reviewers (interface “Request: generate comments”). They use the protocol to include their comments. The completed protocol is renamed and sent back to the QM-department (interface “Acknowledgment: comments generated”).
The review owner waits for the deadline to be reached and than collects the review results. The different comments are integrated into one form and reordered. Redundant comments are combined. A deadline for the revision is set.
The consolidated protocol and the revision deadline are transmitted back to the author (interface “Request: integrate the comments and respond”). The process is closed by recording the revision deadline in the planning list. In addition to review coordination, the QM-department also performs formal revision of the documents. This task is accomplished by the role “Proof Reader”.