Why the success of a system depends on the story people believe about it.
ERP transformations are rarely described as storytelling problems.
They’re framed as technology implementations, process redesign efforts, operational transformations. And from a program perspective, that framing is accurate. The work is technical. The timelines are precise. The configuration is complex.
But from a human perspective, something else is happening simultaneously.
Every ERP transformation is also a narrative shift.
Not a metaphorical one — a structural one. The organization’s story about how work gets done, who owns what, what good performance looks like, and how teams coordinate is being rewritten. Whether that rewrite is designed or left to chance determines how the organization experiences the change — and ultimately whether the system gets adopted or merely tolerated.
The story already exists — whether you design it or not
When a major system transformation is announced, people don’t wait for the official communication to fully understand it. They start constructing a story immediately — quietly, individually, and collectively. That story answers the questions that official communication almost never addresses directly.
Why is this really happening? What does leadership actually care about — is this about cost reduction, control, or genuinely making work better? What does this mean for people like me specifically? Is this going to make my work easier or harder? What happens if this doesn’t go well for the organization — or for me personally?
If the organization doesn’t provide a clear narrative that answers those questions, people will provide one themselves. They’ll draw on past experiences with previous system transitions. They’ll piece together partial information from project announcements and hallway conversations. They’ll triangulate between what different leaders are saying and construct their own interpretation of what’s really going on.
And once that narrative forms — once the informal story has taken root across teams and functions — it is very difficult to replace with an official one. The unofficial story has the advantage of feeling honest precisely because it emerged organically rather than being produced by a communications team. Organizations that design their narrative early prevent this dynamic. Organizations that don’t spend months trying to compete with a story they never intended to create. (For how this dynamic plays out in broader change programs, read From Noise to Narrative.)
Why ERP transformations amplify narrative risk
In smaller changes, gaps in communication are manageable. The scope is limited, the number of people affected is contained, and the informal story that fills the gaps doesn’t have far to travel before it encounters the official one.
In ERP transformations, those gaps compound — because ERP touches everything. Finance. Supply chain. Operations. Field work. Reporting. Decision-making structures. Approval hierarchies. Cross-functional coordination. The breadth of impact means that the number of different interpretations multiplies quickly, and each interpretation travels through a different part of the organization before anyone at the center notices the divergence.
One team hears: “This will streamline our work.”
Another hears: “This is going to slow us down during implementation.”
A third hears: “This is about cost reduction and headcount.”
A fourth hears: “This is about visibility and control.”
Same program. Same announcement. Different stories.
This is narrative drift in its most amplified form — not because leaders are contradicting each other, but because a complex change with multiple dimensions is being received through multiple different filters, and nobody has designed the single narrative that provides the coherence those filters need to produce a consistent interpretation.
The longer this drift runs unchecked, the harder it is to reverse. By the time an ERP program reaches go-live with fragmented narratives across functions, the communication effort required to create coherence is significantly larger than it would have been if a single narrative had been designed and reinforced from the beginning. (For more on how narrative drift develops and compounds, read Why ERP Projects Fail.)
What storytelling actually means in this context
This is where most organizations get it wrong — and where the word “storytelling” itself creates confusion.
Storytelling in ERP transformations is not making the change sound exciting. It’s not adding emotional language to a project update. It’s not writing more engaging emails or producing a slick launch video.
Storytelling is structure.
It’s the discipline of ensuring that every communication — from the executive announcement to the manager briefing to the training material to the help desk FAQ — answers the same core narrative questions in a consistent way:
Where are we now, and what’s not working about it? What is changing, and why is this the right response? What does this mean for the people in this organization specifically? Where are we going, and what does success look like when we get there?
When that structure is present, people can orient themselves inside the change. They can locate the individual messages they receive within a larger story that makes sense. The announcement makes sense. The training makes sense. The go-live communication makes sense. Not because each piece is well-written, but because they all point toward the same coherent narrative.
When the structure is absent, even well-written communications feel disconnected. People receive updates without being able to place them in a meaningful sequence. Information accumulates without producing understanding. And eventually, communication itself loses credibility — not because it’s inaccurate, but because it feels like noise. (For the mechanism behind this, read What Is Change Communications?)
The difference between information and narrative
ERP programs are very good at distributing information. System features, deployment timelines, training schedules, go-live milestones, cutover procedures — this content is produced in abundance, distributed through multiple channels, and tracked for completion.
But information doesn’t create alignment.
Narrative does.
Because information and narrative answer different questions. Information answers “what is happening?” Narrative answers “what does this mean?” Those are different cognitive tasks — and the second one is the one that determines whether people change their behavior.
When people receive information without narrative, individual pieces of content feel disconnected. Updates feel repetitive rather than progressive. Communication feels like noise rather than signal — something to manage rather than something to engage with. Signal fatigue builds. People stop paying attention to official channels because those channels have never given them the meaning they needed, only the facts.
When narrative is present — when every update connects back to the same core story, when the meaning of each piece of information is made explicit within the larger arc — something different happens. People understand how the pieces fit together. They can explain the change to someone who asks. Leaders reinforce the same message without being scripted. Teams move in the same direction because they’re oriented by the same story rather than confused by competing versions of it.
This is the difference between a communication program and a narrative architecture. Communication programs produce content. Narrative architectures produce shared understanding. ERP transformations need the second one — and most invest almost entirely in the first. (For how to build narrative architecture, read The Clarity Framework™.)
What strong storytelling looks like in an ERP transformation
Strong storytelling in an ERP context is not louder. It’s more consistent. It’s not more emotional. It’s more structured. Here’s what it looks like across four dimensions.
1. One narrative spine
Every message — from executive announcements to manager cascades to training materials to go-live communications — reinforces the same core story. Not variations of it. Not each leader’s interpretation of it. The same story, with the same language anchoring the same why, repeated consistently across phases and channels.
This requires deliberate work before any communication goes out. The narrative spine has to be defined, agreed upon, and tested with leaders before it cascades — because once different versions are in circulation, consolidating them is far harder than building coherence from the beginning. The Anchor Framework™ is designed precisely for this: define the purpose, anchor on truth, decide on direction — before the first message is drafted.
2. Translation without distortion
Different audiences need different levels of detail and different entry points into the story. A field technician, a finance analyst, and a senior operations leader all need to understand the same transformation — but they need to understand it from the perspective of their own role, their own workflow, their own definition of success.
The discipline of translation without distortion means that the core narrative stays consistent while the entry point and the specificity change. The why is the same. The direction is the same. The implications are audience-specific. This is what the Messaging Matrix is designed to produce — one story, multiple translations, zero distortion of the core meaning.
When this discipline is absent, different groups receive different stories. Each leader customizes the message for their audience without checking whether the customization is consistent with what other leaders are communicating. The narrative fragments in exactly the way that produces the “same program, different stories” dynamic that ERP programs are most vulnerable to.
3. Narrative before detail
Most ERP programs lead with what’s changing — the system features, the process changes, the new workflows. Strong programs lead with why it matters — the problem being solved, the reality that makes the change necessary, the future state that justifies the disruption.
This sequencing matters for a specific reason: people need meaning before they can process detail. The brain doesn’t absorb information neutrally — it absorbs it within the frame that’s already been established. When the frame is “this system is solving a real problem that affects your work,” the details land inside a meaningful context. When the frame is absent — when the details arrive before the why — they land in a vacuum and produce the confusion that programs then try to fix with more detail. (For the psychology behind why sequencing matters, read The Psychology of Alignment.)
4. Reinforcement over time
Storytelling isn’t a launch event. It’s a rhythm.
In ERP transformations that run twelve to twenty-four months, the narrative has to be sustained — not repeated verbatim, but reinforced consistently so that the core story remains coherent as the program evolves, as new phases begin, as go-live approaches, and as post-go-live adoption is measured. The story that makes sense at announcement needs to still make sense at go-live. The why that was articulated in month one needs to be consistent with the why that leaders are articulating in month eighteen.
This requires active narrative maintenance — not just creating the story at the beginning, but tending to it across the full program lifecycle. When narrative maintenance is absent, the story drifts with the program. What started as coherent becomes fragmented. What started as shared becomes contested.
The leader’s role in the narrative
Leaders don’t just communicate the change. They define how it is understood.
Every time a leader describes the ERP transformation — in a town hall, in a team briefing, in a casual hallway conversation — they are reinforcing a version of the story. If that version is consistent with what other leaders are saying, narrative integrity builds. If it diverges, even subtly, the organization feels it. Employees compare versions. They notice the discrepancies. And discrepancies don’t produce synthesis — they produce distrust.
This is why the calm cascade applies directly to ERP storytelling. The emotional tone and the narrative framing that leaders set at the top replicates as it moves through the organizational hierarchy. A leader who describes the transformation with genuine conviction about the problem it solves produces managers who cascade that conviction. A leader who privately doubts the rationale but communicates optimism produces managers who sense the incongruity and communicate with less confidence than the message requires.
Alignment in ERP transformations isn’t just about decisions — it’s about language. The specific words leaders choose, the consistency of the story they tell, and the honesty with which they acknowledge what’s still uncertain are all signals that employees read carefully and interpret as evidence of whether the transformation is genuinely coherent or just managed.
When leaders understand this — when they see themselves as narrative stewards rather than just message deliverers — the quality of communication across the entire program changes. (For how to build that leadership alignment before anything goes out, read Message Alignment: The Anchor Framework™.)
What happens when storytelling is missing
When narrative is not designed, organizations don’t just communicate poorly. They communicate actively against themselves.
Different functions develop different interpretations of what the transformation means. Leaders who haven’t aligned on the story reinforce their own versions — each individually plausible, collectively contradictory. Informal networks fill the gap with narratives that are often more vivid and more trusted than the official ones, precisely because they feel unmanaged.
The organizational symptoms are recognizable: increased escalations from employees who can’t get consistent answers. Managers who hedge when asked to cascade messages because they’re not sure which version of the story is correct. Decision-making that slows because the frame for making decisions hasn’t been clearly established. Growing distrust in official communication channels — not because the content is inaccurate, but because it has stopped feeling like the full story.
And by the time these symptoms surface at the program leadership level, the narrative has usually been fragmented for months. The work of rebuilding coherence is significantly harder than the work of designing it from the start would have been.
What this looks like in practice
I worked with an ERP program team eight months into a large-scale Oracle implementation. The technical work was progressing. Communication had been active throughout. And yet different parts of the organization were describing the same transformation in fundamentally different terms — finance was calling it a “reporting improvement,” operations was calling it a “process standardization,” and field teams had received almost no framing at all beyond the go-live date.
Three different stories. One program.
We paused the content calendar and ran a narrative alignment session with the program’s leadership team — using the Anchor Framework™ to define the single narrative spine that would hold across all three functions and all remaining program phases.
The core story that emerged: the organization had outgrown its legacy systems and the fragmentation was costing real time, real decisions, and real coordination across functions. Oracle was the infrastructure that would let the organization operate at the scale it had already reached.
That story — specific, honest, problem-anchored — became the spine for every communication from that point forward. Finance, operations, and field teams all received the same why with different role-level translations. Manager cascades were aligned. The final twelve weeks of the program ran with narrative coherence that the first eight months had lacked.
Go-live was not without challenges. But the questions people were asking at go-live were fundamentally different from the questions they’d been asking at month eight — more specific, more operational, more forward-looking. The story had landed.
Final thought
ERP transformations are often treated as technical programs with a communication layer added on top.
But communication isn’t a layer. It’s the mechanism that makes the transformation coherent.
Because systems don’t create alignment. Stories do.
If the story is clear — if people understand where they fit, what the change means, and where the organization is going — decisions become easier, behavior begins to shift, and adoption builds.
If the story is fragmented — if different teams are operating from different versions of the same narrative — confusion spreads, alignment erodes, and the system goes live into an organization that was never brought along for the journey.
ERP transformations don’t succeed because the system works. They succeed because people understand the story well enough to work differently inside it.
FAQs: Storytelling in ERP transformations
Storytelling in ERP transformations is the discipline of designing a single coherent narrative that gives every communication — from executive announcements to training materials — a consistent answer to four questions: where are we now, what’s changing and why, what does this mean for people specifically, and where are we going. Without that narrative, information accumulates without producing understanding, and different parts of the organization develop different interpretations of the same change.
Because frequency and coherence are different things. Programs that communicate frequently without a shared narrative produce signal fatigue — too many messages with too little consistent meaning. Each update is individually accurate but collectively confusing because the pieces don’t add up to a story people can orient themselves within. Narrative architecture is what converts individual communications into a coherent program that builds understanding over time.
Narrative drift is what happens when different leaders and functions describe the same ERP program using different language or emphasis — one calls it “standardization,” another calls it “efficiency,” a third calls it “new tools.” Employees don’t reconcile the divergent versions. They distrust all of them. In ERP programs that run twelve to twenty-four months, small narrative divergences at the leadership level compound into significant organizational confusion by the time go-live arrives.
Start with the why — the specific, honest problem the new system solves that the current one doesn’t. Build a core narrative spine that answers: where we are, what’s changing and why, what it means for people, and where we’re going. Test that narrative with leaders before anything is communicated externally. Then develop audience-specific translations that preserve the core story while making it relevant to different roles and functions. Maintain the narrative actively across the full program lifecycle — not just at announcement.
Translation without distortion is the practice of adapting the core narrative for different audiences — with different levels of detail and different role-specific implications — without changing the underlying story. A field technician and a finance manager need to understand the same transformation from the perspective of their own roles. The why is the same. The direction is the same. The role-level specifics differ. When this discipline breaks down, different groups receive different stories and the narrative fragments.
Through the full adoption curve — which extends well beyond go-live. The narrative that’s established at announcement needs to remain consistent and coherent at go-live and through the post-go-live reinforcement period. Most programs invest heavily in pre-go-live communication and go quiet afterward — exactly when the story most needs to be reinforced as people are actually living inside the new system for the first time.
The Clarity Framework™ provides the structural methodology for building and maintaining narrative coherence across a complex, long-running program. The diagnose principle identifies where narrative is fragmenting before it becomes visible as adoption problems. The define principle builds the single narrative spine that all communications then express. The design principle creates the rhythm that sustains narrative coherence over a twelve-to-twenty-four month program. The deliver principle ensures the narrative is communicated with the empathy that makes it receivable. And the measure principle tests whether the story has actually landed — not whether it was distributed.
Ana Magana is a change management and communications strategist based in Calgary, Alberta. She helps organizations design the narrative architecture that makes ERP transformations coherent — through The Clarity Framework™.
Leading an ERP transformation that needs a clearer story? Work with Ana →
Related reading: Why ERP Projects Fail — And How Communication Determines the Outcome → How to Communicate During a Major System Transition → From Noise to Narrative: How to Build an Effective Change Communications Strategy →