IntroductionThe 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.
A process engine provides human workflow management; system service orchestration; monitoring and reporting of process metrics and business KPIs.
BPMN Descriptive Process ModelA 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.
Tip: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.
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.
The figure below shows a draft of an example for “recruit new employee” process.
|Figure 1a: Recruitment Process - Descriptive model (draft)|
Tip: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).
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.
|Figure 1b: Recruitment Process - Descriptive model (final)|
- 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.
- 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 ModelThe 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)|
Tip: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).
It is critical to ensure the correctness of syntax and consistency of semantics in the model.
|Figure 2b: Recruitment Process (part) - Operational model (Hiring Business Unit Manager)|
|Figure 2c: Recruitment Process (part) - Operational model (HR Team)|
Tip: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).
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".
BPMN Executable Process ModelThe 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)|
Other RequirementsApart 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.
NoteThe 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.
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.
- 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.
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.
- Object Management Group. 2011. Business Process Model and Notation (BPMN) Version 2.0 Specification
- Silver, B. 2009. BPMN Method and Style. Cody-Cassidy Press
- Freund, J and Rucker, B. 2012. Real-Life BPMN. CreateSpace Independent Publishing