Technology Isn't the Solution: What 20 Years of EPM Implementations Have Taught Me
Key Takeaway
After twenty years of doing this, here's the one thing I keep coming back to. Technology is not the solution. It enables the solution. If I had to pick just two things that decide whether an implementation actually works, it would be clarity and change management. Almost never the tool itself.
Let's start simple. Break the words apart: enterprise, performance, management. An enterprise isn't one single thing. It's a bunch of different functions all doing their own part, sales, procurement, production, finance, HR. Leadership sets goals for the business, maybe it's growth, maybe it's margin, maybe it's a new product or a new geography, and those goals cascade all the way down until they become KPIs that individual teams get measured on.
Sounds rational enough on paper. In practice, this is exactly where things get interesting.
Here's something I genuinely believe. Success in an enterprise doesn't only come through collaboration. A lot of it comes through conflict, and that conflict is healthy. It's not a sign that something's broken.
Take a simple example. A business wants great customer service: the right product, right price, on time, right quality. If you only optimise for that, sales will want unlimited stock everywhere so nobody's ever refused. But you can't keep unlimited stock at every location. Working capital just won't allow it. So finance gets told to protect margins, maybe by procuring cheaper, cutting overheads, being tighter on discounts. And sales feels every bit of that as friction, because heavy discounting moves volume but eats the contribution margin finance is trying to protect.
The goal of the enterprise is one thing. The moment it turns into departmental KPIs, it splits into competing priorities. That's not dysfunction, that's just how it works. The job is managing it well, not making it disappear.
I saw this really clearly with a custom bottling and packaging company I worked with once. Their whole philosophy was simple: never refuse a customer, whatever the order is. I'm not going to challenge that, they know their business better than I do. But when I sat with their supply chain team, they were in real pain. Demand kept changing randomly, all the time. And a manufacturing line just doesn't work that way. It has a heartbeat. Run it for a set time and you get a predictable output. Interrupt it mid-batch for a new order and there's a changeover cost, cleaning up, reloading, reconfiguring. Do that constantly and you get what we call nervousness in the system. Constant firefighting, inventory piling up that nobody's clearing, frequent changeovers, material shortages.
What we asked them was pretty simple. Have you actually calculated what it costs to fulfil every single demand unconditionally? What's the inventory you're carrying just to keep that promise? Because there's no genie's lamp here. Somebody told me this very early in my career and it's stuck with me ever since. If this world had Aladdin's lamp, you wouldn't need a supply chain at all. You'd just wish for something and it would show up. It doesn't work that way. Everything you want has to go through a process, and that process takes time and has a cost attached to it. Once a business accepts that, planning stops feeling like bureaucracy and starts being the thing that makes the promise to the customer actually sustainable.
The technology behind EPM didn't evolve in a straight line. It converged from a bunch of different directions at once. ERP grew out of manufacturing resource planning, MRP, which was originally just about materials. Then it expanded to cover staff, capacity, other resources too, and we started calling that MRP II. From there, planning widened further to bring in sales and operations, then finance, and that became integrated business planning, eventually pulling in HR, legal, pretty much everything into what people call connected planning. Separately, finance had its own layer sitting on top the whole time: corporate performance management, budgeting, actuals, variance analysis.
Picture a whiteboard with a circle in the middle labelled EPM, and different tools sitting in the corners. Some built for finance, some for procurement, some for HR, some for sales, each one thinking it owned a piece of "enterprise performance." Eventually the platform providers, the SAPs, the Oracles, the Anaplans and Boards of the world, realised none of them could own it alone. No function succeeds in isolation. Sales can't hit its numbers without supply. Supply can't plan without a demand signal. So the tools converged toward the middle.
I've personally lived through about three cycles of this. Standalone physical machines you'd load a plan into, almost like a miniature mainframe. Then the web. Then the cloud. Now AI sitting on top of all of it. But the one thing that hasn't changed is the core idea underneath: a multidimensional database, because business itself is multidimensional. You're never just looking at "sales." You're looking at sales by product, by region, by channel, and you can slice it up and down a hierarchy, from one product variant all the way up to the whole company. And sitting above that is the analytical layer: descriptive, what happened, diagnostic, why it happened, predictive, what might happen next, and prescriptive, what you should actually do about it.
Which brings me to the question I get asked most: why do EPM implementations succeed, and why do they fail?
The honest answer is that technology isn't the solution. It enables the solution. If I had to pick two things that matter most, it's clarity and change management.
Clarity means knowing exactly what you're solving for. Sometimes it's very specific: "it takes us twelve days to close our books, we need automation." Sometimes it's more symptomatic: "my gross margin analysis keeps going wrong and I don't really know why," and that needs actual diagnosis, breaking the problem down before you even think about technology. Either way, every single layer of the organisation needs to know why they've signed up for this. Without that, change management is a disaster before it even begins.
Change management is the harder half, honestly. Every enterprise is a running engine. It doesn't get to pause for six months while you build something new and then restart. It has to run and repair, run and transform, at the same time. That's extra workload, and it almost always falls on the people already running the business, not some outside team that's been brought in to help.
In my experience, failure shows up in three different forms, and it's worth telling them apart because the fix for each one is different.
Technical Failure: The Inputs Were Never Right
This is when the drivers weren't properly identified, data capture was incomplete, or business process mapping got skipped entirely. You've got the ambition but not the data coverage. Sometimes you find out the organisation wasn't even capturing the data it thought it was. And there's a particularly dangerous version of this too: a CFO or business leader who doesn't actually know the reality on the ground because their team has been quietly synthesising a "clean" number for years. You only find out things were broken in the spreadsheet once you finally put a real tool in front of it.
Technological Failure: The Expectation Gap
This happens when people expect one platform to behave like Excel, scale like Hadoop, and report like Tableau, all at the same time. There's no ceiling to expectation once it starts running away from you, and managing that has to happen during the sales cycle, not after go-live. Modern EPM tools are genuinely powerful. I think of them like a set of Lego blocks. You can build almost anything with them, and that's the strength. But if you don't know what you're actually trying to build, you end up with something that has no shape, no balance, no meaning, and then it's really hard to defend when someone asks, "what exactly is this?"
Change Management Failure: The Human Pattern That Repeats Everywhere
Business units that have spent years building their own Excel models are comfortable with them, genuinely fond of them even. You can sleepwalk through a spreadsheet you built yourself. You own every macro, every shortcut, you feel completely in control. Then a new tool shows up promising better governance, better traceability, better connection across teams, but nobody feels that value on day one. They only feel the friction of learning something new. Add a fragmented, outsourced IT setup where different vendors control different pieces and none of them report to you, and now you've got a real behavioural problem, not a technology one. I've seen this pattern repeat across enough industries and companies to say it confidently: it's not organisation specific. Human behaviour doesn't change that much from one enterprise to the next.
At a Glance
| Failure Type | What It Looks Like | Root Cause | The Fix |
|---|---|---|---|
| Technical | Numbers look "off" once a real tool replaces the spreadsheet | Drivers never identified, incomplete data capture, no process mapping | Business process mapping and data capture done before platform work starts |
| Technological | "The tool can't do X," frustration that it isn't behaving like every other tool at once | Unbounded expectations, wanting Excel's ease, Hadoop's scale, and Tableau's reporting all together | Manage perception during the sales cycle, define scope before go-live, not after |
| Change Mgmt | Quiet resistance, people keeping the old spreadsheet "just in case," slow adoption | Comfort with the old way, fragmented IT ownership, no felt value on day one | Phased rollout, early wins, visible sponsorship, let success build trust before scaling |
The leaders I respect most in this space aren't the ones with the most aggressive vision. Some of the CFOs I've worked with have had a clearer picture of what they wanted than I did, and I say that genuinely, no shame in it. The mistake I see, even from strong leaders, is trying to boil the ocean. Demanding too much too fast from an organisation whose data isn't ready, or whose people aren't ready. Push too hard and every stakeholder who preferred the old way takes every chance to paint the whole initiative as a failure, because to them, the smoother, happier experience is the one they already know.
Clarity matters, but a roadmap matters just as much. Do it in phases. Get a real result first. Let that success build trust before you ask for the next phase.
That's the pattern I keep seeing hold up, in manufacturing companies, in companies built through mergers and acquisitions with completely different cultures and systems glued together, everywhere in between. The technology itself has gotten genuinely good. Better integration, better native connection to the Excel workflows people already trust, more auditability than any spreadsheet could ever give you. But none of that changes the one thing I keep coming back to. You cannot be the tool alone. The organisation still has to know what it's solving for, and it still has to manage the human side of getting there.
Thinking through where your organisation actually stands on clarity and change readiness before your next planning transformation?
Talk to a Keansa Consultant
.png){kind=small}
.png){kind=small}
.png){kind=small}