Process Analysis

What it is about

A process analysis answers three questions before anyone presses a button: Where are time, money and attention being lost today? Which steps actually add value – and which only exist because they have always existed? And: which parts of a process are ready for automation, and which still need a human hand?

Two paths to insight: interviews and process mining

I combine both methods, depending on the available data and the culture. Structured interviews provide the context, the why and the tacit knowledge — they show the process as people actually live it. Process mining delivers the objective reality: from the log data of the systems involved, I reconstruct how the process really runs — including all the loops, workarounds and special cases nobody has on their radar any more.

Only the combination gives the complete picture. Interviews alone are rose-tinted; mining data alone does not understand the human context.

My approach

• Discovery interviews with the people who live the process every day — not with those who merely documented it.
• End-to-end mapping: from the triggering event to the measurable outcome, including all hand-offs, waiting times and manual interventions.
• Process mining on existing system data — based on facts, not opinions.
• Risk & control mapping: where in the process do risks arise, which controls are in place today — and where are they missing?
• Numbers instead of gut feeling: lead times, error rates, processing times — quantified, not estimated.
• Assessment by leverage: what does automation deliver in € per year? What does it cost? Where is the break-even?
• Prioritised roadmap: quick wins first, structural levers next, strategic playing fields last.

From report to living process management

An analysis is only as valuable as what happens afterwards. To keep processes from gathering dust in a slide deck, the results ideally flow into a professional process management tool — a central place where processes are modelled, documented, versioned and continuously developed. The result is a living picture of your processes that grows with the company instead of being hastily dug out again for the next audit.

Process management is first and foremost an organisational question, not a software question. It includes:

• Process map: management, core and support processes at a glance — as a common language across all departments.
• Clear accountability: process owners, roles and responsibilities (RACI) for every relevant process.
• Process governance: approval workflows, versioning and fixed review cycles, so that documentation and reality do not drift apart.
• KPIs & continuous improvement: process KPIs that are measured regularly and translated into improvements.

Which tool fits in a given case depends on company size, requirements for modelling depth, compliance and integration. I work tool-agnostically — because the best tool is always the one that actually gets maintained.

Process management as the backbone of GRC

In practice, governance, risk & compliance rarely fails for lack of policies — it fails because policies, risks and controls exist detached from the actual workflow. A clean process model closes this gap: it is the place where rules, risks and controls become concrete.

• Risks and controls at the process step: the internal control system (ICS) is anchored directly in the process — exactly where the risk arises.
• Audit-proof evidence: who does what, according to which rule, with which control — documented, versioned and verifiable at any time.
• Regulation under control: requirements from ISO 9001, ISO 27001, NIS2, DORA or the EU AI Act can be mapped to the affected processes and implemented in a targeted way.
• One model, many perspectives: quality management, information security, data protection and internal audit work on the same process basis instead of in separate silos.

What I expect from the result

A lean, readable report — not an 80-page slide battle. Concrete recommendations with expected impact, estimated effort, risks and dependencies. A prioritised list that can be carried forward even without me.

My stance

For me, process analysis is neither an end in itself nor an IT procurement exercise, but a strategic tool. It gets particularly interesting where first attempts at automation or AI did not have the expected effect — the cause usually lies not in the technology, but in the underlying understanding of the process.

The more decisions automation and AI take over, the more important governance becomes. If you do not know how your processes run, you can neither assess risks nor demonstrate compliance — which is why a clean process model is the prerequisite for responsible automation, not its by-product.