ERP - Is it The Pizza or The Oven?

The Distance From The Pizza — Part Three

There is something fascinating about an ERP implementation. Millions of dollars can be spent selecting the system, configuring it, integrating it, testing it, migrating data, training people and preparing for the moment when someone finally announces that the organization is “live.”

Teams work for months, sometimes years, toward that moment. There are steering committees, status reports, risk registers, testing cycles, project plans and increasingly complicated spreadsheets tracking whether everything is on schedule. And when the system finally goes live, there is usually a genuine sense of accomplishment. There should be. Getting an ERP system implemented is a significant undertaking.

But somewhere between the project plan and the celebration, I think we sometimes lose sight of a rather simple question: did we actually make better pizza?

Because the ERP isn't the pizza. It's the oven.

Think about what happens in a pizza shop when the owner decides to replace an old oven. The decision isn't really about the oven. The owner isn't standing there thinking about stainless steel, temperature controls or the latest technology. The decision is being made because the owner wants something better on the other side of the oven. Perhaps the old one can't keep up with demand. Perhaps it cooks inconsistently. Perhaps it is becoming expensive to maintain. Perhaps a new oven will allow the business to handle more customers or produce a better product.

The oven matters enormously, but nobody walks into the restaurant because they are excited about the oven. They walk in because they want the pizza.

That distinction seems obvious when we're standing in a pizza shop. It becomes considerably less obvious when we're standing inside a large technology transformation.

An ERP system can connect information, standardize processes, eliminate duplication, automate transactions and give management an extraordinary amount of visibility into what is happening across an organization. Those are powerful capabilities, and they can fundamentally improve the way a business operates. But the system itself doesn't create trust between a manager and an employee. It doesn't explain to someone why their job is changing. It doesn't help a frontline employee understand what success looks like in the new environment. And it doesn't automatically make a business better simply because the software is working the way it was designed to work.

The value has to show up somewhere beyond the system—in the work, in the customer experience, in the employee experience and ultimately in the performance of the organization.

That is where the pizza comes in.

Everyone involved in an ERP transformation is looking at a slightly different part of the same operation. The person making the pizza sees the work itself. The shift manager sees the kitchen. The project team sees the implementation. The executive sees milestones, risks and expected benefits. The board sees the investment and the business case. The vendor sees the system. All of them can be looking at the same transformation and reasonably conclude that things are progressing well.

And yet the customer can still be waiting forty-five minutes for dinner.

That is one of the interesting consequences of organizational distance. The farther we move away from the people actually experiencing the outcome, the more likely it becomes that we begin measuring the transformation through representations of reality rather than reality itself. We look at dashboards, project milestones, testing results, adoption percentages and training completion. All of those measures can tell us something useful. But they are still representations. They are telling us about the pizza rather than putting us in the kitchen with the person making it.

And that distinction becomes important when the organization starts making decisions based on what the system is telling it.

One system doesn't necessarily create one organization

This is one of the things I find particularly interesting about ERP transformations. We often talk about the objective as though it were to create one system. In reality, the business doesn't need one system nearly as much as it needs one organization that understands what it is trying to accomplish and can work effectively within the new environment.

Those aren't the same thing.

An organization can have beautifully integrated technology and badly integrated people. It can have standardized processes and inconsistent understanding. It can have perfect data and terrible decisions. It can have an ERP system operating exactly as designed while the people using it are struggling to figure out how to operate in the new world.

Sometimes the technology even becomes the explanation for decisions that leadership has actually made. “We have to standardize this because the ERP requires it.” “We can't do it that way anymore because the system won't allow it.” “That's just how the new system works.”

Sometimes those statements are absolutely true. But sometimes the organization has made a leadership decision and then allowed the technology to take the blame for it. That's worth watching, because technology is remarkably good at becoming the messenger for decisions that nobody wants to own.

If leadership has decided that a process needs to change, the ERP may be the mechanism through which that change happens. It shouldn't become the excuse for why the change happened.

Don't blame the ERP for a change you decided to make. The system may enable the decision, but leadership still owns it.

The distance between “installed” and “successful”

Then comes the part of an ERP transformation that is often described as adoption.

The system goes live. People have been trained. The project team declares success. And then reality arrives. People are slower than they used to be. They make mistakes. Managers spend more time helping their teams. Workarounds begin appearing. Customers notice. Productivity dips. Someone eventually says, “We're having an adoption problem.”

Maybe.

But sometimes the organization has underestimated the distance between having a new system and being good at working in a new system. Those are very different things.

Think about our pizza shop again. Imagine installing a brand-new oven at four o'clock on Friday afternoon. Not Monday morning. Not during a quiet week. Friday afternoon, with the dinner rush about to begin.

The cooks have spent years learning the quirks of the old oven. They know where it runs hot. They know how long certain pizzas really take. They know which settings aren't quite right. They have developed little workarounds that nobody ever documented because they didn't need to. They simply know how to make the kitchen work. Now the new oven arrives.

At the same time, you've replaced the ordering system. The cooks are learning a new process. The manager is trying to figure out what is happening. Orders begin backing up. Customers start complaining. The people who used to make the kitchen run almost instinctively are now stopping to figure out what the system wants them to do.

At seven o'clock, someone walks into the kitchen and asks, “Why aren't people adopting the new system?” It's an interesting question, but perhaps the better question is why we installed a new oven and replaced the ordering system at four o'clock on a Friday afternoon.

We wouldn't normally do that in a pizza shop. We'd schedule the installation when the business could absorb it. We'd train the cooks. We'd test the oven. We'd probably run the old and new processes in parallel for a while. We'd have someone available to deal with problems. Most importantly, we'd make sure the people who actually have to produce the pizza were ready before we put the first customer order through the door.

None of that is particularly revolutionary. In fact, it's pretty obvious. And that's what makes it interesting. Organizations know these things. They put training in the project plan. They talk about communications. They identify key users. They establish support processes. They conduct testing. They have change management teams.

And then the project gets compressed.

The board wants the date moved forward. Another transformation gets launched. The business gets unexpectedly busy. A critical integration falls behind. A senior manager leaves. Training gets squeezed. The organization is asked to absorb one more change because, on paper, it looks like one more change. Eventually, the problem isn't necessarily that people are unwilling to change. The organization may simply have exceeded its ability to absorb change effectively.

That's organizational friction. And organizational friction doesn't care how good the original business case was.

What happens when your best cooks leave?

Let's go back to Friday night. The new oven isn't working quite as expected. Orders are backing up. Customers are getting frustrated. The manager is overwhelmed. And your two best cooks—the people who know exactly what to do when something goes wrong—have had enough. They leave.

Perhaps they don't make a dramatic announcement. Perhaps they simply decide that they don't want to spend the next six months working this way and accept an offer from the pizza shop across the street. You may eventually replace them. You may eventually get the new oven working. You may eventually get productivity back to where it was. The spreadsheet may eventually show that headcount has returned to normal.

But something important has happened that the spreadsheet may never capture.

Those cooks knew the customers. They knew the equipment. They knew the kitchen. They knew the shortcuts. They knew how to recover when the Friday-night rush went sideways. They knew which problems were actually serious and which ones could be fixed in thirty seconds. They carried knowledge that had never been written down because nobody had ever needed to write it down.

And now your competitor knows some of it.

This is why I think we need to be careful about how we talk about recovery after transformation. We may eventually recover the headcount. We may recover the productivity. We may recover the customer volume. But we may never recover the institutional knowledge, relationships, opportunities and momentum that were lost along the way.

A customer who leaves during a difficult transition may not come back. An experienced employee who walks out the door may take ten years of institutional knowledge with them. A manager who spends six months fighting fires isn't spending that time building the next opportunity. A sales team distracted by internal problems may miss a market opportunity that never comes around again. Those costs don't necessarily appear on the transformation budget. They appear somewhere else, sometimes much later.

Eventually recovered does not necessarily mean economically recovered. That's an important distinction when we think about the value of transformation.

Look in the box

There is another lesson hidden in our pizza shop.

Before the delivery driver leaves, someone looks inside the box. Is this the right pizza? Is everything there? Is it cooked properly? Is it damaged? Does it actually match what the customer ordered? Nobody would consider that excessive bureaucracy. It's simply a final check before something leaves the building. Transformation needs something similar, although perhaps not another committee, another fifty-page readiness report or another traffic-light dashboard. It needs a habit of asking a much simpler question:

If we put this pizza in the box and hand it to the customer right now, what could go wrong?

The interesting thing about that question is that the answer changes. A key integration can fail. A critical manager can leave. Training can fall behind. Another transformation can suddenly be added. The business can get busier. Employees can start creating workarounds. Customer complaints can appear. The transformation hasn't necessarily become a failure. But the risk profile has changed.

So we look in the box again.

I think this is where transformation management can become much more useful than simply asking whether people have been communicated with or whether training has been completed. The real question isn't whether we've checked the required boxes. It's whether the organization is becoming capable of succeeding in the new environment.

The person closest to the pizza will often see the problem first. The farther away we are, the more likely it is that the problem will arrive as a number on a dashboard after someone has already spent time trying to fix it. And the farther a problem travels before someone notices it, the more expensive it generally becomes to fix.

Go-live isn't the outcome

This may be the biggest trap of all.

Organizations are very good at celebrating milestones, and go-live is certainly a milestone. But the customer doesn't care that the ERP went live. The employee doesn't care that the data migration was completed. The board ultimately doesn't care that the project team hit its implementation date. They care whether the organization became better.

That's why the distinction between the pizza and the oven matters. The oven has to work. It has to be reliable. It has to support the volume we're trying to produce. People need to know how to use it. But none of those things, by themselves, tell us whether the customer is getting a better pizza.

And yet we sometimes behave as though getting the oven installed is the transformation.

It isn't. It's the beginning of finding out whether the transformation actually worked.

So, are we managing the pizza—or managing the oven?

That may be the question worth asking throughout any technology transformation. Not instead of asking whether the system is working, but alongside it.

Is the technology doing what we intended? Are people able to work successfully within it? What are we learning from the people closest to the work? Where is friction appearing? What workarounds are emerging? What are customers experiencing? What are employees experiencing? And, perhaps most importantly, are we still close enough to the pizza to know? Because ERP can absolutely reduce organizational distance. It can connect information that used to sit in different places. It can give people visibility they never had before. It can eliminate unnecessary duplication and make an organization more connected and, in many cases, significantly better.

But technology can also create another layer between the people making decisions and the people experiencing the consequences. We can become so focused on whether the system is working that we forget to ask whether the organization is working.

The technology can connect the organization, but leadership still has to connect the people.

And that brings us back to the question at the heart of this series.

The farther away we get from the pizza, the easier it becomes to believe that everything is working because the system says it is. But the pizza may be telling us something completely different. So before we celebrate the new oven, perhaps we should do something remarkably simple.

Look in the box.

And ask whether we're actually managing the pizza—or whether we've become so focused on managing the oven that we've forgotten why we bought it in the first place.

Cambiara Group - October 12, 2026