Nina Uhl's picture

After having read the overall story about Enterprise BPM and the role services play within this approach, I would like to dive into the modeling aspect of Enterprise BPM. How and what does the business side need to do to model in a proper way to reach a seamless transition to the automation part – and back?

We call it “Process Transformation” and this is the idea behind the story:

Business processes are modeled as Event-driven Process Chain (EPC) with the line of business managers or the involved process owners. These EPCs describe the WHAT – the business point of view being steered by business strategy. The models are easy to understand and have a high degree of flexibility in its process structure and are the basis for “Model to Execute”, the implementation part of EBPM.

In the M2E context business process models represent the requirements view. They describe what the process owner expects from the implementation team. To allow for a precise translation of these process requirements into a logical, i.e. technically oriented process model in BPMN, the EPC should comply with some modeling conventions.

In general, modeling conventions ensure consistency across models and modeling teams. They promote clear and transparent communication of process and service information. Model to Execute modeling conventions serve three purposes:

  • Consistent modeling of process and service architecture
  • For the EPC to BPMN transformation, business process models MUST comply with a few compulsory modeling rules. Their violation generates errors that stop the transformation.
  • The more the business process model complies with additional modeling rules, the higher quality and level of detail of the resulting BPMN model. If those rules get violated, the user is informed by warnings which can be ignored by transformation.

EPC object types relevant for M2E requirements modeling:

A pure EPC consisting of events, functions, and connectors can already be transformed into a BPMN model. However, often there is more requirements information to be gathered by business and handed over to the BPMN. For example, the transformation derives the type of a BPMN task from the modeling patterns of a EPC function.

Thus, you can  preconfigure EPC functions for the following BPMN tasks: automated, semi-automated and manual. A process step is defined as an automated task when a software service performs without any manual interaction. BPMN therefore calls them service tasks. A semi-automated step is a process step where a human performer performs the step with the assistance of a software application and is scheduled through a task list manager of some sort. In BPMN they are called user tasks. A manual process step is expected to be performed without the aid of any business process execution engine or any application.

A process step is defined as an automated task when you assign a business service to a function.


To create a semi-automated task in the BPMN model you need a screen object in the EPC or define the specific requests in the attributes.


And to receive a manual BPMN task, the function in your EPC needs to be assigned to an organizational unit:


This pattern-based approach enables the EPC2BPMN transformation to recognize the task type of EPC functions. And, this is only the beginning. In the future we would like to hand over additional implementation-relevant business information, e.g. data and business rules, from the EPC to the BPMN.

I hope that this overview on the modeling conventions for a smooth conversion from EPC to BPMN as the basis for our Model to Execute approach helped you understand the Process Transformation part of our Enterprise BPM approach.

Please let us know your questions or thoughts as comments. In the next post of this series, my colleague Katrina will introduce the next step: From Logical Models in ARIS to Technical Models in wM Designer

Stay tuned and Happy Easter!