Ariadne – a new chapter for Modell Aachen and orgavision!
Discover Ariadne
Imagine a relay runner trying to pass the baton, but the team hasn't agreed on exactly when that should happen. One starts too early, the other drops the baton. This is exactly what often happens in end-to-end processes when interfaces aren't clearly defined—one of the most common reasons why an end-to-end approach fails in practice!
The term "end-to-end" is mentioned more and more frequently in business contexts, yet not everyone knows what it really means. My colleague Phil Färbers hit the nail on the head in his article End-to-End Processes: What It Really Means : “An end-to-end process describes a workflow from the initial trigger to the final result, following the value stream rather than the organizational chart.”
Let’s ask the follow-up question that often comes up in process workshops: How do I map an end-to-end process in a management system so that everyone involved knows when it’s their turn? How do I clarify who passes the baton and when?
Since end-to-end processes are intended to highlight interfaces , the word itself reveals the solution: an interface is created wherever you make a cut. Whether it works depends on how precisely that process cut was made.
By cleanly breaking down the end-to-end process into sub-processes, which are then linked together, you create a comprehensive and complete picture of the process from start to finish and the associated sub-processes – both in the horizontal (end-to-end view) and in the vertical (deep dive into sub-processes).
The following graphic illustrates this exact interplay between the end-to-end view and the level of detail in the sub-processes:
Let's take an example: End-to-end processes like lead-to-cash span multiple departments: marketing, sales, finance. This is intentional, and that is precisely where their value lies. However, you cannot map an end-to-end process as a single mammoth process and then expect it to be followed in practice.
If end-to-end processes are not broken down at all, employees get lost in the big picture. A person who performs a sub-process daily does not need an overview of eight departments. They need clarity on what they should do and when, what happened before them, and who they need to hand off to. Dirk Stähler1 aptly calls these mammoth processes "functional process graveyards": documentation created for compliance that has no steering effect because it lacks the necessary segmentation.
To avoid this effect, documentation needs to be much more detailed and practical than is often the case, so that the process remains usable for employees and manageable for process owners. The goal of end-to-end process documentation is therefore to provide control for process owners on the one hand and create useful content for the roles and departments executing the tasks on the other.
To distinguish between those who are responsible and those who are executing, the RACI model by Smith, Erwin & Diaferio is helpful2. This model uses four classifications: Responsible, Accountable, Consulted, and Informed.
According to RACI logic, the process owner fulfills the role of Accountable. This person is solely responsible for the decisionsmade to change and optimize the process. Important: We are talking about one person, because experience shows that when multiple people are responsible, no one feels responsible.
As the name suggests, the executing roles refer to the people who are actually involved in the implementation (Responsible). The model uses Consulted to refer to potential stakeholders who provide subject matter expertise during the process decision-making stages. And Informed refers to the groups of people who do not play an active role in the process, but rather hold a supporting function.
Now that the question of responsibility has been clarified, back to the core topic: If end-to-end processes lack a foundation of cleanly defined sub-processes, they become nothing more than a facade. This means that while we may have a nice overview of the overall process, we cannot extract any usable information from the sub-processes because they contain multiple responsibilities, gaps, or ambiguities.
The good news: Clean segmentation and end-to-end thinking are not contradictions, but two sides of the same coin.
Departments often think in silos rather than in process chains. Every department documents "its part" – which is the first important step! However, interfaces with other departments are often left undocumented because they are viewed as someone else's responsibility or have not been clearly defined. This frequently leads to end-to-end processes being segmented incorrectly or not at all.
The boundary between two processes lies where the core business object changes – a lead becomes a quote, and a quote becomes an order.1 As long as the same object is being worked on, it belongs in one process.
What sounds clear in theory can be implemented structurally, for example, directly in Ariadne. The end-to-end process can be visualized very effectively using a process overview . This helps to identify messy interfaces and correct them later in the relevant sub-processes.
If the graphic only depicts a portion of the end-to-end process, a link to a complete view is a good option. In the end-to-end view, you can then jump into the individual processes. As a rule of thumb, we recommend a process size of 10–12 steps. This can look like this in the process overview:
It is important that the sub-processes function as independent, cleanly defined units and are connected to preceding and subsequent links within the other processes and the entire end-to-end process.
Take a look at your process documentation and answer the following questions:
Conduct an end-to-end interface workshop as a targeted format for uncovering gaps. This is particularly suitable for departments where there is ambiguity regarding interfaces. This ensures that the baton isn't dropped during the next handoff, but is passed on smoothly.
1) Stähler, Dirk (2019). End-to-End-Modellierung im BPM: Wie ein stabiles Prozessmodell entsteht, Computerwoche
2) Smith, M. L., Erwin, J., & Diaferio, S. (2005). Role & Responsibility Charting (RACI), Project Management Forum
Sign in to get in touch with Carsten directly.
We are happy to provide you with inspiring content, current events and news.
