Why AIS [ai]works Process Intelligence rethinks process analysis
In many companies, process analysis still begins in a surprisingly similar way. People from different areas come together in a workshop. In front of them is a whiteboard, a digital process map or a wall full of post-its. Then the joint reconstruction begins: What happens first? Who takes over next? Where is approval given? Which system is used? Where are the interfaces? Step by step, a process picture emerges that becomes increasingly complete and clean.
There is fundamentally nothing wrong with that. Process pictures are important. They help us structure complex workflows, make responsibilities visible and create a common language for change. However, it becomes problematic when we confuse creating a process picture with actual process analysis. Because a neatly documented process still says surprisingly little about how an organization actually works.
This is exactly why we at AIS advocate a somewhat provocative thesis at first: We should stop starting process analyses by drawing processes.
The reason lies in a simple human mechanism. If you ask someone, “How does this process work in your organization?”, you will usually get a plausible and structured answer. First A happens, then B takes over, then approval is given by C and at the end everything is documented in the designated system. This description does not even have to be wrong. It often describes very precisely how the process is intended, how it was documented or how it should function under ideal conditions.
For real process analysis, however, that is not enough. It becomes more interesting when we leave the abstract level and instead ask: “When did this actually happen last?”
Then we are no longer talking about the process in general, but, for example, about the last major investment decision, a specific procurement transaction, an unplanned technical failure, a budget overrun or a month-end closing in which information was missing. We go through this one case from beginning to end and try to understand what actually happened.
And suddenly the picture changes.
In this case, the information may not have come automatically from the ERP system after all, but as an Excel file by email. An approval may initially have been given by phone and only later documented in the system. Alongside the officially leading system, there is a list that is in fact far more relevant for the employees involved. A case may only have been resolved quickly because a certain person knew whom to call. Or an allegedly automated process only works reliably because someone regularly checks and corrects data manually.
For us, process analysis begins precisely at these points.
The actual organization is more interesting than the documented process
With AIS [ai]works Process Intelligence, we therefore reverse the classic logic of process recording. We do not first try to document a process flow as completely as possible. We want to understand how work, information and decisions actually interact in an organization.
That is why we do not start with the process, but with the business-relevant decisions.
This perspective matters because processes ultimately do not serve an end in themselves. A company does not collect data because data as such is valuable. The data is needed to assess situations and make decisions. A forecast is not created so that a forecast exists, but because capital is allocated, measures are prioritized or economic developments are assessed on that basis. An approval process does not exist because of the workflow, but because decisions are to be made in a controlled, traceable manner and with clearly defined responsibilities.
Our methodological principle is therefore: Decision before process.
We first ask which decisions are actually relevant for the result of a role or a function. We then select one of these decisions and reconstruct it based on a real case. How was the case triggered? What information was available at that point in time? What additional information had to be obtained? What courses of action were available? Who evaluated them? Who made a recommendation? Who was allowed to decide? Who had to approve? How was the decision implemented and how was its impact monitored?
During this conversation, the process emerges almost automatically. At the same time, however, significantly more information becomes visible. We identify which roles are actually involved, which data is needed, which systems it comes from, where information is transferred manually, which documents are required and at which interfaces waiting times or coordination loops arise.
The key difference is that these perspectives are not captured one after another in different workshops. Process, organization, data, systems and governance are examined simultaneously using the same real case. This creates a much denser picture of the actual working reality.
The process picture becomes the result rather than the starting point
A second consequence follows from this logic: the process diagram no longer stands at the beginning of the analysis. It emerges from the analysis.
At first, that sounds like a small methodological difference. In fact, however, it changes the entire way of working.
In a classic process recording, a model is created first. This model is then discussed and validated with the various participants. A large part of the energy therefore goes into the question of whether the picture shown is right or wrong.
With AIS aiWorks Process Intelligence, we take the opposite path. We look at several real cases from different role perspectives. We reconstruct decisions and workflows, compare statements with one another and identify commonalities, differences and contradictions. Only afterwards is the end-to-end process built from this information.
As a result, we spend less time discussing whether an arrow in the process diagram is in the right place. We discuss the underlying reality.
The process picture naturally remains an important outcome. But it takes on a different quality. It is no longer the result of a shared recollection of how a process should normally work, but a condensation of actual cases.
An interview alone is not yet the truth
However, it would be too simple merely to replace traditional workshops with AI-guided interviews. An interview, too, initially reflects only one perspective. People experience organizations from different points of view. What appears transparent and complete for one area may represent a significant information gap for another.
That is why another component of our methodology is systematic evidence review.
If, for example, an interviewee says, “All approvals in our organization run through the workflow system,” we initially treat this as a statement and not as an established fact. In the next step, we can ask whether an actually completed case can be reviewed. This may fully confirm the statement. But it may also show that urgent decisions are regularly made in advance by email or by phone and only subsequently documented formally in the system.
This does not mean that someone said something untrue in the interview. It merely means that organizations are more complex than their official process descriptions.
This logic becomes particularly valuable when several interviews are brought together. If, for example, an operational function explains that all open measures are visible to management at all times, while management reports that it often only learns about smaller measures through the monthly accounts, an analytically interesting contradiction arises. This contradiction is not used as a confrontation. It is reviewed neutrally in a further discussion or on the basis of existing documents and systems.
In this way, the interview series learns from one conversation to the next. The first interview produces not only results, but also questions for the second. After several conversations, recurring patterns become visible. Statements can be confirmed, qualified or disproved. Individual perspectives gradually form a consolidated as-is model.
This is exactly where AI changes process analysis
For us, the interesting use of artificial intelligence therefore does not lie in the fact that a language model can write interview records or create process diagrams more quickly. That would be helpful, but it would not fundamentally change the existing methodology.
The greater advance lies in the fact that AI enables an additional analytical layer.
An analysis agent can systematically track across a series of interviews which decisions have already been examined, which roles are involved, which systems appear and where statements by different interviewees diverge. It can identify that an interviewee is currently describing something abstractly, even though the analysis requires a concrete case. It can determine that a statement has not yet been substantiated by evidence. And it can generate from one interview an open review question that is examined neutrally in a later conversation with another role.
This changes not only the speed of evaluation. It changes the possible analytical depth.
Ten interviews do not result in ten conversation summaries that a project team then has to place side by side manually. The conversations can be transferred into a shared analysis architecture from which role and responsibility models, decision structures, end-to-end processes, system and data landscapes as well as interface and deficit pictures emerge.
This is exactly what we mean by AIS [ai]works Process Intelligence.
AI does not take over the professional assessment of a company. It does not decide whether an organizational peculiarity is sensible or inefficient. And it does not automatically define a future target process. Rather, it ensures that large volumes of qualitative information can be systematically structured, compared with one another and prepared for professional assessment.
The machine condenses. Judgment remains a consulting task.
This gives the workshop a completely new function
This changed form of process analysis has another consequence. It changes the workshop.
Traditional process workshops use a significant part of the shared time simply to establish a common understanding of the current situation. Experts explain to one another which tasks they perform, which systems they use and where they depend on one another. That is necessary, but at the same time it is an extremely expensive form of information gathering.
If the actual workflows have already been captured, analyzed and reconciled across different roles in advance on the basis of real cases, the workshop can start much further ahead. The current process picture is already available and only needs to be validated. Critical interfaces are known. Contradictions between roles have been identified. Points of friction are described and can, where meaningful, be quantified in terms of frequency, time loss, risk or economic impact.
This shifts the workshop from assessment to decision-making.
The decisive question in the room is no longer: “How does our process actually work today?” It can be: “Which of the identified deficits do we want to change, and what must the future process look like to achieve that?”
This is a key difference, especially for managers and highly specialized expert functions. Their shared time is no longer used primarily to exchange information that can also be gathered in individual interviews. It is used for the points at which joint weighing, prioritization and decision-making are actually necessary.
AI should still come only at the very end
As much as artificial intelligence can support the analysis itself, a clear sequence in process optimization is just as important to us.
We do not begin with the question: “What can we automate here with AI?”
We begin by understanding what is actually happening today and why.
A manual work step is not automatically inefficient. An Excel file is not automatically a problem. An additional approval is not necessarily unnecessary bureaucracy. All of these things can be symptoms of an underlying problem, but they can just as easily serve a professionally necessary purpose.
Anyone who jumps to the technical solution too early runs the risk of automating a symptom without having understood its cause. In the worst case, this does not make a poor process better, only faster.
That is why the sequence in AIS aiWorks Process Intelligence is deliberately clear: first, the actual working and decision-making reality is reconstructed. Then points of friction and their causes are examined. A future process can then be developed. Only on this basis does the question arise as to which work can be standardized, digitized, automated or supported by AI, and which decisions should deliberately remain with people.
So perhaps we still need to draw processes – just later
Process diagrams will remain an important instrument of organizational and process development in the future as well. They help us reduce complexity, make relationships visible and communicate future workflows.
We simply need to stop confusing them with the actual analysis.
A good process picture should not show what ten people were able to agree on after several hours at the whiteboard. It should reflect as precisely as possible how an organization actually works and decides: with its formal structures as well as its informal paths, with its systems as well as the Excel files alongside them, with its defined responsibilities as well as the dependencies that only become visible in the specific case.
That is why our position at AIS is not that we should no longer draw processes.
We should simply stop starting with them.
With AIS [ai]works Process Intelligence, we therefore understand process analysis not as the documentation of a workflow, but as the reconstruction of an organization's actual decision-making and working reality. Only once we have understood this reality can we meaningfully discuss what the process of tomorrow should look like.