There is a version of digital transformation that consists of selecting a platform, running a migration, and declaring the organisation transformed. It is popular because it is legible to a board and it produces a date. It also has a failure mode so consistent that it is almost a law: the new system encodes the old organisation's dysfunction, in software, permanently.
The work that prevents this is unglamorous and comes first. You have to find out how the organisation actually operates.
The process on the wall is not the process
Every organisation has a documented process. Almost none of them run it.
What runs is the documented process plus a layer of accumulated workarounds: the spreadsheet that reconciles two systems that do not talk, the WhatsApp group where approvals actually happen, the person in operations who knows which of the three customer records is the real one. None of this is in the process document. All of it is load-bearing.
Discovery is the work of finding that layer. It is done by sitting with the people who do the job and watching them do it — not by interviewing their managers, who describe the documented process in good faith because that is genuinely what they believe happens.
The three questions that produce most of the value
Where does work wait? Follow a single unit of work — an order, an application, a case — end to end, and record every point at which it stops. Almost all cycle time in a business process is waiting, not working. The waits are where the value is, and they are usually caused by handoffs and approvals rather than by anything a faster system would fix.
Where is data re-entered? Every point where a human retypes information that already exists in a system is both a cost and a defect source. Counting these is the fastest way to size the integration work, and the count is always higher than anyone expects.
What are the exceptions, and how often? Every process has a happy path and a set of exceptions. Teams describe the happy path; the exceptions consume the time. A process where 30% of cases are "special" is not a process with a few edge cases — it is a process whose real shape nobody has written down yet.
Write down what success looks like in numbers
A transformation programme without a numeric target cannot succeed, because there is no condition under which it is finished.
"Improve customer experience" is not a target. "Reduce time from application to decision from eleven days to two" is. So is "eliminate the 14 hours a week finance spends reconciling the two inventory systems." Both can be measured before the work starts and again afterwards, and both tell you within a quarter whether the programme is working.
Baseline everything before you change anything. Teams that skip the baseline lose the ability to demonstrate their own success, and then struggle to fund phase two.
Sequence for the smallest useful slice
The instinct in a large programme is to design the complete future state and then build it. The result is a long period with nothing in production, during which the requirements change and the sponsor loses patience.
The alternative is to find the smallest slice that delivers real value to real users and ship it. One process, end to end, in production, being used. It validates the architecture, it proves the integrations, it surfaces the exceptions nobody mentioned, and it gives the programme a demonstrable win while the budget conversation for phase two is still open.
Plan for the people, not just the system
The technical work is usually the smaller half. A system that changes how people do their jobs needs the same rigour applied to training, to the transition period, and to the honest conversation about which roles change.
We build employee training into transformation programmes as a workstream, not as a week at the end. The teams that adopt new systems fastest are the ones who were involved during discovery and who understood, before go-live, why the change was being made.
What this costs
Discovery on a mid-sized transformation is typically two to four weeks of work. That is a real cost, and it is the cheapest phase in the entire programme to change your mind in.
The alternative — discovering the same information after the platform is selected, the contract is signed and the migration is under way — costs an order of magnitude more, and by then the answer usually has to be a workaround rather than a design change. Which is how organisations end up with a new system that encodes the old spreadsheet.
Our digital transformation practice starts every engagement with this work, including on custom software builds where the process map is what the system is shaped around.