Implementing change effectively

Process managers often feel let down by management because individual managers for their departments keep "getting away with " circumventing agreed processes. After the initial euphoria, management attention to process management projects often falls asleep. Once the models are in place, nothing happens. In the following, we will look at how process managers ensure that BPM projects survive in day-to-day business and keep everyone on board during change processes.

What BPM projects are about

When BPM projects fail, it is often due to unclear expectations. Process management projects are often equipped with the mission "to introduce process management". However, process management is not a goal, but a set of methods; without a goal, however, it becomes difficult to mobilize the necessary "management attention" for the BPM project. Of course it makes sense to use professional management methods in the company. And of course it takes more effort at the beginning to anchor the know-how and the basics of the methods in the company. That's why it seems as if a BPM project is all about introducing BPM. But appearances are deceptive. It is about solving concrete organizational problems: The closing ratio in lending is too low, the scrap rate in production is too high, new software is to be introduced and so on. Often, separate project groups exist for the solution of these problems parallel to the BPM project - in the worst case, even in competition with it.

Why BPM projects fail

BPM projects often have to live with waxy goals: "We want to learn to think in processes," they say. "Create process awareness," is the demand. Often, the process model is also sold as an organizational goal - as if the model itself would already have some effect. Those who have to work with such goals are on the losing track from the start. If, on the other hand, the mission is to solve a specific problem, the project gets a tailwind.

Mistake number two is the mistaken belief that you can change reality with modeled processes. Just because a process model is released, people do not stick to it. Even if the song of praise of clear instructions and consistent sanctions is rehearsed in leadership training, changed processes cannot be "prescribed". This misconception is particularly insidious when process changes are cast in software. If the software only provides the "right" fields and decision options, then people have no choice but to operate the process "correctly". Even the best software gets stuck "in the roll-out" if the users don't want it.

Process managers reduce their risk of frustration if they say goodbye early on to a few illusions that have become widespread in the BPM literature. Illusion number one: "Processes can be managed - you just have to do it right." In reality, processes are social systems (like all organizations), and unlike mechanical systems, they cannot be controlled. You just can't diagnose the "fault" and fix it by instruction like you can with a machine. So anyone who experiences how adopted process models degenerate into wastepaper can take comfort in the fact that they are in the best of company (an admittedly weak consolation).

Second, tightly coupled actions are not natural. If one person performs the same workflow twice, they are unlikely to do it exactly the same way. If two people perform the same work, the probability is even lower. So the fact that a process in an organization follows the same fixed pattern over and over again is not to be expected per se - the opposite would be normal. And just because there is a process model, this tendency is not simply reversed.

Need as a motor for change processes

So you can't move processes at all? Yes, you can. But we need to understand the rules that make this possible. And these have to do with the ability of organizations to learn. Organizations learn when they replace (previously) functioning communication structures and processes with others. They do this (as do individuals) only out of necessity. Namely, when they no longer get what they actually need: for example, when customers are no longer willing to pay the required price, when the public makes demands on emissions or social standards, when owners formulate different return expectations, when corporate headquarters prescribes the use of different software, and so on. If there is no need, nothing happens.

This is the crux of change management: those responsible for the process must present the need for adaptation in a suitable form - so that all relevant people understand it and it is discussed in the important committees. Many a company management has made a mess of this: Large staff meetings, PowerPoint presentations with lots of charts and a lot of business-speak that nobody understands.

Allow different perceptions of processes

In this way, process managers can help to bring the important issues into the communication: They make the processes and their environment visible - that is, the "customers " of the process and their expectations. They show how different or uniform a process looks in the organization. If people experience the process differently, this becomes clear. The goal is not to model a syntactically correct and uniform "as-is" process as quickly as possible. Rather, the goal is to bring real life to the table in an uncensored way. And as improvised and inconsistent as it is. Improvisation and variations are not bad per se - many processes only work thanks to these subtle structures. In contrast, when the expectations and demands of the environment are discussed, the need for adaptation is on the table. Now - and only now - can we talk about change. But how to model such a process? Everywhere there are variants, if-then's and details that seem important to individual participants, but which take place at far too low a "flying height" for the process manager. The art is to perceive this information, to appreciate it, to give it a place in the model - without modeling it! Lest there be any misunderstanding, it's not about taking information and writing it somewhere just to get people to shut up. It's about reflection. The actual process model can only serve to roughly organize all this information. It is useful to first record a "logical process model" that lists only the theoretically necessary steps and milestones from start to finish. This model is an excellent "carrier" for all kinds of analog information.

Communicative process modelling without prohibitions on thinking

This form of process modeling is a creative and communicative process. A modeling program on the beamer screen would stifle this creativity. Better is a wide table with a wipeable slide and BPMN elements to lay and move. Sequence and message lines can be erased and redrawn at any time, and all the analog information is simply written on the table. There should be no inhibitions to communicating about the process! The facilitator also needs a smartphone and a selfie maker. This can be used in between to freeze the current state of the discussion on the table. The selfie maker is needed to position the camera high enough above the table. This way, you get the whole process on the picture without having to compose several photos.

Formal framework for analog process knowledge

Despite this analog form of moderation, it makes sense to use the fixed standard Business Process Model and Notation (BPMN) for modeling. The BPMN model structures the many additional analog information. In addition, we use the special strength of this standard: Here it is possible to model the relationship between a process and its environment. No other modeling language distinguishes between "occurred " events (we wait for something to happen "out there") and "triggered" events (we give something to the world). The pools in the model show which processes communicate with each other and how - the message lines between the pools denote mutual expectations. Those who are well versed in the standard also use the event subprocess to capture contingencies and special cases in the process model, without the model immediately bursting all bounds.

Recognition enables change

The result of this modeling is a rough process model with a lot of annotations and additional information. Correct syntax for BPMN purists is a minor matter. Perhaps there are even several different models, because different stakeholders see the process quite differently. It is not about the model, it is about modeling. This model reflects the actual "as-is" process: its inconsistencies, its fractures, its unfulfilled expectations, its inefficiencies, but also, for all its improvisation, its amazing functionality - and that is what needs to be appreciated: It is the enormous achievement of the process and all those involved that despite all its inconsistency, it somehow works. The classic "as-is process modeling" with "weak point analysis" stifles the willingness of those involved to change. The appreciative recognition of a process is the key to getting people to deal with the construction sites and to constructively search together for a process - a "target process". So the real challenge for change management is not to come up with the better process. What it's really about is the willingness of everyone involved to embark on the search for it together.