Skip to content
Process analysis & assessment

Which processes first? A scoring matrix for mid-size firms

Effort versus impact, frequency versus error rate, dependencies first: how a mid-size company decides which workflow gets touched before all the others.

13 min read PriorisierungProzessanalyseBewertungsmatrixDigitalisierungMittelstand

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

A wish list collects what annoys people. A priority list ranks what pays off and what is feasible. The difference shows in a simple test: if two items cannot be compared because one has figures behind it and the other only a feeling, the assessment is not finished yet. A process analysis supplies the common basis for comparison.

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.

Annual impact of one workflow
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 year

The 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

When a high-scoring project has a precondition that is not yet met, it is not the project that moves forward but the precondition. That is not a step backwards: cleaned-up master data or a clearly defined leading system act on several later projects at once and therefore score highly in their own right, even if they look unspectacular at first.

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.

Project experience

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.

Criterion1 point5 points
FrequencyLess often than monthlyDaily or more often
Time per runUnder two minutesOver twenty minutes
Errors and reworkCorrections are rareRegular queries and corrections
Implementation effortSeveral systems, many special casesOne system, clear rule
PreconditionsMaster data or access missingData and access are in place
Visibility in the companyAffects a single personAffects 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.

Score sheet, six criteria from 1 to 5
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 visibility

Site 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

Visibility does not mean picking a project that looks good. It means showing the result where it arises: a report that used to take two days, now on screen every week; a message from the site that is attached to the job by the evening. Introducing the first result without a word gives away part of its effect.

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.

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.

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.

This article is based on data from: Federal Statistical Office of Germany (enterprise structure), Bitkom (surveys on digitisation in mid-size companies), KfW (KfW Mittelstandspanel) and our own project experience.

Related Articles

Law, security & funding

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.

14 min read
Process analysis & assessment

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.

13 min read
Practice & rollout

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.

13 min read