Digitalization strategy: the roadmap that comes before the first tool

Why doesn't a digitalization strategy start with software?

Because software encodes a process. If the process isn't settled, it encodes the one the vendor considers right, and you pay the difference in customizations, training and workarounds.

The second reason is the order of decisions. You can select a tool in eight weeks. The question of which work should disappear requires a decision from management, and that takes longer. Buy first and you've delegated the decision to the go-live date.

A digitalization strategy answers three questions, and none of them is a product question: Which work will run differently, in what order will we tackle it, and who owns each initiative by name. If that fits on one page, the strategy is done. Everything beyond it is execution planning and belongs with the person leading the respective initiative.

Which three decisions belong before that?

They're uncomfortable because they touch responsibilities and habits. That's exactly why people happily replace them with a software selection.

• What is the purpose? Fewer errors, shorter lead times, lower costs or more revenue. These four lead to different initiatives. Name all four and you've named no purpose at all.
• Which work disappears? Not "gets easier," but disappears. Data entry, follow-up questions, forwarding, checking. If nobody can name a step that goes away, the initiative will add work instead.
• Who decides when it's contested? Digitalization creates conflict between departments because a process crosses boundaries. Without one person who decides between sales and production, every initiative ends in another alignment meeting.

The third question is where mid-sized companies get stuck most often. It usually gets answered with "we'll do that together," which in practice means the process stays exactly as it is.

In what order do you tackle the initiatives?

By benefit per effort, not by visibility. The sequence below has proven itself in mid-sized companies because it starts with work everyone experiences as a burden.

The most common deviation is jumping to stage four, because an analytics tool installs quickly and looks good. It then shows numbers nobody trusts and burns the trust in the entire effort.

Replacing the ERP system is a special case. It touches all five stages at once and, depending on your size, absorbs one to two years of attention. If that replacement is coming anyway, the initiatives from stages one through three belong inside that project rather than alongside it, otherwise you'll build the same workflows twice. If it isn't coming, it's not a prerequisite either: duplicate data entry can be eliminated in almost any existing system.

How big do you cut the first initiative?

Small enough that something is finished within twelve months and actually used day to day. That deadline isn't a project rule, it's a statement about attention: no mid-sized company keeps an initiative at the top of the list any longer than that.

In practice that means cutting along a workflow, not along a department. An example: "from requisition to confirmed order, no paper and no double entry" instead of "we're digitalizing purchasing." The first sentence describes a path with a beginning and an end, the second describes a territory.

That includes a shutdown date for the old way. As long as both paths stay open, people under pressure use the familiar one. An initiative without that date creates parallel work instead of relief.

What does digitalization really cost?

The license price is the smaller part. In practice, the effort for rollout, data maintenance and training often runs to twice the cost of the software. Your own working hours never show up in any quote.

Four items belong in every calculation:

• Licenses or subscriptions, calculated over five years instead of one.
• Rollout and customization, usually handled by the vendor or a partner.
• Data work: checking master data, cleaning up legacy records, resolving duplicates. This item gets overlooked most often, and with older systems it is the largest.
• Your own time: the days employees spend on coordination, testing and onboarding instead of day-to-day business.

Name these four items and you arrive at a number that is higher than expected. It is still the more useful basis, because otherwise the project runs into budget trouble in year two and is then written off as a failure.

A note on funding: there are federal and state programs for digitalization projects, and their conditions change regularly. They are a contribution to the decision, never the reason for it. A project that starts only because of a grant ends when the funding period does.

Why do digitalization projects fail in mid-sized companies?

Because of three things. Technology is not one of them.

• No owner from the business side. If the project sits with IT, the result is a system the business side doesn't see as its own. IT builds, the business side reviews, nobody decides.
• Master data that nobody maintains. Three part numbers for the same item make every analysis wrong. Maintenance needs a person with time, not a rule in a manual.
• No relief for the people involved. When rollout and day-to-day business run in parallel, day-to-day business wins. The project slips by months without anyone ever making a decision.

These three points cost decisions, not investment. That's why they belong on the same single page as the strategy, with a name and a date attached to each.

There's one more point that's easy to handle and still often missing: onboarding during working hours, with one person per area who answers questions. Two hours of training for a system that shapes the entire workday isn't enough. Where this support is missing, people build private side lists in spreadsheets. And with that, double data entry is back, just invisible.