Setting up an organization for digital transformation that scales comes down to one thing: building an operating model around the change, not running a sequence of isolated tool projects. The companies that get the most value from automation know who owns the program, who owns each process, who performs the work today, how success is measured, and how new use cases move from idea to production. That is the difference between buying automation and building transformation capacity.
Most enterprise transformation programs do not fail because the technology is missing. They fail because the organization is not set up to own the change. McKinsey puts the failure rate of large-scale transformations at around 70%, and consistently finds that culture and ownership, not technology, are the biggest obstacles. It is the same reason most enterprise AI pilots stall before they scale. Every customer is different. A global retailer, an FMCG distributor, and a fast-growing e-commerce business will not run transformation the same way. The right model depends on scale, maturity, systems, culture, and how decisions actually get made. Still, some patterns work better than others. Below are the recommendations we see working best for enterprise retailers and FMCG organizations.
Key Takeaways
- Transformation scales when the customer builds ownership around automation, not when the vendor runs it. That means one accountable program owner, a network of domain champions, and a named business owner plus operator for every single use case.
- Map and improve each process before you automate it. Automating a broken or undocumented process exposes the problem faster instead of solving it, so the rules that live only in people's heads have to be written down first.
- Treat the first eight weeks after launch as a controlled adoption phase. Track acceptance and corrections weekly, then expand to the next process instead of over-optimizing the first one.
1. Map and improve the process before you automate it
Automation is not a shortcut around process clarity. Before a workflow is automated, the business should understand how the process works today: who does the work, what systems are used, what decisions are made, where exceptions appear, and where the process breaks down.
This is easy to rush. It feels slower than just automating. In practice, it saves time. Many processes contain rules that live only in people's heads. In retail and FMCG, those rules might involve minimum order quantities, carton multiples, supplier exceptions, delivery-day restrictions, promo constraints, margin rules, approval limits, or local market habits. They show up in sentences like "you just have to know that," "we always do it this way," and "only one person knows why this exception exists."
Those rules need to be written down before automation starts. The point is not documentation for its own sake. It is to make the process clear enough that an AI agent, an automation workflow, or a human operator can follow the same business logic. In some cases the process should be improved before it is automated. If the workflow is inconsistent, politically contested, or full of unmanaged exceptions, automation will expose the problem rather than solve it.
A useful test: if the business cannot explain the current process clearly, it is probably too early to automate it.
2. Name one transformation owner with real authority
A digital transformation program needs one accountable business owner. Different companies use different titles, such as Transformation Manager, Head of Transformation, AI Adoption Manager, VP Internal Solutions, or Business Transformation Lead. The title matters less than the mandate.
This person sits above individual processes and owns the automation program as a business initiative. They decide which processes move next, unblock departments, manage leadership expectations, and make sure the company captures value beyond the first pilot. They typically own four things: the commercial relationship with the automation partner, prioritization across departments, internal change management when teams need to work differently, and visibility into value delivered, including baselines, adoption, and next-quarter priorities.
This does not have to be a full-time role in every company. But it should have a named owner, dedicated time every week, and a clear mandate from leadership. The accountability gap is where programs quietly die: BCG's research on transformation success found that only about two in five organizations adequately monitor progress, compared with roughly 90% of the programs that actually win. Without this role, automation often stops after the first two or three processes. No one owns the next wave, no one resolves conflicts between departments, and no one decides whether a workflow is worth automating now or later.
3. Build a network of internal champions
Transformation cannot live only with a central program owner. Each major domain needs people who understand the work and can translate it into automation opportunities. We usually recommend building a network of internal champions.
In a retailer or FMCG company, champions might sit in commercial, supply chain, finance, HR, procurement, category management, master data, logistics, or operations. A champion is not a developer and not a project manager. They are a domain-level advocate and translator. Their job is to spot valuable workflows, help document how the process really works, support adoption in their area, and bring new use cases into the transformation cadence.
Good champions usually share four traits: they know the process better than the org chart does, their team trusts them, they can explain what should happen when exceptions appear, and they have time allocated for the program. This is the same shift that makes a business-user-first automation model outperform the IT-first alternative, with business users now building far more of their own automations than central development teams can.
For smaller organizations, three or four champions may be enough. For large enterprise programs, there may need to be many more across domains, countries, or business units. The common mistake is choosing champions only because they are good with tools. That helps, but it is not the main criterion. Process knowledge, credibility, and willingness to drive adoption matter more.
4. Give every use case a business owner and an operator
Each automation use case should have two named people before implementation starts.
The first is the business owner. This person is accountable for the outcome of the workflow. They decide what good looks like, approve priorities, resolve business tradeoffs, and confirm whether the automated output is acceptable for the company. The second is the operator: the person who actually performs the work today, or is closest to the team that does. After automation, they remain essential. They oversee the AI agent, guide it with examples, spot wrong outputs, explain exceptions, and help improve the workflow over time.
Both roles matter. If there is no business owner, no one can make decisions when there is a tradeoff. If there is no operator, the automation team loses the practical knowledge that makes the workflow work in real life. For every use case, agree on four points before launch:
- Business owner: the person accountable for the business outcome and sign-off.
- Operator: the person who knows the current work and will oversee or guide the AI agent after automation.
- Acceptance definition: what counts as an acceptable output.
- Baseline and correction threshold: how the process performs today, and how much manual correction is acceptable after launch.
A practical target might be 20% manual correction at the beginning and 5% after two months, though the right number depends on the process. The exact target matters less than agreeing on it upfront. Put this into a one-page process brief. If the use case cannot be explained on one page, it may need more preparation before automation starts.
This is not bureaucracy. It prevents disputed decisions later. When production questions arrive, someone needs to decide whether the AI agent is wrong, the rule is missing, the operator needs to guide it differently, or the process itself needs to change.
5. Move platform governance to the customer early
If the vendor remains the default admin for everything, the customer remains dependent. Access changes, offboarding, permissions, workspace hygiene, and basic governance should sit with the customer. The vendor can set guardrails, coach the setup, and support escalations, but the customer should own the operating environment.
This matters because governance questions become adoption questions. If every access change waits for an external team, the platform feels external. If the customer owns governance, the platform becomes part of the company's normal operating system.
The exact setup will differ by customer. In some organizations governance sits with business transformation. In others it is shared with IT, operations, or a central automation team. The important point is that ownership is explicit.
6. Create one shared operating channel
Digital transformation gets messy when decisions are split across private messages, scattered Teams chats, old email threads, and one-off calls. We recommend creating one shared channel for the transformation owner, champions, business owners, operators, and the vendor team. Use the customer's tool of choice, such as Slack, Teams, or another internal collaboration tool.
The channel should become the default place for new use-case ideas, questions from champions and operators, known issues and examples, process decisions, training recordings, and answers that should be visible to others later. Private messages are where ownership disappears. A shared channel creates memory, reduces duplicate support, and helps champions and operators learn from each other.
The channel should not become a passive helpdesk queue. It should feel like an operating room for the transformation program: practical, visible, and tied to real workflows.
7. Treat the first eight weeks as a controlled adoption phase
The first weeks after launch are not just technical tuning. They are where the team learns to trust the automation, and where the AI agent learns from real business behavior. Track a few simple numbers every week: how many outputs were produced, how many were accepted without changes, where the largest manual correction happened, why it happened, and whether the same correction is repeating.
A five-minute weekly review is often enough. The trend matters more than the first number. If acceptance is not improving after six to eight weeks, the cause is usually one of three things: the automation is missing a rule or needs configuration changes, the acceptance definition is unclear, or the process has too many exceptions and is not mature enough yet.
Concrete examples are more useful than opinions. "The team does not trust it" is not actionable. "These 12 outputs were corrected because supplier minimum order quantities were missing" is actionable. This is where the operator becomes especially important, because they are the person who can tell whether the AI agent is making a genuine mistake, missing a business rule, or producing something that is technically correct but not usable in practice.
8. Expand before you over-optimize
One trap is spending five months fine-tuning the first process while the larger opportunity waits. After two months of live operation, improving acceptance by another few percentage points may be less valuable than automating the next process. The transformation owner should make that tradeoff deliberately.
A simple expansion sequence works well:
- Select a process with repeated decisions, available data, and a clear owner.
- Map the current process and improve obvious weak points before automation.
- Measure the current baseline for two weeks.
- Prepare the one-page process brief with business owner, operator, acceptance definition, baseline, and correction threshold.
- Run the automation in parallel with the existing process for two to four weeks.
- Move into live operation with a weekly review.
This creates a repeatable transformation engine instead of a one-off automation project, and it is how organizations climb the automation maturity curve from scattered pilots toward operations that mostly run themselves.
What good looks like
A well-run transformation program shows up in behavior, not in steering slides. You know the model is working when champions bring new use cases without being chased, operators can explain what the AI agent is doing well and where it needs guidance, and business owners can define acceptance criteria and make tradeoffs. Support questions move from private messages into the shared channel. Governance sits with the customer. Executive meetings shift from operational cleanup to adoption, roadmap, and expansion.
No two customers will implement this in exactly the same way. Some will start with one department. Some will build a central automation office. Some will begin with a narrow process and expand only after trust is built. That is fine. The operating model should fit the organization. But the underlying principle is consistent: automation scales when the customer builds ownership around it. The companies that get this right do not just automate isolated tasks. They build the internal muscle to keep finding, launching, and improving the next wave of high-value workflows.
Why Duvo Is the Ideal Solution
The operating model above is the hard part of transformation, and it is exactly what Duvo is built to support. Duvo Clarity maps the real process first, capturing the steps, systems, handoffs, and exceptions that normally live only in people's heads, so a workflow is understood before it is automated. From there, Duvo's AI agents run the operation end to end across the systems a retail or FMCG team already uses, including SAP, Oracle, supplier portals, carrier sites, WMS, Excel, and email. High-risk actions wait for human approval, and every outcome is documented, which keeps the business owner and operator firmly in control during the controlled adoption phase.
Because business users build and deploy agents in natural language with no code, your champions become the people who actually expand the program, and governance can sit with the customer from day one. The model produces compounding results: at Rohlik, Duvo surfaced roughly one million euros of goods recorded as inbounded but missing from the warehouse, and at Pilulka it moved A and B item availability up 15% in two weeks. One predictable subscription, live in weeks rather than months. If you want to set your organization up to own the change, see how Duvo works at duvo.ai or book a demo.
Frequently Asked Questions
Why do most digital transformation programs fail?
Most digital transformation programs fail because of organizational ownership, not technology. McKinsey and BCG both estimate that around 70% of large-scale transformations fall short of their goals, and the recurring causes are weak accountability, low adoption, and culture rather than missing tools. Transformations that name a clear owner, monitor progress, and build adoption succeed at far higher rates.
Who should own a digital transformation program?
One accountable business owner should own the program, with a mandate from leadership and dedicated time every week. The title varies, such as Head of Transformation or AI Adoption Manager, but the person sits above individual processes and owns prioritization, change management, the partner relationship, and visibility into value delivered. Without this role, automation usually stalls after the first two or three processes.
Should you automate a process before improving it?
No. You should map and, where needed, improve a process before automating it. Automating a broken, undocumented, or contested workflow exposes the problem faster instead of solving it. A useful test is simple: if the business cannot explain the current process clearly, it is probably too early to automate it.
How many transformation champions does an organization need?
It depends on size. Three or four domain champions may be enough for a smaller organization, while large enterprise programs may need many more across departments, countries, or business units. The right champions are chosen for process knowledge, credibility, and willingness to drive adoption, not just for being good with tools.
How long does it take for automation adoption to stabilize?
Plan for a controlled adoption phase of about eight weeks after launch, with a short weekly review of how many outputs were accepted and why corrections happened. A practical correction target is around 20% at the start and 5% after two months. If acceptance is not improving after six to eight weeks, the cause is usually a missing rule, an unclear acceptance definition, or a process that is not mature enough yet.
What is the difference between buying automation and building transformation capacity?
Buying automation is a sequence of isolated tool projects that each solve one task. Building transformation capacity means standing up an operating model, including a program owner, champions, business owners and operators, customer-owned governance, and a repeatable expansion sequence, so the organization keeps finding and launching the next high-value workflow. The first approach plateaus after a few pilots; the second one scales.
Sources
- McKinsey & Company. Why do most transformations fail? A conversation with Harry Robinson.
- McKinsey & Company. Common pitfalls in transformations: A conversation with Jon Garcia.
- Boston Consulting Group. Flipping the Odds of Digital Transformation Success.
- Boston Consulting Group. How CEOs Can Beat the Transformation Odds.
- Harvard Business Review. Leading Change: Why Transformation Efforts Fail (John P. Kotter).