How the Elephant Finder finds what everyone knows – but what is not stated in any process manual
The most interesting sentences in a process interview often begin with a single word: “Actually.”
“Actually, this runs via SAP.” “Actually, this process is fully automated.” “Actually, there is a clear approval rule for this.” Or: “Actually, all information is in the system.”
It usually becomes interesting immediately afterwards.
Because after “actually,” the real working reality often follows. Then we learn that an Excel file is also maintained because the information in the system is not complete. That in urgent cases, an approval is initially given by phone and only documented later. That a process may be technically automated, but only works because an employee regularly checks manually whether the data is correct. Or that there is a person who officially does not have any special role in the process, but without whose knowledge important procedures would regularly come to a standstill.
These are exactly the moments that are of particular interest to us at AIS [ai]works Process Intelligence. Because they often do not simply show an error, but the difference between the formal organization and the lived organization.
And that is often exactly where the elephant sits in the process.
Many process problems have long since become normal
The difficult thing about these elephants is that those involved often no longer perceive them as a problem. People and organizations are remarkably good at finding solutions for things that do not work structurally. If a system does not provide information, an Excel file is created. If a workflow is too slow, people call in advance. If responsibilities are not clearly defined, at some point a person emerges who simply knows how it works.
Such workarounds are often sensible at first. They keep the organization operational. Over time, however, they become part of the normal process. After a few years, no one often remembers why a particular additional step arose in the first place.
That is exactly why the classic question “Where do you have problems?” is often not enough for a good process analysis. The most interesting deficiencies are not mentioned because they have long since become self-evident.
The Excel list is then no longer a problem. It is simply part of the process. The three coordination loops have always been necessary. And the fact that someone has to be called again before an important decision has become so normal by now that it might not even be mentioned in the conversation.
The Elephant Finder therefore does not try to collect as many pain points as possible. It looks for the small signals that make it visible that the official process and the actual sequence may diverge.
The Elephant Finder initially just listens more closely
What is important here is this: A sentence such as “Actually, it runs automatically” is not yet a finding.
Perhaps it actually runs automatically in 98 percent of cases. Perhaps the additional Excel file makes sense from a functional perspective. Perhaps an informal coordination is even more efficient than the intended formal process.
That is why the Elephant Finder is specifically not intended to diagnose prematurely.
It initially just listens more closely.
When someone says “normally,” “as a rule,” “officially it is like this, but ...” or “when everything works ...,” this initially only creates an indication. The analysis then returns to the specific case: How was it in the transaction we are talking about right now? What actually happened there? What impact did the deviation have? Why was this additional step necessary? And can this be verified on the basis of a real transaction, a system extract, or a statement from another involved role?
This is how a robust picture emerges step by step. Not directly from the striking sentence to the solution, but from the specific case via effect and cause to the evidence.
That may sound like a small difference. Methodologically, it is decisive. Because consulting, too, can be subject to confirmation bias. Anyone who believes after ten minutes that they have identified the cause of a problem will find a surprising number of arguments in the rest of the conversation that confirm exactly this assumption.
Good Process Intelligence must therefore not judge as quickly as possible. It must verify better.
An apparently small media discontinuity can become a governance issue
How relevant this deeper analysis can be is shown by a simple example.
Suppose we are analyzing a procurement process. One interview participant explains: “Actually, there is a form for this, but if it is urgent, we usually send an email.”
In a classic process capture, this could become a media discontinuity: form process versus email. It ends up on a list of optimization potentials and may later be accompanied by the recommendation to digitize the process more strongly.
But the more interesting part only begins with the next question: Why is the form not used in urgent cases?
Perhaps the answer is: “Because otherwise we lose about two days.”
Why do these two days arise?
“Because the form first has to be approved internally.”
And the email does not require this approval?
“It does. The approval is then made up later.”
Suddenly, we are no longer talking about a form, nor about a simple media discontinuity.
We are talking about the fact that a formally upstream approval apparently regularly takes place after the actual decision.
That is a completely different quality of insight. Behind it may lie governance issues, incorrect approval logics, excessively long throughput times, or simply a process that does not fit operational reality.
So the elephant was never the email.
The email was only the signal.
The really big elephants often emerge between the interviews
This methodology becomes even more interesting when not just one conversation is considered.
Suppose that in Accounting we learn that a separate Excel file is used for a certain management object. Taken by itself, that does not necessarily have to mean anything. A few interviews later, Controlling explains that it also maintains its own list. Operations, in turn, works with a different file. At the same time, IT assumes that the ERP system is actually the binding data source for all parties involved.
Then the question changes.
The finding is no longer: “Several Excel files are being used.”
The actual question is: Does this organization even have a jointly accepted system of record?
A systemic pattern emerges from several local anomalies.
This is exactly where we see one of the major levers of AI in process analysis. Not in the fact that a language model transcribes interviews faster. But in connecting statements, anomalies, contradictions, and open questions across a series of conversations.
A single good consultant can conduct an excellent interview. It becomes more difficult in the tenth conversation to simultaneously keep in mind every side remark from interviews two, four, and seven and, at the right moment, derive the appropriate neutral follow-up question from them.
An analysis agent can establish these connections in a structured way. One interview thus not only generates insights about one role. At the same time, it also generates review tasks for the next conversations.
The analysis gains a project memory.
Not every elephant has to disappear
Nevertheless, the professional assessment remains decisive.
If four functions describe the same process differently, this does not automatically mean that one of them is wrong. Perhaps there are different variants for different business cases. An additional control may be inefficient, but it may also be mandatory for regulatory reasons. And an informal process may represent a deficiency – or simply be an expression of the fact that the formal organization has not yet caught up with the actual work.
AI can make such patterns visible, compare statements, and mark contradictions. But it cannot automatically decide whether an organizational peculiarity is sensible, necessary, or inefficient.
That is exactly why we do not understand AIS [ai]works Process Intelligence as an automated consulting machine. The technology condenses information and increases analytical depth. The assessment remains a consulting task.
This also applies to later optimization. Only once an Elephant is actually confirmed are we interested in its impact. How often does the issue occur? What waiting times arise? How many people are affected? What risks or economic effects result from it?
Because a good process analysis should not end with the longest possible list of problems.
It should identify the few issues that are truly relevant.
Good process analysis does not find more problems. It finds the right ones.
That is exactly the idea behind the Elephant Finder within AIS aiWorks Process Intelligence.
We do not want to prove that processes work worse than assumed. We want to find out how they actually work. This includes the documented process just as much as the informal paths alongside it. The leading system just as much as the Excel file that everyone ultimately trusts after all. The formal responsibility just as much as the person without whom practically no decision works.
That is why the decisive insights are often not found in the process manual.
They are hidden in small deviations, subordinate clauses, and things an organization has long since become accustomed to.
And sometimes the most important sentence in an entire process interview therefore begins with a completely harmless word:
“Actually ...”
When this word comes up, it is worth not jumping straight to the next question.
Perhaps that is exactly where the elephant sits.