Some ERP implementations stay with you because of everything that went wrong. I remember one for exactly the opposite reason.

Several years ago, I participated in a global Oracle ERP transformation of a manufacturing company headquartered in New York. By the time the roadmap reached Chile, the implementation methodology was well established, the global template had already been proven, and the project team had accumulated valuable experience from previous deployments. Still, every rollout had brought its own challenges, so no one expected Chile to be any different. It was. To this day, it remains one of the smoothest Oracle ERP implementations I have ever experienced.

The local General Manager was fully committed to the transformation but, like many country leaders, he was already balancing more responsibilities than one person could reasonably manage. Rather than attempting to participate in every workshop and every design discussion, he entrusted most of the day-to-day project leadership to the Finance Manager.

She had never participated in an Oracle implementation before and had no Oracle background. Yet she seemed to instinctively understand how the business side of a transformation project needed to be structured. She organized her people, clarified responsibilities, and made decisions with remarkable confidence.

Long before the first configuration workshop, she had already begun preparing the organization for the project. She understood that the Finance and Supply Chain teams would somehow need to continue running the business while simultaneously participating in the implementation, so she worked to ensure that operational responsibilities would not prevent key people from contributing to the project when they were needed.

At the same time, she approached local regulatory requirements with remarkable discipline. Rather than waiting for workshops to uncover country-specific needs, she documented Chile’s statutory reporting obligations, tax rules and accounting requirements before they had the opportunity to become design issues. She understood that those conversations were not administrative details to resolve later. They were essential inputs for building the right solution from the beginning.

She applied exactly the same thinking to electronic invoicing. Chile had been one of the earliest countries in Latin America to establish mandatory electronic invoicing, and she made certain that every dependency, every integration and every business scenario had been understood before development progressed. The result was an implementation of the electronic invoicing solution that reached go-live without the disruptions that so often accompany these integrations.

When User Acceptance Testing finally arrived, she approached it with the same level of preparation. Every relevant business scenario was reviewed carefully. Every important transaction was validated. She seemed unwilling to assume that something would simply work because it had worked somewhere else.

It took me some time to realize just how much she had anticipated. Looking back, she had systematically addressed most of the execution risks that tend to disrupt global Oracle programs. She protected the organization’s execution capacity before the project competed with day-to-day operations. She clarified local regulatory requirements before configuration made change expensive. She coordinated external dependencies before they became critical path activities. She ensured that business validation was thorough enough to prevent unpleasant surprises after go-live.

None of these actions were particularly visible during the implementation. Most of the work happened quietly, inside the client organization, before problems had a chance to surface. That was precisely why the rollout felt so smooth.

That experience shaped much of how I look at ERP transformations today. A strong implementation partner matters, but so does the strength of the client’s own team. Someone needs to anticipate issues, coordinate the business, drive decisions, and make sure the small but critical things actually happen. When that work is done well, it is almost invisible.

It is also why I have become so focused on strengthening client teams and working as part of them. I have come to believe that successful projects are not the ones where nothing goes wrong, but the ones where important problems are addressed early enough that they never become visible.

This is the other side of ERP readiness: the organization’s own ability to participate in the transformation.

Can the business make decisions quickly enough? Are the right people available? Have local requirements been understood? Are external providers ready when they are needed? Will business experts have enough time to properly validate the solution? An implementation partner can help with all of this, but cannot do it on the client’s behalf.

Looking back at that rollout in Chile, I no longer think of it as the project where everything went right. I think of it as the project where the organization quietly did the work that prevented so many things from going wrong.

That Finance Manager eventually became a friend. An ocean separates us today, but we have stayed in each other’s lives. And whenever I think about that project, I still think about how naturally she understood something that took me years of other implementations to fully appreciate.

Perhaps that is the lesson I wish more transformation leaders considered before starting a global Oracle transformation. The smoothest rollouts are not necessarily the ones with fewer challenges. They are the ones where the organization understands from the beginning that successful delivery depends not only on selecting the right implementation partner, but also on preparing itself to become one.