How a process analysis works: step by step

Many digitisation projects in mid-size companies begin with a solution rather than a question: a new system is to be introduced, an interface built, a form digitised. Anyone starting that way is building on assumptions about where time is actually lost. A process analysis reverses the order. It first establishes what happens today: which steps a case runs through, how often it occurs, where data is transferred by hand from one system to the next, and at which points things regularly get stuck.

Small and mid-size companies make up the vast majority of businesses in Germany (Federal Statistical Office) — and as a rule they have no dedicated organisational department. The overview of workflows and systems sits in the heads of individual people, often in those of the office manager who has been there for fifteen years. That is precisely why taking stock is not an end in itself: it makes visible knowledge that otherwise only passes on by word of mouth. A lack of overview of the systems in use and of the company's own data is regularly named as an obstacle in digitisation surveys (DIHK).

The outcome is a document, not a workshop feeling. The report describes the recorded workflows, quantifies the time they take and ranks measures by benefit and effort. Every measure carries a cost estimate so that management can decide without having to request a separate quotation for each idea. The report stays with the company and remains usable even if the implementation is later carried out by internal staff or another provider.

A mid-size company has more workflows than can sensibly be recorded in a few days. So a selection is made. For a first analysis, four to eight workflows are a realistic scope (project experience) — quotation, order creation, scheduling or route planning, feedback from the workshop, invoicing and dunning, for example. What matters is that these are real workflows and not topics: "order from enquiry to invoice" is a workflow, "digitisation" is not.

The selection follows sober criteria. A workflow that occurs daily and ties up ten minutes of manual work per case deserves more attention than an elaborate special procedure that comes up three times a year. Equally important is whether the workflow follows a rule. Where an experienced person decides by feel because every case is different, automation usually creates more rework than savings. Such workflows are deliberately marked in the report as "stays manual".

Alongside the workflow recording, a list of the systems in use takes shape. It captures purpose, vendor, version level, who supports it, how it is operated and which outputs exist: is there an API, an export format, an automated file exchange? This list is often useful in its own right, because many companies know which software they use but not which data that software can hand out, and in what form.

The second part is data ownership. For every important field — customer master data, articles, prices, dates, time recording — it is recorded which system leads. Where two systems maintain the same entry without one taking precedence, maintenance effort builds up and sooner or later a contradiction appears. This mapping is the basis for any later connection between systems; it also decides whether linking them through interfaces makes sense at all, or whether data maintenance has to be sorted out first.

The report is the actual product of the analysis. It typically runs to 20 to 40 pages (project experience) and is structured so that management can read the first three pages and decide afterwards. The detailed part serves the people responsible for the subject area and whoever implements later — it contains the recorded current-state workflows, the system list, the findings and the assumptions behind every estimate.

Every measure is described to the same pattern: what the situation is today, what changes, which systems are affected, the estimated price, the estimated benefit and the preconditions that must be met first. The estimates follow the usual orders of magnitude — from EUR 4,900 net per automation or interface, ongoing support from EUR 190 net per month — and are refined per measure according to scope. They are a planning basis and do not replace a binding quotation.

One chapter is deliberately devoted to sequence. Measures depend on one another: assigning documents automatically requires clean customer master data first; reporting on key figures requires a reliable data source first. The proposed order is therefore not a wish list but a chain. If the company lacks process documentation anyway, it appears in the report as a measure of its own rather than being quietly assumed.

For the company, the noticeable effort is smaller than the overall duration suggests. On-site recording ties up around 60 to 90 minutes of the respective contact per workflow (project experience), spread across one or two appointments. The rest — evaluation, assessment, writing the report — happens without the company's involvement. Between recording and handover there are usually one to two weeks.

Digitisation projects in mid-size companies are predominantly small in scale and financed from ongoing funds (KfW). That matches the way the analysis is cut: it is meant as a self-contained, plannable step, not as the entry point to a programme running for months. Anyone holding a report after four weeks can decide within the current financial year instead of waiting for a budget round.

The handover takes place in a meeting, usually with management and the people responsible for the areas involved. The report is not read out but talked through: which findings are surprising, which measure gets tackled first, which precondition is still missing. Experience shows that this conversation changes the order — often because a deadline in the company pulls one measure forward.

After that, the company decides. Implementation frequently starts with a single, clearly delimited measure that shows an effect within a few weeks — a recurring transfer of data between two systems, an automatic notification at an approval step, or replacing a duplicate entry. Only once that first measure has settled into everyday work does the next one follow. Which forms of process automation come into question depends on the findings, not on a pre-packaged product list.