Systems Reliance: When the tool becomes the strategy

The Promise and the Pitfall of Platforms

For many organizations, platforms promise salvation. ERP systems, CRMs, and workflow tools are seen as vehicles for scale, speed, and transformation. When adopted, they come with bold expectations: improved consistency, automation, visibility, and control.

But that promise often comes with a cost.

In practice, platform initiatives are slow, rigid, and resource-intensive. They rarely deliver at the speed or flexibility leadership hopes for. More often, they lock in assumptions that no longer hold, reflect workarounds instead of workflows, and shape behavior in ways no one quite intended.

The result is familiar. The platform goes live, but the real transformation never quite follows.

How Systems Take Over

System reliance doesn’t happen all at once. It builds over time as tools and platforms gradually shift from supporting the work to shaping it. The result isn’t always resistance, but quiet compliance.

Here are some of the signals we see:

🧮 Platform-first thinking

Platform initiatives too often focus on capability instead of purpose. ThoughtWorks describes platform thinking as treating internal platforms like products — with their own users, roadmaps, and measurable outcomes.

When organizations skip this mindset, they fall into a common trap: build the platform, then hope people will figure out how to use it. As Eduardo Matos puts it puts it, teams often focus so heavily on shipping technical features that they lose sight of the people meant to use them.

When that happens, the platform becomes the frame, not the enabler. The core question shifts from “What problem are we solving?” to “What does the system allow?”

🐌 Process rigidity

Recent research confirms that poor ERP UX remains a major obstacle. A 2025 study from Aalto University showed that reducing unnecessary clicks measurably improves efficiency and lowers user stress, unsurprisingly.

Industry reports back this up: Panorama Consulting notes that intuitive navigation directly drives ERP adoption and productivity. Meanwhile, modern UX trends — such as personalization, AI assistance, and mobile-first design — are reshaping expectations around enterprise platforms.

👤 Shadow systems

When systems don’t match real work, people build workarounds. Gartner reports that 30–40% of enterprise IT spend is on shadow IT—unsanctioned tools teams adopt to get things done (Josys, 2024). Additionally, 65% of all SaaS apps in use aren’t approved by IT, and 59% of IT professionals report struggling to manage them (Zluri, 2023).

Rather than causing outrage, these workarounds often emerge out of necessity. I've heard a person say "I know I should use the systems provided, but for my daily tasks, I use a tool that fits my context better."

🤦🏻 Delayed impact

Delayed impact becomes the norm as platforms are delivered but intended value is postponed. Go-lives are declared successful even when usage is low or fragmented. Often, the project becomes the stand-in for transformation itself. Leadership places all hopes for change on a tool, only to realize too late that culture, process, and alignment were left untouched. Nike's supply chain disaster exemplifies this pattern: a $400 million ERP implementation led to $100 million in lost sales and a 20% stock price drop when software glitches caused massive order fulfillment problems. A quiet question sometimes follows: "And this was supposed to fix everything?"

These patterns aren’t signs of failure. They’re signs that the system is taking precedence over the people it was meant to support. And in large-scale initiatives, the goal is often to land the rollout, not to rethink how work should actually flow.

Why This Happens

Systems are usually selected and implemented with the best intentions. They’re meant to bring alignment, speed, and clarity. But they often fail because they assume that processes are known, workflows are stable, and teams operate in clean handovers.

That’s rarely true.

When friction and disconnects are unresolved, platforms can simply automate the chaos. And when systems are brought in without enough attention to context, incentives, or actual usage, they become monuments to misalignment.

The British Post Office’s Horizon system case perfectly illustrates this. For over a decade, the system falsely indicated financial discrepancies at local branches. But rather than questioning the technology, the organization prosecuted hundreds of sub-postmasters for theft and fraud. The system had become so central to operations that challenging its accuracy seemed impossible — even when people’s lives were at stake. Computer Weekly reports that more than 700 subpostmasters were prosecuted for crimes such as theft and false accounting, with many sent to prison, before the system’s flaws were finally exposed.

“We shape our tools; thereafter they shape us.” – John Culkin

We’ve seen this play out in public healthcare, where large-scale platform rollouts promise transformation but end up overwhelming staff with rigid workflows, poor interfaces, and a lack of fit to daily practice. The system goes live, but the system doesn’t listen.

In many organizations, platform projects shift decision-making in ways no one planned. Instead of strategy guiding the system, the system begins guiding strategy — and IT becomes the de facto orchestrator of change. As ERP Today notes, CIOs are “becoming the innovation orchestrator… implementing an ‘enterprise control plane’ to govern corporate processes and data flows.”

That shift isn’t inherently negative. In fact, some CIOs embrace this role by integrating business thinking and design-led practices into IT. As Vipin Gupta of Toyota Financial Services puts it, “Good CIOs transform IT from inside, but great CIOs use design thinking and inclusivity to transform IT by changing what happens outside of IT.”

But a deeper challenge emerges when platforms are extended without foresight — particularly through the introduction of AI capabilities. AI is increasingly embedded in ERP and CRM platforms, often in the name of innovation. But as Forbes notes, this frequently leads to complexity, not clarity — especially when AI is layered on top of already misaligned systems. The platform ends up automating the noise instead of clarifying the signal.

This happens in part because platform scope decisions are often made at the leadership level — but handed off too quickly to IT and vendors. Senior leaders want transformation, but assume the tool will deliver it. By the time real-world complexity surfaces, decisions are locked in, and leadership has stepped away.

And the costs aren’t just technical. When these projects go wrong, they don’t quietly fade away, but they grow. Scope expands, deadlines shift, budgets inflate. As a result, revenue pressures rise. The organization is forced to save somewhere else — and too often, that means jobs.

In global organizations, this pressure becomes even harder to manage. Multi-region rollouts promise scale, but struggle to accommodate local variation. Markets with different regulations, roles, or operating models are typically squeezed into a single system logic. Instead of alignment, the result is friction on a global scale — and a growing reluctance to raise issues, for fear of slowing things down even more.

What’s worse, the pressure to recoup investment often forces teams to work around the flaws instead of fixing them. Platforms become too big to challenge — especially when billable work or go-live deadlines take priority over usability, clarity, or adaptation.

Design’s Role in Reframing Systems

This is where service design offers a better path forward — not through a full transformation blueprint, but through grounded methods that reveal what’s really happening inside the system. While systemic design methods still support the work — especially in narrative framing and leadership engagement — the primary tools here are practical and operational: blueprinting, journey mapping, and process design.

Rather than relying on assumptions or abstract process models, design starts by observing actual behavior — and co-creating alternatives with the people doing the work. It traces where work flows, where it breaks down, and where systems begin to constrain rather than support. These observations and shared acts of making often surface what business cases miss: the shadow processes, duplicated effort, and unmet needs hidden inside formal workflows.

Service Blueprinting plays a central role. It gives teams a shared view of how people, systems, data and processes interact across silos, channels, and tools. A well-built blueprint shows where the platform helps, where it hinders, and where additional context is needed to make the system work as intended.

Beyond that, journey operations — the practice of maintaining and evolving journeys over time — helps ensure systems stay aligned with evolving business needs. It shifts platform implementation from a one-time deployment to an ongoing conversation about experience, outcomes, and ways of working.

In practice, these methods help answer critical questions:

• Where does the platform reflect real work, and where does it distort it?
• Where are people working around the system, and why?
• What process steps look clean on paper but break down in reality?

This is where process design enters — not just to map what should happen, but to shape what could happen. It brings clarity to workflows, connects intent to execution, and translates cross-functional needs into something scalable. When paired with service design, it ensures the resulting systems are not only desirable, but operationally sound.

Design doesn’t just document these questions, it prototypes alternatives. It offers something visible and testable that different stakeholders can react to, long before anything is configured.

Design works best when slotted alongside the planning or configuration of platforms — offering visibility, clarity, and alignment as configuration decisions are being made. In one large-scale ERP rollout we supported, just two designers worked alongside tens of implementers — mapping real user needs, visualizing cross-functional flows, and showing what good could look like. The result was stunning: faster consensus, fewer rework cycles, and a platform that fit more than just the default process.

That kind of impact doesn’t require control. It requires timing, clarity, and presence. Design’s strength isn’t in running the program — it’s in shaping how the program understands what’s worth solving, and what working actually looks like.

Design Systems as a Bridge

One of the clearest examples of this is the rise of Design Systems.

Design Systems are not just UI kits. When done right, they connect platform logic with business context. They make consistent implementation faster, but also allow flexibility where it matters. They reduce repetition, improve accessibility, and align teams across tech and product.

A robust Design System typically includes UI kits, design tokens (such as colors, spacing, and typography), component libraries, code packages, accessibility guidelines, documentation, and unified ways of working. Together, these allow organizations to look, act, and feel cohesive across markets — while significantly reducing the replicated effort of designing and building interfaces.

But the most critical benefit is speed. Design Systems have a measurable impact on time-to-market, often shaving weeks or even months off delivery timelines by eliminating the need to reinvent basic patterns over and over again.

And in doing so, they give teams something even more valuable than consistency: time. Time to focus on more complex and strategic challenges, like aligning platform efforts to reality, resolving disconnects, and reducing organizational friction. In this way, Design Systems don’t just improve delivery. They contribute to clarity, culture, and meaning across the organization.

In platform-heavy environments, that becomes a strategic advantage. Design Systems allow teams to speak the same language — not just visually, but functionally. They bridge what the system expects and what people need.

When Design Enters

Design doesn’t always arrive at the start of a platform journey. In fact, it often shows up late — after rollout, when adoption lags, workarounds emerge, or teams start asking why the system doesn’t fit.

At that point, the mission shifts. It’s no longer about influencing configuration — it’s about helping teams reclaim and reshape what’s already there. Design methods discussed above become tools for sense-making and salvage.

But when design enters early, the impact multiplies. Before anything is hard-coded, teams can test assumptions, shape roles, co-create processes, and define what good actually looks like.

Why This Matters

When organizations place too much hope in systems alone, they often end up designing for the platform instead of the people. That may stabilize operations, but it rarely unlocks change.

The result is a familiar loop:

1. Tools are rolled out to bring consistency.
2. People adapt through workarounds.
3. The platform becomes harder to challenge, even when it’s misaligned.
4. Momentum fades, while frustration builds.

This isn’t just a usability problem, but a structural one. Left unchecked, system reliance quietly shifts power, shapes decisions, and limits what teams believe is possible. It can stall transformation not through resistance, but through compliance.

That’s why design matters here. Not to decorate what exists, but to question what should. Not to configure a better menu, but to help teams ask the right questions before choosing the restaurant.

But this shift requires designers to step up, again. Many organizations still don’t see design as relevant in the context of platforms — and often, neither do designers themselves. It’s a space dominated by enterprise architecture, vendor sales, and implementation timelines. Yet it’s precisely because of that, that design is needed: to bring real use cases, human clarity, and operational sense-making into the room.

Because systems aren’t the strategy, but they shape how strategy shows up.

And if we want change to accelerate, we need to make sure we’re designing the right system, not just implementing the available one.

______

Participate in the discussion:Change Acceleration Series in LinkedIn:

1. From Designers to Change Agents
2. Friction - Where Momentum Gets Stuck
3. Disconnects – When The Signal Breaks Down
4. Systems Reliance – When The Tool Becomes The Strategy (you are here)
5. Blind Spots – When Critical Signals Go Unseen
6. -
7. -

‍