There is a pattern we see often enough to predict. A company decides to modernise, evaluates platforms, buys one, configures it to match how work is done today, and eighteen months later concludes that digital transformation does not work in their industry.
What actually happened is that the software faithfully encoded a process nobody had examined. Including the approval step that exists because of a incident in 2019, the duplicate data entry that exists because two departments stopped trusting each other, and the spreadsheet a single person maintains and has never mentioned.
Mapping the process first is not a documentation exercise. It is a filter. You walk the operation, write down every step including the informal ones, and then ask of each: does this exist because the work needs it, or because of history? Usually a meaningful fraction of the steps have no defender once someone asks out loud.
The steps that survive are the ones worth building software for. The ones that do not should be retired before, not after, they are automated — because automating a step is the most expensive possible way to keep it.
The second thing mapping gives you is a migration order. Processes are not equally painful, and the one that produces visible relief fastest is rarely the one an org chart would start with. Starting there buys you the goodwill you will need for the harder ones.
Then measure adoption rather than rollout. A feature that is live and unused is not progress, and the gap between those two states is where transformation budgets quietly disappear. If people have gone back to the spreadsheet, the honest status is red, and you want to know that in week four rather than at the steering committee a quarter later.
- process
- migration
- adoption
