The question comes up in almost every first meeting: where do we start? Most companies do not have one obvious bottleneck but a dozen workflows that all grate somewhere — orders taken by phone, time recording on paper slips, invoice checking, goods receipt, holiday requests. Around 99 percent of companies in Germany are small or medium-sized enterprises (Federal Statistical Office of Germany), and they all face the same allocation problem: time for change is scarce, so the order of work decides whether anything lands at all. This article describes how to set that order in a way everyone can follow — with two axes, six criteria and a scoring matrix that fits on a single sheet of paper and needs no software.
Key takeaways
- Prioritising means weighing two quantities against each other: the impact of a workflow, calculated from frequency times duration plus rework, and the effort of implementing a change. Anything else is gut feeling in table form.
- Impact only becomes tangible once you extrapolate to a full year: runs per week times minutes per run times working weeks gives hours, which can be valued with an internal hourly rate and compared across departments.
- Error rates count twice, because they cost rework and damage trust in the data. A rare but error-prone workflow can therefore rank ahead of a frequent but stable one.
- Dependencies beat any score: where master data is inconsistent or an upstream system will not release the data, a project does not get faster, only more expensive. The precondition moves to the front, not the project.
- The first project has to be visible inside the company and should reach a result in roughly eight weeks as a guideline (project experience), because without a tangible success the workforce will not carry the second one.
Why the order decides the outcome
An assessment regularly produces a list of ten to twenty candidates: orders taken by phone, paper timesheets, invoice checking, goods receipt, holiday requests, filing delivery notes, maintenance planning. Every single item can be justified, and every one has somebody in the company who considers it the most urgent. What is scarce is not the insight but money and, above all, attention: a company with thirty or eighty employees can carry one project alongside daily business, rarely two, hardly ever three. That makes the order of work the real decision — not the question of whether to digitise.
Choosing the wrong order costs more than time; it costs consent. A first project that runs for six months and then improves a workflow three people use twelve times a year leaves a lasting impression: much effort, little return. The next proposal then meets objections that have nothing to do with its merits. A first project that visibly takes work off people's hands within a few weeks does the opposite: it opens doors for topics that were previously dismissed as too complicated. The order of work decides whether the whole programme holds, not just the first step.
A priority list is not a wish list
Making impact measurable: frequency times duration
Impact is not an opinion but a calculation. You need two figures per workflow: how often it occurs and how long it takes. Both can be gathered within a few days without disrupting operations. For frequency, a look into the leading system is usually enough — the number of documents, orders, enquiries or reports in the last quarter. For duration, record five to ten real runs rather than asking for an estimate. Estimates from the people involved tend to come out too low, because searching, asking back and waiting between steps are not counted (project experience).
The two figures turn into an annual number. Runs per week times minutes per run times working weeks gives minutes per year; divided by sixty it gives hours. Those hours are the currency in which very different workflows become comparable — goods receipt in the warehouse and invoice checking in the office. Valuing the hours with an internal hourly rate produces a figure that also carries weight with management. Honesty matters in both directions here: in a mid-size company, saved hours rarely turn into saved headcount but into capacity for work that currently gets left undone.
Case: check, code and file an incoming invoice
Runs per week .................. 120
Minutes per run .................. 6
Working weeks per year .......... 46
Hours per year = 120 * 6 * 46 / 60 = 552
Query on every 12th document ... 10 cases per week
Extra minutes per query ......... 15
Hours per year = 10 * 15 * 46 / 60 = 115
Total impact = roughly 667 hours per yearThe values in the example are chosen, not measured (project experience). What matters is the structure of the calculation: a workflow that looks small becomes large through repetition. Six minutes are nothing; six minutes a hundred and twenty times a week tie up more than a third of a full-time position. Conversely, a laborious workflow that occurs twelve times a year stays small, even when it takes up a lot of room in conversation.
Error rate: the second half of impact
Pure processing time understates the impact when a workflow regularly goes wrong. Errors cost three times over: once for the rework, once for the clarification with the customer or supplier, and once in trust in the data. The third item is the most expensive and appears in no time measurement. Where a report is considered unreliable, it is not used; instead private side records appear in spreadsheet files that nobody maintains and that nevertheless carry decisions.
Error rates can be estimated well without a measuring system if you look for the right traces. They are usually well known inside the company but are not tracked as a metric. Do not ask about errors — ask about rework, because every department can name that.
- Duplicate entry: the same detail is typed into two systems. Every discrepancy between them is a latent error that surfaces sooner or later.
- Media breaks: the case moves between paper, message and system. Every switch produces transfer errors and waiting time.
- Free text instead of selection: where spellings are unconstrained, duplicates appear and reports cannot be totalled.
- Queries: workflows that regularly trigger a follow-up question have a quality problem at the input, not in the processing.
- Correction postings: their number per month is a usable approximation of the error rate of a commercial workflow.
- Personal lists: when staff keep their own list alongside the system, the system is missing something the workflow needs.
A rare workflow with a high error rate can end up ranked ahead of a frequent but stable one. Monthly billing runs twelve times a year but costs two days of clarification each time — that beats a daily routine that has run quietly for years. This is why the error rate belongs in the matrix as its own column, not as a surcharge on processing time.
Estimating effort honestly
The second value in the matrix is the effort of implementation. In practice it is regularly underestimated, because the visible part gets estimated — the new screen, the new report — while the invisible part is skipped: data quality, special cases, rollout. A rule of thumb: the more systems a workflow touches and the more exceptions it knows, the further the actual effort sits above the first estimate.
The matrix does not need a firm quotation, only a shared classification into five levels. It helps to anchor effort not in days but in its drivers. Four of them explain most of the spread between estimate and reality (project experience).
Number of systems involved
A workflow inside one system is mostly configuration. A workflow spanning three systems needs interfaces, error handling and a plan for the case where one system does not answer.
State of the master data
Inconsistent spellings, duplicates and missing assignments extend every project. Cleaning them up is often the actual work and belongs visibly in the estimate.
Number of special cases
Rules that hold for nine out of ten cases are implemented quickly. The tenth case can double the effort, so the estimate has to include the question of whether it needs automating at all.
Number of people affected
Technology can be planned, habit cannot. The more people have to change how they work each day, the larger the share for support, training and follow-up in the first weeks.
Dependencies: which workflow sits on top of which
Scores rank a list, but they know nothing about mandatory sequences. Some projects only make technical sense once another one is finished. Introducing mobile time recording before job or site numbers are unambiguous means building fast capture for data that then has to be assigned by hand afterwards. The workflow does not get shorter, only different — and the people involved experience the change as extra work.
So for the top candidates, check three questions: which data does the project assume, and does it exist in sufficient quality? Which system leads for that data, and will it release it at all? Which upstream or downstream workflow would have to change as well? Data integration is often the silent precondition that turns a two-week project into a two-month one. The precondition comes before the project.
Dependency beats score
Why not the most complex process first
The most complex workflow is usually the one people complain about most loudly — production planning, quotation costing with many variants, route planning. The temptation is strongest there because the pain is visible. For a first step it is still the poorer choice, for three reasons: the requirements are not yet stable, the number of special cases is unknown, and the people involved have no shared experience of this kind of project work.
There is also a timing effect. A complex project often delivers its first visible result only after months. During that time nothing happens in the company that justifies the effort, while the people involved attend meetings and answer questions. Impact comes not from complexity but from repetition. The most complex process stays on the list, but further down and split into pieces that each carry a benefit on their own.
The first project is meant to show that change works in this company. Picking the hardest case for it tends to show the opposite.
Why not the least important process either
The opposite caution is just as expensive. Starting with the most harmless workflow out of fear of resistance — the digital holiday request, room booking, the phone list — does produce a result, but not one anybody feels. The effort for selection, rollout and training is incurred all the same. The verdict after the first project then reads: it worked, but it changed nothing.
The damage is subtler than after a failed large project, but it lasts longer. Digitisation is subsequently seen as busywork on side issues, and the next discussion starts one level lower. Bitkom names a lack of time and a lack of staff as central obstacles to digitisation in its surveys of mid-size companies (Bitkom) — both are arguments that gain weight after a first project with no consequences. The target zone lies between the extremes: a workflow that runs often, that many people know, but whose rules stay manageable.
The scoring matrix on a single sheet of paper
The matrix needs no software. It consists of one row per process and six columns, each column scored from one to five. Three columns describe impact, three describe feasibility. The sum gives the ranking; because both halves carry equal weight, a project cannot climb on impact alone if it is unrealistic in practice. Conversely, easy feasibility alone is not enough either.
More important than the exact score is that everyone uses the same scale. So before scoring, define what one point and what five points mean. The following assignment has proven itself in practice and can be adapted to your own wording and orders of magnitude in half an hour.
| Criterion | 1 point | 5 points |
|---|---|---|
| Frequency | Less often than monthly | Daily or more often |
| Time per run | Under two minutes | Over twenty minutes |
| Errors and rework | Corrections are rare | Regular queries and corrections |
| Implementation effort | Several systems, many special cases | One system, clear rule |
| Preconditions | Master data or access missing | Data and access are in place |
| Visibility in the company | Affects a single person | Affects several areas daily |
Do not fill in the matrix on your own. Management knows the frequency from the system; duration and errors are known to the people who carry out the workflow every day. When the two sides score the same row differently, that gap is itself a finding: the workflow is not documented the way it is lived. Resolving that difference is often already part of the improvement.
A worked example without software
Four candidates from a company with around fifty employees, scored in a single ninety-minute session. The figures are chosen for illustration (project experience), but the pattern is typical: the workflow with the highest impact is not the one tackled first.
Process Fr Ti Er | Ef Pr Vi | Total
------------------------------------------------------
Incoming invoice check 5 3 4 | 4 4 5 | 25
Site time recording 5 2 5 | 2 2 5 | 21
Quotation from enquiry 3 5 3 | 2 3 4 | 20
Holiday request 2 2 2 | 5 5 2 | 18
Fr frequency Ti time per run Er errors and rework
Ef effort Pr preconditions Vi visibilitySite time recording leads on impact but falls back on feasibility, because unambiguous job numbers and access on the sites are missing. The incoming invoice wins because it is solid in both halves. The holiday request would be quick to implement, but the impact is not there. The quotation from an enquiry stays on the list and first needs unambiguous article and price data. The result is an order of work nobody experiences as arbitrary, because it hangs on criteria rather than on people.
Visibility: the first project has to be felt
The sixth column of the matrix is the unusual one: visibility. It has little to do with economics and a great deal to do with whether the programme holds. A project that touches several areas every day creates conversation after the rollout. A project that runs in the background in accounting may save more hours but goes unnoticed in the rest of the company — and turns up at the next budget discussion without an advocate.
The first project is a proof, not a savings programme. It should show that a workflow really can get better in this company, and do so quickly enough that the link between effort and result stays visible. As a guideline, no more than eight weeks should pass between the decision and a tangible result (project experience). If it will foreseeably take longer, split the project into a first part that already takes work off people's hands and a second part that follows later.
Visibility without symbolic politics
The first weeks: a four-step approach
Only a few weeks separate the completed matrix from the first result, provided the workflow is clear. According to KfW, digitisation projects in mid-size companies are predominantly small in scale and financed out of ongoing funds (KfW Mittelstandspanel) — which fits an approach built from short, self-contained steps that needs no dedicated department and can be carried alongside daily business.
Week 1: collect candidates and measure
Name ten to fifteen workflows, pull the frequency from the leading system and record five to ten runs per workflow. The person who carries out the workflow does the recording — not the person who describes it.
Week 2: score and check dependencies
Fill in the matrix in a joint session, then check the preconditions for the top three candidates: data, leading system, adjacent workflows. Candidates with an open precondition move down, the precondition itself moves up.
Week 3: cut the first project to size
Shrink the winner far enough that a result is possible within a few weeks. Deliberately leave rare special cases to manual handling for now and record the scope in writing so it does not grow unnoticed during implementation.
Weeks 4 to 8: implement, support, measure again
Implementation, rollout with the people involved on a real case rather than on a manual, then the same measurement as in week 1. Only the second measurement shows whether the automation has held up in daily work.
Name ten to fifteen workflows, pull the frequency from the leading system and record five to ten runs per workflow. The person who carries out the workflow does the recording — not the person who describes it.
Fill in the matrix in a joint session, then check the preconditions for the top three candidates: data, leading system, adjacent workflows. Candidates with an open precondition move down, the precondition itself moves up.
Shrink the winner far enough that a result is possible within a few weeks. Deliberately leave rare special cases to manual handling for now and record the scope in writing so it does not grow unnoticed during implementation.
Implementation, rollout with the people involved on a real case rather than on a manual, then the same measurement as in week 1. Only the second measurement shows whether the automation has held up in daily work.
The second measurement is the step most often skipped — and the only one that makes the discussion about the next project easy. A figure from your own company carries more weight in any meeting than any experience brought in from outside. So note before implementation which figure you will collect again afterwards and who will collect it.
What the matrix does not decide
A scoring matrix ranks, it does not decide. There are good reasons to deviate from the ranking, and they are legitimate as long as they are stated and recorded. A statutory deadline, a customer project with a fixed requirement, a system replacement that is due anyway — all of these can pull a workflow forward even though it does not lead on points.
Legal requirements deserve separate consideration. Retention obligations, the traceability of postings, data protection for staff data and works council codetermination for systems capable of recording behaviour or performance affect many digitisation projects directly. These points cannot be weighed with scores; they belong in a professional review before implementation, in individual cases by a tax adviser or a lawyer. This article sets out the context and does not replace such a review.
- Statutory or contractual deadlines set the order regardless of the score.
- Upcoming system replacements: whatever is being touched anyway can be included more cheaply than tackled separately later.
- Staffing bottlenecks: a project whose key person is tied up for months starts later, even with a high score.
- Visible resistance: where a workflow is professionally contested, the clarification belongs before the technology, otherwise the result gets circumvented later.
- Deliberate abstention: some workflows stay manual because they are rare or require judgement. That, too, is a result of the assessment, not an omission.
Record every deviation in one sentence. A process documentation that also holds the rejected candidates and the reason they were deferred saves half the discussion in the next round — and makes visible which precondition has since been met and which candidate therefore moves up.
Related Articles
Digitisation funding: types, paperwork and sequence
Grants, subsidised loans, consulting subsidies: what German funding covers, which documents an application needs and why it must precede any binding order.
How a process analysis works: step by step
Kick-off, walkthrough, system inventory, evaluation, report: what really happens in a process analysis, what to prepare and what it deliberately leaves out.
Handling complaints digitally: deadlines and evidence
Which periods run from delivery, which records should be created on a complaint case, and how to map both digitally without turning it into a large project.