- >
- Digital Transformation>
- Who Actually Drives Digital Transformation? The People Behind Every Rollout
Who Actually Drives Digital Transformation? The People Behind Every Rollout
TL;DR
- Digital transformation fails or succeeds on four groups of people, not on the software: leaders who set direction, business teams who run the new process daily, IT who governs it, and customers who judge whether it actually helped them.
- Only 48 percent of digital initiatives meet or exceed their business outcome targets, and Gartner traces the gap between high performers and everyone else to who owns delivery, not which tool they bought.
- AI changes what each group does day to day: agents now prepare the information people need (data pulled, policies checked, drafts assembled), while people keep the decision.
- Business users becoming "citizen developers" is the fastest-growing source of new workflows, but it only holds up long-term if IT keeps governance over data, access, and integrations.
- The most common failure point is still cultural resistance to change, not a missing feature. Naming that early, in plain terms, is the fix most transformation plans skip.
Best for: Operations and transformation leads, CIOs, and department heads at mid-size and large organizations who need buy-in across leadership, line-of-business teams, and IT before a transformation program can move past the pilot stage.
Definition: Digital transformation is the process of redesigning how a business operates and delivers value using technology, and it succeeds or fails based on how well the people running, building, and using that technology adapt to the new way of working.
Why the technology is rarely the reason transformation stalls
Most transformation budgets go to software, integrations, and infrastructure. Most transformation failures trace back to people: a workflow nobody adopted, a leadership team that lost interest after the kickoff deck, or a department that quietly kept its spreadsheet because the new system didn't fit how they actually work.
Gartner's 2025 CIO and Technology Executive Survey, covering more than 3,100 CIOs and technology executives across 88 countries, found that only 48 percent of enterprise digital initiatives meet or exceed their business outcome targets. The research also identified a smaller group Gartner calls the "Digital Vanguard," where 71 percent of initiatives hit their targets. What separates that group is not better technology. Gartner's own research attributes it to shared ownership: these organizations have CIOs and business leaders who co-own delivery, instead of IT building something and handing it over.
That single finding reframes the whole question. The technology stack is a necessary input. The people who lead, build, and use it are the actual mechanism of success or failure.
What AI changes about who does the work
Before AI, a workflow routed a request from one inbox to the next, and a person had to read every document, check every policy, and decide at every step. That is still largely true for organizations that have not updated how their workflows run.
With AI in the workflow, an agent reads the incoming request, checks it against policy, pulls the related records, and flags what's missing or risky, before a person ever opens the request. The person still decides. What changes is how much manual digging they do to get to that decision. Agents prepare; people decide. That shift matters for every one of the four groups below, because it changes what "doing the job" looks like for leaders, business teams, IT, and the customers all of this is supposed to serve.
The four groups who actually drive the outcome
Visionary leaders set the direction, not the toolset
MIT Sloan's George Westerman has argued for years that digital transformation is a leadership challenge well before it is a technology one, and his more recent work pushes that further: because AI moves faster than most organizations' planning cycles, leaders now need what he calls "directive emergence." That means staying anchored to the outcome the business needs, while treating the path to get there as something that gets adjusted as new information comes in, not locked into a two-year roadmap on day one.
The title on this person's door matters less than whether they can hold that outcome steady while the plan under it keeps changing. In practice that role sits with a Chief Digital Transformation Officer where one exists, or with the CIO, CTO, or CEO where it doesn't. What doesn't work is a steering committee that approves a plan once and checks in at the next quarterly review.
Business heads are the ones who make or break daily adoption
The people running procurement, finance, HR, and operations are the ones who decide, in practice, whether a new process sticks. They are also increasingly the ones building it. Business users who describe what they need in plain language, a form, a sketch, or a short brief, and get a working application or workflow back through a no-code app builder without waiting on an IT backlog are usually called citizen developers, and this is the fastest-growing source of new internal applications inside large organizations right now.
SN Aboitiz Power Group's experience is a useful, verified example of what this looks like in practice: "Simplicity in Kissflow democratizes application development through low-code and no-code solutions." The company's citizen development program has automated more than 95 processes and delivered a 451 percent ROI, independently measured by Nucleus Research, by reducing how much work had to route through third-party developers.
Citizen development only holds up if it has a ceiling. Business heads should own the request and the logic; IT still owns the data model, the access rules, and what the workflow is allowed to touch.
IT teams shift from building everything to governing what gets built
Professional developers do not disappear in this model. Core integrations, security policy, and anything touching regulated data still need engineering judgment that a business user shouldn't be asked to carry. What changes is the volume of routine requests IT has to personally build.
When business teams can build their own forms and workflows inside guardrails IT sets, the IT backlog stops being the bottleneck for every small process change. IT's job moves from "build the thing" to "define what business users are allowed to build, and keep an audit trail of what changed and who approved it." That's a governance function, not an abdication. No-code AI agents that read a request and draft a response still run inside rules IT wrote, and nothing they do skips the human approval step that governance requires.
The Kanoo Group, a 135-year-old conglomerate spanning shipping, oil and gas, travel, and real estate, described this shift directly: Kissflow "acts as the middleware that connects everything, from backend systems to front-end operations," letting both IT-led and citizen-led applications run on the same governed layer instead of as separate, disconnected efforts.
Customers are the only group whose verdict actually counts
A transformation program can hit every internal milestone and still fail if it doesn't change what the customer experiences. Internal process speed is a means, not the end. The questions that matter are whether a customer's request gets resolved faster, whether their data is handled consistently across channels, and whether the organization can explain, with evidence, what changed for them.
Customer expectations also keep moving, which means a transformation plan built around today's expectations is already slightly out of date by the time it ships. Tracking the gap between what customers now expect and what a process actually delivers, revisited on a real cadence rather than once at kickoff, keeps the rest of the transformation program honest about whether it is working.
Where transformation plans actually break
Digitizing a process is the comparatively easy part. Changing how people work around that process is where most plans stall, and the pattern behind most digital transformation failures traces back to one of these three points rather than the technology itself.
Organizational change gets treated as a side effect instead of a plan. A new system rolled out without a sequenced change plan, without a clear owner for adoption, and without a way to measure whether people are actually using it the way it was designed, tends to decay into a shadow process within a few months. The fix is not complicated, but it is specific: name who owns adoption, set a measurable adoption target (not just a go-live date), and revisit it on a fixed schedule rather than hoping it holds.
Upskilling gets underfunded because hiring looks easier. Replacing a team that doesn't know a new system is usually more expensive and slower than training the team already in the building, especially when the tooling itself doesn't require a programming background to use. The real constraint is rarely aptitude. It's usually that nobody budgeted time for training against a go-live date that didn't move.
Cultural resistance gets named too late. By the time leadership notices resistance, it has usually been visible to frontline staff for months. A paper-based team told to switch to digital approvals doesn't resist the software. They resist an approval chain they don't understand and weren't consulted on. Naming the resistance early, in a plan rather than a postmortem, and involving the people affected before the system is finalized, is the difference between adoption and a workaround. These three points show up repeatedly across the digital transformation best practices drawn from organizations that got this right.
There is a real risk on the other side of this too: an organization that moves all its approvals, data, and records into one governed platform depends on that platform's uptime, access controls, and audit trail being genuinely solid. That's a legitimate tradeoff to evaluate, not just upside to assume. Kissflow publishes its uptime status and holds SOC 1 Type II, SOC 2 Type II, SOC 3, ISO/IEC 27001, HIPAA, GDPR, and CCPA certifications, which is the kind of thing worth checking before consolidating critical processes onto any platform, not only this one.
Before AI vs. with AI: what changes for each group
| Group | Before AI | With AI in the workflow |
| Visionary leaders | Set a fixed multi-year roadmap and review it quarterly | Hold the outcome steady; adjust the path as conditions change ("directive emergence") |
| Business heads | Submit a ticket and wait for IT to build the workflow | Describe the process in plain language and get a working app or workflow back, inside IT's guardrails |
| IT teams | Build and maintain every workflow personally | Set the rules, data access, and audit trail; review what business users built against them |
| Customers | Experience whatever speed the internal process happens to run at | Experience a process where an agent has already assembled and checked the information before a person acts on it |
What to measure instead of just the go-live date
A transformation program needs a small number of metrics tracked past launch, not just at launch:
- Adoption rate at 30, 60, and 90 days after rollout, not just on day one
- Cycle time for the specific process being transformed (an approval, an onboarding step, a procurement request)
- The ratio of workflows business teams build themselves versus workflows still waiting in the IT backlog
- Customer-facing outcomes tied to the process (resolution time, error rate, repeat contacts)
If none of these move in the first 90 days, the technology is very likely not the problem.
Why Kissflow powers a governed layer for all four groups
Kissflow is an enterprise-grade platform for building, running, and governing Agentic AI applications. It starts with a domain expert or developer describing the application in natural language. Then, Kissflow builds the complete application, covering data models, AI agents, business rules, events, forms, workflows, navigation, roles, access control, and UI elements as a coherent application rather than a prompt chain. The Agentic AI Applications are executed within a secure, governed sandbox, with humans in the lead at defined decision points, so that nothing goes out of your control. Kissflow is used by Fortune 500 companies and large enterprises across 87 countries. Since 2012, Kissflow has helped enterprises automate and govern their complex business processes. Kissflow's extensive connectors and MCP capabilities make it very easy to integrate with other enterprise systems, like SAP, Oracle, Microsoft, and Salesforce.
That is the same structure the four-stakeholder breakdown above describes: business heads build inside roles and access control IT defines, while agents prepare the work and humans stay in the lead at every decision point that matters.
See how Kissflow lets business teams build their own workflows without losing IT's governance over data and access. Book a demo to walk through a citizen development rollout built for your organization's approval structure.
Frequently asked questions
Who is actually responsible for digital transformation succeeding?
No single role owns it. Leadership sets and holds the direction, business teams adopt and often build the new processes, IT governs what gets built and keeps it secure, and customers are the ultimate judge of whether any of it worked. Gartner's research on high-performing "Digital Vanguard" organizations found the common factor was shared ownership between CIOs and business leaders, not a single accountable executive.
Should digital transformation focus on technology or people?
Neither alone. Technology without a plan for how people's day-to-day work changes tends to get adopted on paper and ignored in practice. People-focused change management without the right tools just makes an old process slightly more bearable. The two have to move together, with the technology decision made after the people and process decisions, not before. For the employee-experience side of this specifically (productivity, engagement, day-to-day tools), see Kissflow's guide to digital transformation for employees.
Why do employees resist digital transformation?
Usually because they were told what was changing without being told why, or without being consulted on how it would affect their specific job. Resistance is rarely about the software itself. It is about uncertainty: whether their role still exists, whether they'll be able to do the new version of their job competently, and whether anyone asked them first.
What is a citizen developer, and should IT be worried about them?
A citizen developer is a business user who builds their own applications or workflows, usually by describing what they need rather than writing code, instead of filing a ticket and waiting for IT. IT's role doesn't disappear. It shifts to setting what data citizen developers can touch, what integrations they can use, and keeping an audit trail of what they built and changed.
How do AI agents change the day-to-day work of digital transformation?
Agents take on the preparation work: gathering documents, checking them against policy, flagging what's missing or inconsistent. People keep the decision at every step that matters. The practical effect is that the person approving a request spends less time hunting for information and more time actually deciding, with a complete record of what the agent checked.
How is digital transformation different now than it was five years ago?
Five years ago, "digital" mostly meant replacing paper and spreadsheets with software that still required people to do every step manually inside it. Now the shift is from digitizing the paperwork to redesigning the work itself around agents that prepare information and people who decide, which is a bigger change than most "digital transformation" initiatives from that era actually attempted.
Related Articles