Digital Transformation: change the work, not only the tools
We change how work flows, who decides and what the platform does, all together, so that the new way becomes the only way.
In brief
Digital transformation works when the old way of working stops accepting work. New tools fail when the old route keeps running beside them, so we map how work really flows, design process, decision rights and platform together, cut over in slices with a stop date for each old route, and hand leaders a cadence they run themselves.
- Who it suits
- A COO, transformation lead or head of operations with a mandate to change how part of the business runs.
- What you provide
- A sponsor who will hold the stop dates, and time from the people who do the work every day.
- What you get
- A map of the work as it is done, a target operating model, a cutover plan and an adoption cadence.
- Where it ends
- Your leaders run the cadence. We stay only if the scope adds support.
On this page
What is the work doing that the process document does not say?
Process documents describe how work should go. Work runs on something else: the side spreadsheet that corrects an awkward report, the approval someone gives by email because the system will not take a late amendment, the one person who knows how exceptions are handled and has never been asked to write it down. A new platform replaces the documented process and leaves those steps exactly where they were.
People then use both. Entries are made twice, the versions of the record drift apart, and approvals still land where they always did, now needing a click in each system. Nobody is accountable for switching the old route off, so it stays as a safety net. Adoption is reported as logins, which the vendor's dashboard supplies, instead of as the old route having stopped, which nobody measures.
The business ends up paying for the platform and for the old process, and receiving the benefit of neither.
How does the work change in slices instead of on one date?
- 01
Trace real cases
We sit with the people closest to the work and follow real cases from first request to last, exceptions included, choosing cases that went wrong as well as cases that went well. The result is a map of how work flows today, with every hidden step and the person who holds it. The people on the floor read it back to us before we use it, because a map they do not recognize cannot be trusted.
- 02
Settle decision rights
For each point where someone decides, we write down who decides, on what information, and where the decision is recorded. Where more than one role believes it owns a decision, a leader chooses; we prepare the options and show what each changes. Changes to reporting lines stay with your leaders.
- 03
Give every hidden step a fate
Each hidden step is absorbed into the new process, replaced by platform configuration or retired on purpose, with a name against it. A step that disappears by accident comes back as a spreadsheet.
- 04
Cut over a slice at a time
Each slice, a team or a process, gets an entry check, a date on which the old route stops accepting work, and a person who turns it away when it tries. Training happens on real cases, in the week the slice goes live.
- 05
Hand over a cadence
Leaders receive a standing review, a definition of adoption that counts the old route as stopped, and a named owner for each process. We step back after a full operating cycle, once the cadence has run without us.
Adoption is the date the old route stops accepting work.
Logins measure interest. Everything else is a report about intent.
Which way of cutting over fits your business?
We recommend one by looking at how much of the work is exceptions and how costly a wrong record would be, and we write the reason down so it can be challenged.
| Approach | Fits when | What it costs you | Where it goes wrong |
|---|---|---|---|
| One date for everything | The process is small, self-contained and well understood | The sponsor's full attention for a short, risky stretch | A hidden step surfaces when nothing remains to fall back on |
| Slice by slice, with stop dates | Work crosses teams and exceptions carry much of the load | A longer period of change fatigue and a heavier coordination load on the owner | Slices drift apart when each team treats its date as negotiable |
| Parallel run for a fixed period | The record has legal or financial weight and errors are expensive | Everything entered twice for a defined period, which people resent | The period never ends, because nobody owns the end |
| One willing unit first, then the rest | The design is unproven and one team asks to go first | A lopsided picture, since willing teams are rarely typical | The first team's workarounds are copied into the design |
A pattern we are called into
Maintenance approvals that still travel by email
A property management company adopts a work-order platform for repairs. Tenants' requests now enter the platform and contractors quote through it. Approval still happens the old way: a regional manager answers an email, and an assistant keys the decision in afterwards.
- Observe. We follow recent requests from the tenant's message to the contractor's invoice, including disputed ones. The emailed approval carries a rule nobody wrote: certain owners must see any quote above their own limit, and the limits live in a spreadsheet.
- Decide. The limits move into the platform's configuration with an owner for each. The manager approves in the platform, or delegates there.
- Cut one slice. One portfolio goes first. From its stop date the assistant no longer accepts emailed approvals and sends the sender to the platform.
- Hear the objections. Managers who travel say approving on a phone is slow. The design is corrected where the complaint is right, and the date holds where it is not.
- Move the next slice. Each portfolio passes the same entry check before its own stop date.
Where it endsThe platform holds the only record of an approval. The limits spreadsheet is gone, and a manager who is away has a delegate approving in the same place. Leaders review the same measures each month and can see which portfolios have not yet stopped the old route.
What is resistance telling you?
We read resistance as information before we read it as reluctance. A manager who says the new screen is slower usually has a case: the old way held a step the design dropped. A team that keeps a private copy is saying the shared one is not trusted, or lacks something the job needs. A decision that has quietly moved to someone else, without its old owner agreeing, shows up as a request to check with me first.
We find the reason with the people concerned. Where the design is wrong, we correct it. Where it is right, we hold the date and the sponsor says so in person. Both answers need a senior person in the room, which is why we ask for the sponsor's time at every slice.
Is this a transformation, or a smaller job?
It fits when
- A platform is chosen or about to be, and the process around it has not been redesigned
- Work crosses teams and exceptions carry much of the load
- A senior sponsor will hold the stop dates when they arrive
- Leaders are ready to decide who owns each decision
Look elsewhere when
- One team wants a tool configured, which needs a smaller piece of technology work
- The question is which technology to buy or how systems connect, which sits with Technology Consulting
- Nobody with authority will enforce a stop date. We say so and do not start
- The change is mandated but nobody has agreed what it should achieve
You give up the safety net. The old route will not be there when the new one disappoints, so the new one has to be made good quickly, and leaders feel that.
What sets the pace, and where does our part stop?
Pace depends on how much of the business is in scope, how much of the work is exceptions, and whether leadership holds the stop dates when they arrive. We agree how adoption will be measured in the scope, before the first slice goes live.
We configure or advise on the platform you have chosen. Vendor contracts stay with you. We do not promise adoption or business results, because both depend on decisions that belong to your leaders.
What can you do before we start?
The assessment places your transformation on a maturity scale and names the next step. The template structures a roadmap you can fill in yourself. Our research explains why changes get harder to make as they accumulate.
What do buyers ask before they commit to a transformation?
Do we need to choose the platform before you start?
No. If the platform is chosen, we design around it. If it is not, we help set the selection criteria from how your work actually flows, so the decision rests on your process instead of a vendor demonstration.
Who decides when the old system is switched off?
The sponsor, on the entry check for each slice. We recommend the date and show what depends on it. A stop date holds only when someone senior will enforce it and turn people away when they ask for exceptions.
Can the business keep operating while the change runs?
Yes. The switch goes live in slices, one team or process at a time, each with an entry check and a stop date for the old route, so no slice depends on the whole business changing on a single day.
What do you hand over at the end?
The map of the new operating model, the decision rights, the record of each cutover and an adoption cadence with named owners. Your leaders run the cadence from then on, and we stay only if the scope adds support.
Related
Is the old way still running beside the new one?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.