In companies with ten to thirty employees, digitisation usually starts the same way: someone adds up how much time administration eats, and the result is a plan meant to solve everything at once — new software for orders, hours, invoices and stock, plus training for everyone involved. A few months later the plan is stalled, because nobody had the time it would have required. Around 99 percent (Federal Statistical Office) of companies in Germany are small and medium-sized enterprises, and in the smaller ones there is no project manager who can be freed up for six months. This article describes the alternative: one workflow after another, each step finished within a few weeks and each with a result that is visible in daily work. That includes a realistic budget frame and the question of when a new system is genuinely needed and when an interface is enough.
Key takeaways
- The large digitisation plan rarely fails on technology in small companies, but on simultaneity: changing orders, hours, invoices and stock together ties up exactly the key people who keep the business running.
- A workable scope covers exactly one workflow, takes three to six weeks from recording to handover (project experience) and ends with a result the affected department recognises without further explanation.
- Effort decides the order, not technology: start with the workflow that occurs often, needs little judgement and is currently entered twice — not the one with the most appealing tool behind it.
- A single step stays in the four-figure rather than the five-figure range: analysis from 1,900 EUR net, one automation or interface from 4,900 EUR net — and after each step the company can stop without losing what it has gained.
- A new system becomes necessary only when the vendor ends maintenance, when the workflow cannot be mapped in the existing system, or when no documented data path exists; otherwise connecting two systems is the far smaller intervention.
Why the big plan rarely lands in a small company
A large project assumes someone leads it. In a company with 250 employees there is a role for that; in a company with 25 employees it falls to the person who already writes quotations, coordinates appointments and handles the paperwork. Lack of time and lack of staff count as the most common obstacles to digitisation in mid-sized companies (Bitkom) — not a lack of tools. And it is precisely this scarce resource that a plan touching several areas at once consumes in unusually large quantities.
On top of that comes the simultaneity of the change. If order intake, time recording and invoicing are all reorganised in the same quarter, every open question reaches the same people at the same moment. Each query waits for a decision, each decision waits for management, and management has customer appointments. The plan then stalls not because it was professionally wrong, but because the queue is longer than the calendar.
The third point is the result. A large plan delivers its benefit at the end. Until then, those involved mostly see effort: checking data, maintaining lists, running through test cases. Anyone who has gained nothing after four months loses the willingness to take part — and without that willingness even a technically clean setup does not carry. Small steps reverse the order: the benefit comes first, and it funds the patience for the next step.
What „workflow“ means here
How to tell that a plan is scoped too large
Whether a plan is scoped too large can be checked before it starts. The questions are unspectacular: how many people have to change their daily work? How many systems are touched at the same time? How long until the first person actually does something different from before? If the answer to the last question is measured in months, the scope is too large — regardless of how sensible the goal itself may be.
A second sign is the dependency chain. As soon as a plan contains sentences such as „we can only do that once the master data is cleaned up, and we can only clean up the master data once the new system is in place“, the first visible benefit has slipped to the end of a long chain. In such cases it pays to read the chain backwards and look for the first step that delivers something on its own. Nearly every chain contains such a point; it is rarely the point a system demonstration starts with.
- More than one workflow is being changed at once, for example quotation writing and time recording in the same quarter.
- The first recognisable benefit is more than six weeks away.
- The plan needs decisions from more than two people before anything at all is built.
- The task list contains items nobody in the company can describe in their own words, because they come from a system demonstration.
- The schedule assumes the same capacity in peak season as in January.
- There is no point in the plan at which the company could stop without losing what it has gained.
The other scope: one workflow, a few weeks, one visible result
The alternative gives up the grand design and takes on a single workflow. It is recorded, calculated, changed and handed over — and then it is done. In practice the span from recording to handover runs three to six weeks (project experience), and the larger share of that time goes not into the technology but into coordination, testing in real day-to-day operations and rework.
What matters is that something stands at the end that is recognisable without explanation. „The supplier invoice lands with the right order automatically after scanning“ is such a result. „The data basis is cleaner now“ is not. The distinction sounds pedantic, but it decides whether the second step finds support inside the company. How such a recording works in practice is described under process analysis.
The second advantage is financial. A plan that runs in steps can be ended, postponed or continued differently after every step. Digitisation projects in mid-sized companies are predominantly financed out of current funds (KfW), and current funds cope far better with predictable partial amounts than with one large lump sum.
Recording (week 1)
The workflow is recorded where it happens: taking notes, counting, looking at documents. What counts is not the org chart but what actually happens — including the detours that have settled in over the years and appear in no written description.
Calculation (weeks 1 to 2)
How often does the case occur, how long does it take, how many people touch it? Only these three figures show whether a change is worthwhile — or whether the workflow is too rare to justify the effort. That is a valid outcome too.
Decision (week 2)
From the calculation follows the smallest intervention with a noticeable effect: a connection between two systems, an automatic handover, a digital form instead of paper. Everything else is noted and kept for a later step rather than built along the way.
Delivery (weeks 3 to 5)
Work is done against the real workflow, not against a description. Running the old and the new way in parallel for a few days is the normal case, so that nobody works without a way back and special cases surface while the old route is still open.
Handover (weeks 5 to 6)
People are shown the new route on their own case, not in a manual. Add to that a short piece of documentation, a named contact inside the company and an agreement on what will be measured in four weeks to see whether the new route is actually being used.
The workflow is recorded where it happens: taking notes, counting, looking at documents. What counts is not the org chart but what actually happens — including the detours that have settled in over the years and appear in no written description.
How often does the case occur, how long does it take, how many people touch it? Only these three figures show whether a change is worthwhile — or whether the workflow is too rare to justify the effort. That is a valid outcome too.
From the calculation follows the smallest intervention with a noticeable effect: a connection between two systems, an automatic handover, a digital form instead of paper. Everything else is noted and kept for a later step rather than built along the way.
Work is done against the real workflow, not against a description. Running the old and the new way in parallel for a few days is the normal case, so that nobody works without a way back and special cases surface while the old route is still open.
People are shown the new route on their own case, not in a manual. Add to that a short piece of documentation, a named contact inside the company and an agreement on what will be measured in four weeks to see whether the new route is actually being used.
Which workflow to tackle first
The order decides the success of the whole series. The obvious move would be to start with the workflow that has the most appealing tool behind it. More robust is a selection based on four sober criteria: frequency, share of manual work, room for judgement and cost of errors. A workflow that occurs daily, requires a lot of typing, needs little judgement and costs money when it goes wrong is the right place to begin.
The opposite case matters just as much. Workflows that occur rarely or depend heavily on the judgement of an experienced person are left untouched at first. A special calculation needed four times a year does not justify automation — and a workflow in which every second decision is an exception does not become simpler through automation, it becomes rigid. Drawing that line is part of the outcome of an assessment, not a rejection of the plan.
Frequency
How often does the case run per week? A daily workflow with ten minutes of manual work adds up noticeably over a year; a monthly one with two hours usually does not.
Manual work and double entry
Is the same detail typed in several times — in the quotation, the delivery note, the invoice? Double entry is the most common candidate for a first step and usually the cheapest.
Room for judgement
Does the workflow follow clear rules or does it need experience? The more judgement is required, the less automation delivers and the more a better-prepared decision helps.
Cost of errors
What happens when something is missed — a query, a second delivery, an unpaid invoice? High error costs justify an earlier step even at lower frequency.
Putting the budget in proportion
The budget question is often asked too late and then answered too large. Anyone costing out a new system for the whole company quickly arrives at licences, rollout effort, data migration and training in a sum no management team approves in passing. A single step sits in a different order of magnitude — and that is exactly what makes it decidable.
For orientation: a process analysis for a defined area starts at 1,900 EUR net, delivering a single automation or interface at 4,900 EUR net, ongoing support at 190 EUR net per month. These are entry figures, not flat rates — what a specific step costs depends on how many systems are involved and what condition the data is in today. An overview is available under pricing.
More important than the individual amount is the structure. Four steps spread over a year add up to a sum that stays plannable and can be reassessed after every step. The same sum as a single approval at the start of the year assumes that today's judgement holds for twelve months. In mid-sized companies it rarely does, because order intake, staffing and priorities change faster than the project plan.
| Criterion | One large project in a single run | One workflow after another |
|---|---|---|
| First visible benefit | On completion, often after months | After the first step, usually within weeks |
| Time commitment of key people | Across the entire runtime | A few hours per week per step |
| Financial commitment | Large and fixed early on | In partial amounts, reviewed each step |
| Stopping possible | Only at a loss | After every step without loss |
| Handling wrong assumptions | Surfaces late, correction is expensive | Surfaces in the next step |
| Requirement on the company | A project manager freed from other duties | A contact with a weekly time slot |
New system or is an interface enough?
This question decides the difference between a step and a large project. Replacing a system affects everyone who works with it and brings data migration, training and a phase with a higher error rate. An interface affects only the point where data is currently carried from one system to another by hand — the rest stays as it is, including the handling everyone knows.
In many companies the existing system is not the real problem, its isolation is. The inventory system knows the orders, the accounting system knows the invoices, and in between sits a person retyping numbers. Where that is the case, an interface resolves the bottleneck at a fraction of the cost of a replacement. When a replacement is nevertheless the right route is described under legacy migration.
Three reasons that do argue for a new system
- How many workflows depend on this system, and which of them are genuinely affected?
- Is there a documented interface, a complete export or a permitted database access?
- How long will the system still be maintained, and is there a written statement from the vendor?
- Which data would have to be migrated, and what condition is it in today?
- What happens to legacy data that has to remain readable for retention reasons?
- Who inside the company answers queries during the transition without dropping out of daily work?
What a typical first step looks like
A pattern that looks similar in many companies: incoming invoices arrive by post and by email, are printed, filed in a binder, checked, signed and passed on once a month in one batch. Every invoice is handled several times, and the status of a check is only visible when someone opens the binder. Supplier queries cost search time, because nobody can say where a document currently sits without looking.
The first step changes little that is visible and much that is felt: documents are captured in one place, assigned automatically to the matching order or cost object and passed to the responsible person for checking. The binder does not disappear overnight, the workflow stays the same — only the path of the paper is replaced. What emerges alongside is the basis for everything that follows: a process documentation that describes the workflow the way it actually runs.
The first step does not have to be the most important one. It has to be the one after which the people involved agree to a second step.
What happens between the steps
The pause between two steps is not idle time, it is part of the approach. Four to six weeks after handover, someone checks whether the new route is being used or whether the old list is still running alongside it. This check needs no elaborate reporting: the number of cases going the new way, the number of queries and the question of whether anyone still prints something are enough for a sound judgement.
If the check shows the step has held, it also provides the starting position for the next one. If it shows the opposite, the step is reworked before anything new begins. A workflow that has not been adopted but already carries another one on top multiplies the effort — which is why the order „first make it hold, then build on it“ is not a formality. This phase also settles whether a step needs ongoing support or runs without further maintenance.
One measure per step is enough
Where this approach reaches its limits
Not every situation can be broken into small steps. When a server reaches the end of its maintenance, when a legal deadline sets a fixed date or when a central system is switched off on a set day, there is a date that cannot be negotiated. In such cases the change remains a project with a deadline; what helps is to move out everything that does not depend on that date, so the hard core stays small.
The second limit is self-made. Building many small connections without a target picture leaves a web after a few years that nobody can survey any more. Little effort is needed against it: one page stating which system leads for which data and which connections exist. That page is updated after every step and marks the difference between a structure that has grown and a patchwork.
Check legal requirements case by case
Related Articles
Invoice checks automated: order, goods receipt, invoice
Matching order, goods receipt and invoice by machine: which fields are compared, where the tolerance band sits, who owns the exception and what stays manual.
Interface security: accounts, keys and permissions
Sign-in, key handling, encryption in transit, minimal permissions, separate test accounts and key rotation: what to settle for every interface you run.
Monitoring interfaces properly: beyond the server being up
Monitoring interfaces beyond availability: business-level checks, thresholds without false alarms, escalation to a named owner and logs with defined retention.