Using guidelines and conventions to establish broad understanding

Departmental workflows that do not participate in an enterprise BPM program but are developed in isolation differ in one regard dramatically from enterprise BPM. They have been created in one small team. This implies that whenever somebody needs to understand certain aspects in the business process, they know its author and can approach him in informal ways via e-mail, telephone, or just walk up to his desk.

What happens if we apply the same type of modeling and collaboration to enterprise-level business process management?

Typically, we will spread that modeling work over different teams in a way that for a given moment in time, each team or group will work on one process model.

Inside each of these groups, a certain joint understanding establishes itself over time. Members will invest time and thinking in finding a way to express the complex aspects of the process using their own ways to structure it and name activities and data types inside their team. In other words, the group establishes their own language.

This is exactly the way departmental workflows have been developed in the past. The issue with this approach will become obvious when we think about what happens if members of group B, that is, from outside group A, attempt to understand the business process created by group A. In a way, this is similar to a Frenchman attempting to understand a sentence written in the German language. In order to grasp its meaning, he has no chance but to learn German. Therefore, the most important advice for any organization starting the journey on enterprise BPM is to tackle the void that is left when we do not know the author of a model or even a piece of code anymore. We have to find ways to establish models, vocabularies, and requirement documents that are self-explanatory.

For process models that work on complex structures, this can only be achieved by means of a consistent set of modeling guidelines and conventions.

Figure 15: Standardization and homogenization of the solution benefit its success and acceptance

The governance model makes sure that each process model follows these conventions by passing through its quality gateway. This can be a set of critical conventions that need to be checked off by a dedicated process quality team. Establishing modeling standards that define structural and naming conventions is a prerequisite for standardized models that are consistently and easily understandable since they follow the same patterns.

Here are some examples of conventions:

• Names for roles in BPMN pools and lanes
• Names of verbs
• Names of nouns
• Version
• When exception, when variance
• When subprocess (inline and distinct)

BPM and SOA governance can help to ensure that these guidelines and conventions are consistently followed.

The BPM methodology introduced in the chapter is depicted in the following image. Its key feature is a well-defined relationship between activities on a strategic level, near the board of executives to steer the organization through times of change and on a local level, where actual people interact with systems and each other along the lines of a well-understood business process. In the strategy section on the enterprise level, BPM Suite 12c offers the first features to tackle the key activities that we discussed earlier. Here, we model the process hierarchy down and adorn the most fundamental KPI, based on which the organization wishes to measure its performance.

The redesign section of the methodology looks at concrete processes using concrete means that real people and services or systems are involved. Here, we analyze the AS-IS state, define the TO-BE state, and implement it as a executable BPMN process. There is an ongoing activity that looks at and manages all processes on a corporate level and decides, based on their performances, which of them should be run through the process redesign cycle again.