In the third part of my tip series for business process management, I would like to address a few key points about process modeling and process design. Since forming in any BPM project at least one process model, the foundation stone of the project is extremely important that the quality of process models is also fair.

Tip 1-3 are in the first part and Tip 4 - 7 are in the second part of this series to find

8th Working in layers

Unfortunately, we see far too often, process models, the different levels mixed together. This then leads to the fact that the models are complex and difficult to read. Both the IT department and the business departments can not use the model. And the management does not understand what you are talking about basically.

To solve these problems it is useful, the models assign different levels of the model. That sounds easier than it is. Even seasoned analysts Process catch yourself slipping ever again it himself in the wrong level. What level model now wants to use is one left to themselves, more importantly, it is the levels clearly distinguished from each other. Only then can it be ensured that each process can provide an analyst to create a model for a layer. Generally, interest is generally three levels:

1. Overview level
2. Business level
3. Technical level

In the overview level, the process is shown to be, roughly, is hereby meant no process map. This presentation should be very compact and contain the key information. The overview model thus not exhaustive, but you can see at a glance which are handled by the process.

The business layer contains all technical activities and processes. Here it is often difficult to even hide the IT. Often combine IT people to side with certain steps an IT system. This connection should be dissolved as possible. Important here all technical activities that add value are generated in the process. Here is a review of important, but also discipline, so they continued to question whether we modeled the correct level. Using the process description of the technical level, a staff work through the processes.

The technical level, then joins the business level with the IT systems. This may have some activities will be supplemented from the business point of view was not necessarily relevant (eg Persitierung, logins, log files, etc). The various professional activities here are mapped to IT services and technical details are stored. Importance of this level is not too far removed from the business level to be, ideally, the process models are not identical and only the "background information" to change. This is the alignment between IT and business much easier and reduces the cost of changes to the process.

9th KISS

In my article " The rabbit problem "I have shown how quickly a simple process but quickly begins to grow and remain clear. Therefore, one should always try the presentation as simple and short to keep. The does not mean that it is easy to create a simple model! Goethe said one thing. "Sorry about the length of the letter, I had no time to be brief," This is the same also applies to the modeling process. A process to facilitate such an extent that all necessary activities and events are available, but the process is simple and easy to take time and experience. The less experience you have, the more time you will need.

10th Happy Path

The Happy Path is still usually the goal. FYP is called here the Key Performance Indicator: First Pass Yield ., the FYP describes the percentage of all process instances that could be processed in the first run successfully. So all the process instances that have required only the happy path. A common goal is to maximize the FYP. Therefore, it is also useful to model the happy path first, and not to start with the exceptions. But, unfortunately, are exceptions to the mandatory in the process model must be present. However, check whether the exceptions may not be through preventive measures may even exclude completely. This will increase the FYP and the process model is clear.

11th Little logic in the model

Why logic is as little as possible into the process model? The background to this statement is the purpose of a process model. Describe the model should be run when the activities. It therefore has a strong focus on the activities. Decisions are often presented in complex formulas or decision trees. This can naturally represent the Board means the BPMN into a process model, but this would make the process models to swell enormously and confusing. The logic that are found mostly in the business rules (business rules) should therefore be outsourced. For this to their own business rules engines. For a change to existing business rules, for example if a customer pays from 50 € or 100 € no shipping cost does not change the course of the process itself. If this logic should be included in the process models to change in any rule change, the process model, although the changes have no effect on the actual end of the process have. By outsourcing the logic so it saves time not only remain in changing the rules, the special process models are also easier to read.