Why real cases, evidence and cross-checks turn opinions into robust process analysis
“For us, this is fully standardized.”
Fine. Show me the last case.
This small follow-up changes a surprising amount. Because an interview is not yet a process analysis. It is, first of all, a collection of statements about how people perceive their organization, their tasks and their processes. These statements may be entirely correct. But they may also show only part of reality, overlook an exception or confuse a formally defined procedure with the actual way of working.
This is not a criticism of the interviewees. It is simply a characteristic of complex organizations. Anyone who works every day in a specific area inevitably develops their own view of how that area functions. The operational unit sees handovers and specific cases. Management sees decisions and results. IT sees systems and data flows. Controlling sees figures, deviations and reporting. Procurement sees orders, contracts and approvals. All of them can describe the same process and still arrive at different statements, without anyone deliberately saying anything incorrect.
That is precisely why conducting good interviews is not enough for a robust process analysis. What matters is what we do with the answers afterwards.
At AIS [ai]works Process Intelligence, we therefore initially treat a plausible statement exactly for what it is: a statement. If someone explains, for example, that all approvals run through the workflow system, we do not automatically adopt this information as objective process reality. We ask about the specific case. Can we look at a completed case? Where is the approval documented? When was it actually granted? Who made the decision? What information was available at that time?
The statement may be fully confirmed. Then we have turned a description into a much better substantiated finding. But it may also become clear that urgent cases are first coordinated by phone or email and only later formally documented in the workflow. In that case, the original statement was not necessarily wrong. The workflow system may very well be the official documentation instance. Only the actual decision logic is more complex.
And that is exactly the difference that interests us.
Statements must become insights
In traditional process projects, something quickly happens that initially seems harmless. One person says in an interview: “The process is standardized.” A few weeks later, the presentation says: “The process is standardized.” A personal description has unnoticed become a fact.
The larger a project becomes and the more interviews are conducted, the harder it becomes to keep track of the origin and robustness of each individual statement. Was this point substantiated by a real case? Did multiple roles describe it the same way independently of each other? Does it come from just one interview? Could it even be an interpretation by the interviewee or a hypothesis from the consulting team?
These differences must remain visible. Because a robust as-is model does not emerge from collecting as many statements as possible. It emerges from knowing what quality these statements have.
That is why evidence is, for us, an integral part of process analysis. A completed case, a system extract, a documented approval or a work instruction has a different evidential value than the memory of a single interviewee. Multiple independent roles that consistently describe the same procedure also increase robustness. Conversely, a statement that so far comes from only one person may remain marked exactly as such.
At first, this sounds like a methodological detail. In fact, it changes the analysis fundamentally. Because we no longer try to produce a single clear truth from every conversation as quickly as possible. We allow uncertainty. A hypothesis may remain a hypothesis. An open question may remain open. And a contradiction does not have to be resolved immediately either.
Contradictions in particular are often especially valuable.
Let us assume that an operational function explains in an interview: “All open actions are transparent to management at all times.” A few days later, management says: “We often only learn about smaller actions through the monthly reporting.”
Who is right?
Perhaps both.
The operational unit may understand transparency to mean that every action is technically documented somewhere. Management, by contrast, understands it to mean that it has a complete and up-to-date overview. Perhaps major actions are communicated immediately, while smaller cases only appear later. Perhaps there are different process variants. Or perhaps a relevant information gap has in fact emerged.
A good analysis approach does not immediately declare one of the two statements to be wrong. It uses the contradiction as the starting point for the next insight.
The next interview knows more than the first
This is where the cross-interview mechanism comes into play for us. One conversation does not stand in isolation. Insights from one interview generate new questions for the following conversations.
This is explicitly not about playing people off against each other. In the next interview, we would not say: “Operations claims that you see all actions. Is that true?” A question like that immediately creates defensiveness and shifts the conversation from the factual level to the relationship level.
Instead, the contradiction becomes a neutral validation question. For example: “Where can you currently see, in a binding way, which actions are still open?”
That may seem unspectacular, but methodologically it is a major difference. Because we test the same issue from a different perspective, without disclosing the source and without already implying an answer.
That is exactly how an interview series begins to learn.
The first conversation is still relatively exploratory. We want to understand roles, decisions and real procedures. After a few interviews, initial patterns emerge. Certain topics come up repeatedly, statements overlap or contradict each other. Later interviews can therefore become more precise. The questions change with the project’s state of knowledge.
If five conversations have produced different answers to the question of where open actions are maintained in a binding way, then in the sixth conversation it is no longer particularly helpful simply to ask: “How do you track open actions?” We can ask much more precisely: “Where do you see, in a binding and complete way, the current status of all open actions – and which source is authoritative in case of doubt?”
The sixth interview therefore does not start from zero again.
It already carries within it the open questions from the first five.
This is precisely where we see one of the decisive advantages of AI in process analysis. Not in transcribing conversations faster or automatically writing a summary. That is useful, but not the real leap.
The greater lever arises from building a project memory across many interviews.
An analysis agent can trace which statements have already been confirmed, which so far come from only one perspective, which contradictions are still unresolved and
which points should be validated neutrally again in a later conversation. It can identify that three areas describe different systems as the leading one or that an approval worked differently in several real cases than formally described.
This means interviews do not become ten separate conversation records. They become a shared analytical data base that becomes more condensed with each conversation.
That is exactly what we mean at AIS [ai]works Process Intelligence when we say that conversation memory becomes project memory.
Contradictions are not a flaw in the analysis
However, it would be dangerous to interpret every differing interview result immediately as a deficiency.
Organizations need differences. Not every process has to work the same way everywhere. Small investments may require different approvals than large ones. An incident requires a different escalation path than a planned action. Different companies or business models may, for good reasons, have different process variants.
If two roles describe the same procedure differently, the right question is therefore not immediately: “Who has the wrong process?”
The better question is: “Why does this difference exist?”
Perhaps we have discovered a professionally meaningful variant. Perhaps a special case. Perhaps an informal workaround. Or perhaps a genuine accountability gap or a process that works differently in practice than intended in the governance model.
Only this classification turns a contradiction into a relevant insight.
And this is exactly where the human remains decisive.
AI can identify very well that statements do not fit together. It can compare a real case with other cases, generate open questions and make patterns visible across multiple roles. But it cannot automatically decide whether a specific deviation is organizationally meaningful or inefficient, whether an additional approval step is regulatorily necessary or whether a process variant should be retained from an economic perspective.
The machine can condense reality much better.
The judgment remains consulting.
For us, this is an important boundary of AIS aiWorks Process Intelligence. We do not want to create an automated consulting machine that claims to have understood the organization after ten interviews. We want to enable an analysis in which the consultant receives a much more robust information base before making assessments together with the client and developing target processes.
An interview does not have to know the truth. It has to be able to test it.
Perhaps that is why the working title “The interview that does not lie” is communicatively attractive, but methodologically not entirely correct.
Of course, even in an AI-supported interview, someone may forget something, remember it incorrectly or describe only part of reality. No interview method can prevent that completely.
The strength of our methodology lies precisely in the fact that it does not assume that a single person must know the whole truth.
The interview does not have to believe a single statement.
It can ask about the last real case. It can look for evidence. It can check whether a second role describes the same procedure in exactly the same way. And if two statements do not fit together, the contradiction can initially remain until sufficient information is available to classify it.
Only then does an interview series become a process analysis.
Because in the end, we do not want to know what ten people said about a process. We want to understand how this process actually works: which decisions are made, which information is used in doing so, who is actually involved, which systems are relevant and where formal reality and lived reality diverge.
That is exactly why we do not understand AIS [ai]works Process Intelligence as a tool for better interview records. It is a methodology that gradually creates a robust organization-wide as-is model from individual perspectives.
And perhaps the most important question in it is, in the end, surprisingly simple:
“That sounds good. Can you show me the last case?”