Digitalization strategy: the roadmap that comes before the first tool

Why doesn't a digitalization strategy start with software?

Because software maps a process. If the process isn't settled, it maps 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 we tackle it, and who owns each initiative by name. If that fits on one page, the strategy is done. Everything beyond that is implementation planning and belongs in the hands of the person leading the initiative.

Which three decisions come first?

They're uncomfortable, because they touch responsibilities and habits. That's exactly why they tend to get replaced by a software selection.

• What's the purpose? Fewer errors, shorter cycle times, lower costs or more revenue. These four lead to different initiatives. If you name all four, you haven't named a purpose.
• Which work disappears? Disappears, not "gets easier." Data entry, follow-up questions, handoffs, checks. If nobody can name a step that goes away, the initiative will add work instead.
• Who decides in case of doubt? Digitalization creates conflicts between departments, because a process crosses boundaries. Without one person who decides between sales and production, every initiative ends in another round of alignment meetings.

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 is quick to install and looks good. It then shows numbers nobody trusts and burns the credibility of the entire effort.

A special case is replacing the ERP system. It touches all five stages at once and, depending on your size, ties up 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 processes 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 should the first initiative be?

Big enough that within twelve months something is finished and used in daily work. 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 scoping along a process, not along a department. An example: "from requisition to confirmed purchase order, no paper and no duplicate entry" instead of "we're digitalizing procurement." The first describes a path with a beginning and an end, the second just names a territory.

That includes a shutoff 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 fee is the smaller part. In practice, the effort for rollout, data maintenance and training often costs twice as much as the software. Your own working time doesn't 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 is overlooked most often and is the largest one with older systems.
• Your own time: the days employees spend on coordination, testing and training instead of day-to-day business.

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

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

Why do digitalization projects fail in mid-sized companies?

Because of three things. Technology isn't one of them.

• No owner from the business side. If the project sits with IT, you end up with a system the business side doesn't consider its own. IT builds, the business side reviews, nobody decides.
• Master data 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 next to each.

There's one more point that's easy to handle and still often missing: training 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 that support is missing, people start keeping their own side lists in spreadsheets. And double data entry is back, just invisible.