Anyone working in process management with process houses and end-to-end chains knows the moment: someone says that this process does not even exist here. And two seconds later, someone else has found it anyway. This is not a coincidence, but brain research. Templates demand to be confirmed, and our brain delivers.

The way out is a sequence. Process house, APQC, and Order-to-Cash serve for orientation: Where do I need to shine the light? After that, every template is discarded and every process is described as it actually runs. Via input and output, a process network is created—the real current picture. Only then do you overlay chains. And you are free to choose them.

"Please do not think of an elephant now." This famous sentence shows as impressively as almost no other how our brain works. It is impossible not to think of an elephant when hearing this sentence. Our brain wants to confirm every template it receives. Whether we see, hear, or smell it does not matter. It makes it our reality, and it does so unchecked. The same applies to process management.

In every process workshop where process houses are used, this sentence is uttered at some point. An internal sales administrator says, half-apologetically: "We don't actually do that." Two seconds later, the second sentence comes, usually from further up the table: "Well, somehow we do, kind of." With enough interpretation, it is therefore possible to recognize that what the process house prescribes does indeed happen in practice. How could it be otherwise. The process house—that is the elephant. And as soon as we mention the elephant, you will think of why you have it too. That's just how it works in our brain. If you give the brain a template, it is constantly busy with how it can confirm the template in reality. Humans bend to the template, put their own perception in the background, and squeeze it into the given framework.

Too generic or too narrow

End-to-end process chains such as Order-to-Cash or the classic process house with management, core, and support processes: these are the typical candidates for templates. The legitimate objection to this is: It is completely fine to think of an elephant when someone says elephant. That is exactly what it is about. And of course: If the process house says "Acquisition", then every company has a sales department that recognizes itself here. So far, there is nothing real that is being squeezed into a template.

But as appropriate as it is that every company carries out acquisition, this statement is just as generic and irrelevant. On this level, it is true: template and reality match one hundred percent because the template is so generic that it must be answered in the affirmative in any case. "Water is wet" and "it is dark at night" are about as specific.

However: on this level, the template rarely helps. At first, it looks like a generic textbook illustration. So you drill deeper and look at the sub-processes that belong to it. A classic Order-to-Cash flow includes, for example, quotation creation, shipping, and the invoicing process. This is where it gets more detailed. But with the increasing level of detail comes the increasing deviation from how processes are actually lived and linked in the company. Perhaps there is no shipping at all because the product is a service. Where is the project implementation reflected in this flow? Is it part of it or somewhere else? "In a way, we do ship a bit. By implementing the projects at the customer's site," person 2 from the fictional workshop would say now. And already you start to squeeze your own reality into the template.

You see: templates have a disadvantage. Either they are generic and abstract, so that everyone can agree, but they offer little orientation. Or they are specific and concrete, which leads to the fact that you don't really find yourself in them anymore and start to squeeze your own reality into them. After all, in such a workshop, no sticky note must go unused.

This is the major weakness of top-down process architecture.

Two design flaws inherent in the process house

In the process house, two more weaknesses are added. The first is deep within the model itself: it mixes two things that do not belong together. It simultaneously shows how a company runs and how it is structured. The core process flow is a sequence of events; it is oriented along the central value chain: acquisition, production, delivery, service. One after the other. The support processes, on the other hand, are not a sequence at all, but units: purchasing, quality management, HR, marketing, to name a few. They say who does something, but not when and for what purpose.

Because these two dimensions are mixed together in one picture, it is almost impossible to dive coherently into a deeper level. Why, for example, in a long-term planned project business or in make-to-order manufacturing, should quality management not be a central part of the core process flow?

The second problem lies within the division itself. Whether a process belongs to the core, whether it supports, or whether it manages is renegotiated at every level. Of course, production is a core process. But within production itself, there are sub-processes that can in turn be classified according to core, support, and management criteria. Anyone who stops at level 1 will run into allocation problems. Does the capacity and staff scheduling done in HR belong to the core of production? Or does it only support? In any case, without this support, production is not possible at all.

End-to-end flows want to provide the answer to this. They resolve both problems better and remain only with the template problem mentioned above.

How do you actually work with process houses and end-to-end chains then?

Not as a blueprint. But as orientation, and exclusively as orientation. In practice, a process house should only answer a single question: In which corners do I need to shine the light to make absolutely sure that I capture all the processes I want to document with a 360-degree view?

For this question, it is helpful to think in process houses or in end-to-end chains like Order-to-Cash. Frameworks like the APQC Process Classification Framework are also helpful. And exactly at the level to which the APQC breaks it down. The template does not need to go any deeper. Once the overview is established, it has done its job.

First shine the light, then forget

And from the moment you have this overview, the uncomfortable part begins: first, discard every mental construct about the connections between the identified processes. Everything you have set up regarding sequences, affiliations, and chains. Why?

Firstly, because the contents of the processes are so different. Two companies both have a quotation creation. In one, this is a form and a signature; in the other, it is six weeks of calculation.

Secondly, because how the chains actually run is different in every company. Order-to-Cash is a concept, not a sequence. Who hands over what to whom and when, where the chain stalls, and where it takes a shortcut is not written in any reference model.

Thirdly, because within the chains themselves, processes have already been illuminated with the flashlight, where people say: "Ah, we don't have that one at all. But instead, we have another one that didn't appear in the chain at all." Exactly this sentence is the actual yield of the exercise. In a top-down logic, it is considered background noise, and person 2 from the other end of the table will catch it again two seconds later.

And fourthly, because at every level I dive deeper into, the question of core, support, and management is renegotiated. On level 2, a process might be a core process. If I dive into it, it has strategic, supporting, and value-adding elements. And a level deeper again.

At the activity level: Stop

Once you have arrived at the activity level, the rule is: forget every template. Now, all processes are first described as they actually run. Who needs which input when? What do they do with it? And what output do they produce? Completely free and without a template. No allocation, no chain, no category. No elephant.

That feels untidy, and that is exactly the mark of quality. It is the only moment in the entire project when you see your company and not the picture you planted in your head beforehand.

When all of this is documented, you work your way back to the real chains on your own. And not to those prescribed by the template.

Every input has a sender

How does that work? Every process works with inputs that either flow into the organization from the outside or are created within the organization. From this follows a sentence that sounds like a truism and is in truth a design principle: Every input from the organization must be the output of another process.

Step 1: Connect all inputs and outputs with each other, across process boundaries. This does not result in a house or a chain, but in a network. Your entire process network. This is exactly your real current picture.

Step 2: Now you start to use a template again. Which process on level 3 is management, which is core, which is support? Which process do I want to include in which chain? These are exactly the initial questions. Only this time, you do not bend reality to the template, but overlay the template onto reality.

Why MECE no longer applies here

It happens that a process is fed with inputs that come from processes of a completely different chain. This triggers an uncomfortable feeling because it contradicts the logic of the template. The template works according to the MECE principle: mutually exclusive, collectively exhaustive. Or in simple terms: each chain stands on its own, and all chains together describe the entire company.

In reality, however, it is possible for a process to be so elementally at the center of the network that it is part of several chains. Anyone who splits it up so that the drawing works out has let the template win.

Anyone who has understood that MECE does not apply to chains overlaid on a network now also has more room to maneuver. They can design the chains in a way that helps them individually. Perhaps I do not want to link end-to-end flows of the value chain at all, but process scenarios for business units. Then the sales chain from Unit 1 looks different from the one for Unit 2. And that is not an inconsistency, but the very point.

Because a chain is not a truth about the company. It is a view of the network that actually exists. And views can be changed. It is best to tear down houses immediately.

How we solve this at BLIKS IO

This sequence cannot be maintained by discipline. It must be built into the tool. That is why BLIKS IO works in exactly three steps.

First: capture the real current state. Process by process, on level 3, just as it actually runs. Who gets which input, what do they do with it, what output do they generate? Without a chain, without a category, without a tile.

Second: link. Every output is connected to the input it feeds, across process boundaries. Individual process descriptions become a network. Not drawn, but emerged.

Third: chain. Only now do we group processes into process chains and sub-chains. Just as the organization needs it: along value creation, along a business unit, along a standard.

The crucial point is in the details. The input-output links remain intact across chain boundaries. A process fed from another chain does not lose this connection just because it was sorted in somewhere. The template may organize. It must not cut anything off.

The elephant does not disappear in the process. It cannot be ignored—that is precisely its trick. You can only put it in the right place: at the beginning, as a question of where to shine the light. And at the end, as an organization for what you have found.

In between, where the actual work is done, it has no place.