BPMN Process Model - Descriptive, Analytic (Operational) to Executable

It is often said that BPMN 2.0 is becoming too complicated comparing to 1.0 and 1.2, especially for business users and process modelers in general. The comprehensive notation set in BPMN 2.0, in fact, is one of its key benefits in comparison to its predecessors – the ability of the business process models to be executed on the process engines. Taking the appropriate method, BPMN 2.0 serves both as a practitioner’s notation for process design and modelling and process execution on process engine. The purpose of this paper is to explore the three levels method – descriptive, analytic and executable – in the process modelling to suit the business users, the business process practitioners and lastly the process engineers running the process model on a process engine.

Introduction

The notation in BPMN 2.0 includes multitude of elements that allow not only representation of business process but also possible of having a fully executable process model. However, having too many types of elements may clutter the process model so much that it is complicated and hard for business to understand.
Adapting the three levels of modelling method – descriptive, analytic (operational) and executable – with incremental details at each provides an effective approach for the different stakeholders of a business process model.
Note: The three levels are not the same as the levels used in decomposing business processes (functions) in a Business Process Architecture. That is a topic for another paper. For the level 3 executable model, it is presumed that the model is intended for process automation via a process engine.

Tip:
A process engine provides human workflow management; system service orchestration; monitoring and reporting of process metrics and business KPIs.

BPMN Descriptive Process Model

A descriptive process model defines the scope of the end-to-end business process at the strategic level that managers can easily understand. It also depicts the expected outcome of the business process.
The model serves the following purposes:

• Clarify the scope of the end-to-end process
• Identify resources and assign responsibilities
• Identify KPIs of the business process
• Review the process to determine improvement and/or automation.

The key audience of such model are the executive and/or senior managers who have an interest in improving and managing the end-to-end process. Hence it must be easy to understand even for people with no experience in BPMN.

Tip:
Restrict the notation set used. Suggest to only use these elements: pool, lane, abstract task, sub-process, start event (non),intermediate event (none), end event (none), data, data input, data output and message.

Although the model is to depict the end-to-end business process, it must be kept simple only including standard procedure and regular responsibilities. Work out the end-to-end process with a maximum of eight activities (can be task or sub-process) and only shows a single path in the model.
The figure below shows a draft of an example for “recruit new employee” process.

Figure 1a: Recruitment Process - Descriptive model (draft)

Tip:
Though simple, ensure the correctness of syntax. Breaking the syntax is a bad idea as it introduces confusion. Remember it is the standard that helps in the long run. If necessary, the semantics may be inconsistent at this level.

Apart from senior management, there will be other audience including process participants, process analysts, and process engineers. These stakeholders would expect more details but avoid jumping into the details at this level. After several iteration, an agreed end-to-end process model is reached (see Figure 1b below).

Figure 1b: Recruitment Process - Descriptive model (final)

In the example, the final model includes the following details:

• the key responsibilities for each activity,
• data (global, input, output) in the process,
• messages with external parties, and
• intermediate events showing significant business events of the process.

It is also vital at this level to define the key performance indicators (KPIs) for the process and the business. The agreed KPIs are needed for the analysis at the next level. Example of KPI for this process include:

• Recruitment process cycle time
• Cost of recruitment
• Percentage of vacancy filled quarterly
• Ratio of internal vs external fulfillment
• Ratio of interview against application received
• Satisfaction of business unit with selection process

BPMN Analytic or Operational Process Model

The analytic model as its name speaks is for analysis of the process either via simulation or other process improvement method adapted from Lean Six Sigma. This is where the defined KPIs come into the picture. We will skip the analytic in this paper and look at another usage of the model at this level – operational process model. An operational process model is used to show the happening at the level of the participants. It could be a day-to-day guideline of the process from the view of the respective participant.
Before we continue, recall that there are different types of stakeholders and each only interested in their own views. Firstly, the process analyst who is concerned with the whole end-to-end integration of the process between human tasks and system tasks. He/she is also concerned on the improvement of the process either through process optimisation or process automation. On the other hand a process participant only interests in the activities of the process that concern him/her directly. The process engineer at this level is concerned about what the process engine has to achieve.

Figure 2a: Recruitment Process (part) - Operational model (process analyst/engineer)

The example above (Figure 2a) shows the first part of the recruitment process from the initiating event to the “job advertised” intermediate event. The sub-processes are expanded to task level and type of tasks are also identified, particularly user task. Data store elements are in introduced to show potential system integration. Alternate business path, if any, is also included in the operational model. The key audience of this view are the process analyst (who designed the model) and the process engineer.

Tip:
It is critical to ensure the correctness of syntax and consistency of semantics in the model.

As for the subject matter experts (SMEs) representing the hiring Business Unit and HR team, looking at their piece of the puzzle would make more sense as that is what happens in real life. It is therefore worthwhile to show these SMEs their view of the world (see Figure 2b and 2c).

Figure 2b: Recruitment Process (part) - Operational model (Hiring Business Unit Manager)

The model above (Figure 2b) clearly depicts view of the Business Unit Manager – showing the tasks and artefacts to be produced and expected outcomes (vacancy closed or job advertised). The model below (Figure 2c) shows the view for the HR team.

Figure 2c: Recruitment Process (part) - Operational model (HR Team)

Having separate views of the same process for the different roles may require more works but it will pay off especially if the process crosses multiple business functions. The feedbacks from the SMEs would represent their view from within their represented business functions which match to the view for individual role.

Tip:
Intermediate events are used in the process participant's view showing events happening outside the control of the respective process participant (role). For example, "provide additional information" is a task under the view of BU Manager but under the HR Team, it is represented as an event "additional information received".

Closing the gaps between the process analyst, process participants as SMEs and process engineers are the key to move from the operational model to the executable model. It ensures that the logic between operational model and the executable model is the same; different views based on a single model helps the business to understand any technical implication to the process (as inputs provided by the process engineer).

BPMN Executable Process Model

The work of moving the process model from the operational level to the executable level lies mostly between the process analyst and the process engineer. On the process model itself, the model has to be refined to include system elements such as business rule tasks, script tasks and service tasks.

Figure 3: Recruitment Process (part) - Executable model (Process Analyst)

In the example (Figure 3c), only service task is used. From the model in Figure 2a, service task is added to any activity that links to a data store showing the integration required between the process engine and other enterprise systems (e.g. HR System in the above model). The two non-executable pools are used to provide the context of the service tasks (interface) required for the internal system and the external system.

Other Requirements

Apart from the system tasks that are shown on the diagram, there are other parameters that are defined for process execution but not shown on the process diagram.

Note
The parameters required for process execution on a process engine are defined as part of the BPMN process model but not shown on the diagram.

The list below shows the additional requirements of an executable process model that is not shown on the process diagram. The methods of capturing them depend on the features of the process engine itself or not having a specific feature.

• Process data - Data that are used or generated during the process runtime. In BPMN diagram, they can be represented as data elements but for process execution, they must be further defined either in XML or object models. Data matching between parent process and sub process, receiving messages must also be defined. BTW this has nothing to do with in-memory data technology.
• Organisation - Although the pool and lane of the diagram can be used to represent roles of participants, they are not binding in BPMN. The allocation is managed through membership (a combination of defined groups and roles) with other parameters (depending on the process engine). The structure of the groups, roles and other parameters must be defined and users allocated with the right memberships.
• Business rules - Normally defined as decision tables and implemented on business rules management engines or decision management engine, which is called using a Business Rule task. On the process engine, the parameters, the conditions and return variables must be defined within the business rule task.
• User interface - For each user task in the process model, screen or form must be defined and designed. Most out-of-the-box form designers of process engines are adequate for putting together a decent form. Depending on the process engine, it is also possible to define screen flow or page flow, i.e. having some logic flow of multiple pages of form for a single user task. In addition the form fields must be matched to the process data.
• Business KPIs - Though all process engines come with some features of capturing, monitoring and reporting on KPIs, thereis no standard in BPMN at the moment and rely on the extension implemented by the individual process engine.

Apart from the above details, some controls on the process engine may be managed through 'script' language, hence "script task" in the BPMN model. Interfaces with other enterprise systems are called via various types of "service tasks". Most process engines come with a handful of pre-built integration services ready to use by the process engineer. If there is service task that is required but not available that will be a mini development project in itself.
Once these definitions, designs, and developments (if any) are completed, the process model is ready for execution. The executable process model deployed on a process engine is commonly referred to as process based application or simply process application.

References

1. Object Management Group. 2011. Business Process Model and Notation (BPMN) Version 2.0 Specification 
2. Silver, B. 2009. BPMN Method and Style. Cody-Cassidy Press 
3. Freund, J and Rucker, B. 2012. Real-Life BPMN. CreateSpace Independent Publishing