Business process level

At this level the processes of the firm(s) under consideration are modelled. The level is split up in two parts following the metaphor of "what? and how?". The what questions belongs to the process view which describes the business processes and their relations from outside. The how question belongs to the workflow view which describes a certain process from inside. The result of modeling at this level is a business process model. The business

process view shows the processes and the sub-processes of the business unit under

consideration as a process map. The relation between such processes are either an assignment of sub-processes to business processes which allows reuse of such sub- processes or the outputs which are produced or consumed by the processes.

Process view

The metamodel defines the necessary elements and the relations to model the process view. The metamodel does not allow to have an output without an addressee (the to-role on the coordination-flow). An output is always provided for other processes. For example, if a product or service is produced for the market (i.e. not produced for a specific customer) the sink for the output is an (abstract) market process. If the output is produced for end-

Figure 34: Process view metamodel

Process view elements:

Process: A process is a business process or a sub-process as described earlier. Sub-

processes are used to structure a complex business process. In the context of the method no further distinction is made between business processes and sub- processes, i.e. they share the same symbol and meaning.

Output: An output is the result of processes and the granularity of the output definition

impacts the granularity of the necessary processes. Describing the output is one of the key tasks in the description of business processes [Scheer 1999]. An output can have the form of a tangible product like a car which is produced in a process or it can be information like an instruction manual or a report. Outputs can be formally described using a resource description framework like the STEP (Standard for the Exchange of Product Model Data) [Grabowski et al. 1993] or other description framework.

Process view relations:

Hierarchy: The hierarchy models the relation between processes and sub-processes. Coordination-flow: see next.

Figure 35: Example process model

Workflow view

The workflow view shows the flow of control within a business process as a workflow. A workflow starts when a certain event occurs. This event is called start event. The workflow ends when an end event is reached. Between start and end of such a workflow one or more activities are carried out with the possibility of concurrent or conditional execution of such activities.

Figure 36: Workflow view metamodel

The metamodel for a workflow view defines the following elements and relations: Event: defines either the start or the end of a workflow. In literature events are often

used in different ways. For example, events in the event driven process chain (EPC) are used at the start of a process and between each activity to describe either the outcome of a check-activity, like material is (not)available, or changes in the environment, like purchase order arrived or proposal reviewed. Others omit the event completely in a workflow model and instead a start activity and an end activity are used. The start event and the end event differ in the workflow model. The start event has only outgoing flows while the end event has only incoming flows. Apart from this, typically they carry different attributes. Attributes for the start event are often statistical data like the probability of occurrence or the probability distribution.

Activity: defines the task which is executed in a business process either manually or

automatically. Activities can be production activities or coordination activities. Production activities modify the environment and manipulate information or material. Coordination activities control the flow of the process and do not change the environment. A default attribute for an activity is the processing time.

Sub-process: A composition of the relevant elements of a workflow. Sub-processes

serve as a structuring element to reduce complexity and as a reusable element which can be deployed in different business processes.

And-split: A point within the workflow where a single thread of control splits into two

or more threads which are executed in parallel, allowing multiple activities to be executed simultaneously.

And-join: A point in the flow of control where two or more parallel executing activities

converge into a single common thread of control. Each parallel executing thread is held until the set of all thread transitions to the next activity is completed at which point the threads converge, which means they are synchronized.

Xor-split: A point within the flow of control where a single thread of control makes a

decision upon which branch to take when encountered with multiple alternative branches. A single specific transition to the next activity is selected according to the outcome of the transition condition.

Xor-join: A point within the flow of control where two or more alternative branches

converge to a single common activity as the next step. As no parallel activity execution has occurred at the join point, no synchronisation is required.

Output: same as above.

Message: A message is used to notify activities about events. Typically messages are

used to start an activity or notify interested parties about certain events. Messages are often standardized to allow inter-organisational collaborating like the EDI standard or one or more of the emerging XML message standards. Another means often used to inform interested parties are e-mails which inform about certain events. Messages are semantically very similar to outputs or form a part of an output. For instance, an purchase-order-request message asking for a certain product or service is the output of a customer, and the output of the order process is an order in the order processing system as well as the purchase-order-

confirmation message which is sent back to the customer. In fact, messages are a

core element for the coordination of business processes between networked enterprises. In practice, an enterprise has to cope with different types and formats of messages even within the same process. Figure 37 shows a part of a process where an number of hotels are asked if they can provide rooms on behalf of a customer request. For instance, the type can be an EDI message, an proprietary text format, an industry specific XML message (e.g. as proposed by the Open Travel Alliance (OTA) for the travel industry)10, protocols like the SOAP (Simple Object Access Protocol), or even a telephone call or a fax. Such types together with the meaning of the message and the economical consequences can be clarified within the modeling project. Other ways to coordinate processes are a workflow system or a shared data space, for example by the means of a database. The database triggers are used to coordinate the processes.

And-split as well as And-join are not modelled explicitly but are derived from the outgoing flows of control (And-split) and the ingoing flows (And-join). This means, that an activity starts only if all ingoing flows of control are true and when an activity ends all outgoing flows become true.

The relations for the workflow view are:

Coordination-flow: models the flow of control in the process, i.e. one activity

completes and the thread of control passes to another, which starts. A transition may be unconditional, such as the completion of one activity always leads to the start of another, or conditional, where the sequence of operation depends upon one or more conditions.

Information-flow: This models the relation between an activity or a (sub)process and a

message. The type of the arrow indicates the access direction. For example, a message is sent to notify a management process about the completion of a certain step. Note that this may also start the execution of certain activities within the management process, for instance the computation of some figures, but does not play a role in the execution of the current process. This type of coordination can be denoted as weak type. This means, the current workflow does not depend on some response to the sent message. A message can be sent to another process or a business unit. The business unit is used when no specific process is known where to send it. Typically, this is the case in B2C environment. If the construct is used in a B2B relation, then this indicates a source for further improvements by better integration of information in a certain process.

The example in Figure 38 shows a simple workflow which is embedded in the reporting process

Figure 38: Example workflow view