How Does Digital Adoption Work?
Digital adoption works in six stages: Discover, Diagnose, Design, Implement, Enable, Stabilize.
TL;DR
- Six stages. Discover, Diagnose, Design, Implement, Enable, Stabilize.
- Implementation is the fourth of them. Three stages happen before anything is configured. Two happen after the system turns on.
- The order is the mechanism. Each stage removes a specific way the next one fails, so skipping one does not save its cost, it relocates it.
- Discover is done by interview, not questionnaire. A form returns the documented process. The real one is different, and the difference is the requirement.
- Diagnose is the highest-value hour. If the reason the last system failed is not established, the next one fails the same way.
- Enable and Stabilize are contracted, not assumed. An engagement that ends at go-live is priced to fail.
Engagements that consist only of stage four are the ones that produce a working system nobody uses.
Why the sequence is the mechanism
The order is not administrative. Each stage removes a specific way the next one fails.
Configure before you design, and you build to the software’s defaults instead of to your process. Design before you diagnose, and you carry forward the problem that broke the last rollout. Go live without enabling, and you have a correct system and a team that avoids it. Finish at go-live, and you never find out which of your design assumptions were wrong.
Stage 1: Discover
A written account of how the work runs today.
That covers the processes, the software already in place, the spreadsheets doing a system’s job, where data lives, who owns what, how reporting is produced, what is integrated, and every place the same thing is done twice.
Discovery is done by interview and observation rather than by questionnaire, because the documented process and the real one are different documents. The person who actually runs a task will describe a set of steps that appear in no procedure, and those steps are the requirement.
What it produces
Current-state process maps, a systems inventory, a pain-point analysis, a requirements register.
The most common finding is that no two people describe the same process the same way. That is not a discovery failure. It is the finding.
Stage 2: Diagnose
The gaps, duplication, risks and adoption problems in that account, named and ranked.
Ranking matters more than listing. Every organization of any size can generate forty problems. The question is which three are producing the others. A reconciliation step that takes a person two days a week is usually a symptom of two systems holding the same record with no agreement about which is authoritative, and fixing the reconciliation without fixing the ownership question just moves the work.
This is also where the reasons a previous rollout failed get identified. Those reasons are usually still in the building: the same approval bottleneck, the same person maintaining the same shadow spreadsheet, the same team that was never asked what their work involved.
What it produces
A ranked problem set with each item traced to its cause.
The diagnostic that decides the budget
If a previous system failed and the reason is not established before the next one is designed, the next one fails the same way. This is the single highest-value hour in the engagement and it is routinely skipped because it is uncomfortable.
Stage 3: Design
How the process should run, settled before anything is configured.
Stages, ownership, approval rules, handoffs, required data, exceptions, notifications, escalations, reporting. These are business decisions, not technical ones, and they have to be made by people with the authority to make them. A consultant cannot decide who approves a discount over fifteen percent.
The technology decisions come after that: which tools stay, which are replaced, what becomes the system of record, how the systems connect.
What it produces
Future-state workflows, business rules, a roles and ownership matrix, a solution architecture, an application map, an integration architecture, an implementation roadmap.
The roadmap is written to be executable by whoever executes it. Several clients have taken the design and built it in-house or with their existing IT provider, which is a legitimate outcome and one worth planning for.
Stage 4: Implement
The environment gets built to the design.
Modules, fields, layouts, approval workflows, forms, portals, dashboards, and the integrations between systems. Roles, profiles, access levels and data-sharing rules get configured as part of the build rather than added afterwards.
Data is the larger half of this stage. Existing information is inventoried, cleaned, deduplicated, mapped and migrated, and validated against a report after. Automation of the repeating work happens here too, and each automation gets its exception handling defined at the same time. An automation without a defined exception path is a future incident.
What it produces
A configured production system running on your data, migrated and validated, with integrations and automations live.
Stage 5: Enable
Your people can operate it without the people who built it.
Training by role, so a person learns the work they do rather than sitting through every module. Separate training for administrators, because administering a system is a different job from using it. A written procedure for every process the system now carries, in the language the team actually uses. A user guide, an administrator handbook, and an adoption plan with something measurable in it.
The adoption plan is the part that gets treated as a formality. It should name what will be measured, at what point, and what happens if the number is wrong.
What it produces
Role-based and administrator training, an SOP library, user and admin documentation, a measurable adoption plan.
Stage 6: Stabilize and Optimize
The engagement continues past go-live.
Issue resolution. Workflow corrections against what people actually do rather than what the design assumed, which is a different thing and always produces changes. Data-quality monitoring. Usage measured against the adoption plan. An enhancement backlog the client owns.
Some of the design will be wrong. That is expected and it is why this stage exists. A stage that assumed two approvals will turn out to need one, or a field marked required will be blocking a legitimate case nobody described in Discover. Finding those in month two and fixing them is normal. Finding them in month two with no scope to fix them is how a team returns to the old method.
What it produces
A corrected system, measured usage, and a backlog you own.
Why the last two stages are scoped and paid for
A technically correct system that employees avoid is a failed implementation. Enable and Stabilize are the stages that prevent it, which is why they are contracted rather than assumed, and why an engagement that ends at go-live is priced to fail.
Common mistakes
- Starting at stage four. The most common shape of a failed project: software is chosen, configured to its defaults, and delivered against a process nobody wrote down. Better: three stages of work before any configuration, even where they compress into two weeks.
- Running Discover as a questionnaire. Forms return the documented process. Better: interview the people doing the work and watch them do it, because the workaround they have built is the requirement.
- Letting the consultant make the process decisions. Approval thresholds and stage ownership get decided by whoever is available. Better: the design stage needs a decision-maker in the room, and the engagement should stall rather than guess.
- Migrating everything. The old system's full contents get moved in on the theory that history might matter. Better: inventory and decide what comes across. Migrating known-bad data destroys trust in the new system in the first week.
- Treating training as the adoption plan. A session is delivered, attendance is recorded, and the project is called complete. Better: an adoption plan names a measure, a date and a response.
- Measuring logins. Better: measure whether the process is running in the system. Records created at the right stage, approvals inside the workflow, reports produced without reconciliation, and the parallel spreadsheet no longer being updated.
- Closing the engagement at go-live. Better: agree the stabilization period before the build starts, so the corrections that month two will require have somewhere to go.
Frequently asked questions
How long does each stage take?
The first three stages together run two to six weeks depending on scope. Implementation runs ten to nineteen weeks for a single system, twenty to forty for a full environment across several functions. Enable overlaps the end of Implement. Stabilize is typically ninety days after go-live and is agreed before the build starts.
Can we do only the first three stages?
Yes, and it is a common way to start. The output is a design and a roadmap written to be executed by anyone, including your existing IT provider or an internal team. FusionMap is that engagement.
Do we have to replace our software?
The decision belongs in stage three, on the evidence from stage one. A significant share of assessments conclude that the existing tools are adequate and were configured against an undefined process, which is a reconfiguration rather than a replacement.
What if the design turns out to be wrong?
Some of it will be. Stage six exists for that. Workflow corrections against observed behaviour are a planned part of the work, not a defect.
Who needs to be involved from our side?
Someone with authority over the process, the people who actually run each process in scope, and whoever administers the current systems. Stage three stalls without a decision-maker, and stage one is worthless without the operators.
What happens if we skip Enable?
The system works and the team does not use it. This is the most predictable failure in the sequence, and it is the one most often produced by a budget cut late in the project.
How does this relate to AI?
It is the prerequisite. Agents run against your process and your data, so an undefined process and scattered records produce fast, confident, wrong output. The six stages produce the two things an AI system needs to read from and execute against.
Key takeaways
- Six stages: Discover, Diagnose, Design, Implement, Enable, Stabilize. Implementation is the fourth of them.
- Three stages run before anything is configured. Building first means building to the software's defaults.
- Diagnose is where the reason the last rollout failed gets named. Those conditions are usually still in the building.
- Design decisions are business decisions. An engagement should stall for a decision-maker rather than guess.
- Some of the design will be wrong. Stage six exists so the corrections have somewhere to go.
- An engagement scoped to end at go-live is scoped to end on the day the real problems start.
Where to go next
What is digital adoption covers the definition and where the term gets confused with the software category of the same name. How to drive digital adoption goes deeper on stages five and six, which is where most engagements come apart. Our six-step approach is how these stages run on an actual engagement, and the Digital Adoption service page lists what a client owns at the end of each one.