I have led or overseen multiple large-scale SAP transformations across global pharmaceutical operations spanning commercial, finance, supply chain, and shared services. Each one taught me something new. Each one also confirmed the same five patterns of success and failure that I had seen in the ones before it. The striking thing about ERP transformation is how consistent the pathology is. The reasons projects succeed are varied. The reasons they fail are almost always the same.
"In every SAP transformation I've seen fail, the technology worked. What didn't work was everything around it — the governance, the change management, the business ownership, the data."
1. Business Ownership, Not Just Sponsorship
Every SAP transformation has an executive sponsor. That's table stakes. What separates successful transformations from failed ones is whether the business owns the program or merely sponsors it. There is a profound difference.
Sponsorship means showing up at steering committees, approving budgets, and lending credibility to the initiative. Ownership means the business leader is accountable for the outcomes: process improvements, data quality, adoption rates, and ROI. It means their team is actively engaged in design decisions, not just reviewing deliverables at major milestones. It means they are willing to make the hard calls: standardizing processes that have been customized for years, retiring legacy systems that people are comfortable with, accepting short-term disruption for long-term gain.
Programs where IT owns the transformation and the business participates almost invariably struggle with adoption and value realization. Programs where the business owns the transformation and IT enables it have a fundamentally different energy, and a fundamentally different outcome.
2. Data Before Technology
The phrase "garbage in, garbage out" is older than SAP itself, and it is still the most reliable predictor of ERP transformation failure. Organizations that underinvest in data quality remediation relative to their investment in system configuration and development consistently find themselves with a technically functional system that the business can't trust.
In the pharmaceutical commercial context, this is particularly acute. Pricing data, customer master data, contract terms, and product hierarchies that have accumulated inconsistencies over years of acquisitions and organic growth cannot be cleaned in parallel with an SAP go-live. They need to be addressed ahead of time, with dedicated resources, clear ownership, and executive attention that makes data quality feel as important as system readiness, because it is.
If your data remediation budget is less than 15-20% of your total program budget, it is almost certainly underfunded. The most common failure mode in ERP transformations is launching a technically complete system onto a foundation of inconsistent data, then spending years cleaning it up post go-live.
3. Process Standardization as a Strategic Decision
SAP's core value proposition is standardization. The system embeds decades of industry best practices into configurable business processes. But pharmaceutical organizations, particularly those that have grown through acquisition, often have highly customized legacy processes that people are deeply attached to.
The decision about how much to customize SAP versus how much to standardize business processes to fit SAP is not a technology decision. It is a strategic decision about competitive differentiation. The question to ask is: does this process variation create competitive advantage, or is it just the way we've always done it? For most processes such as financial close, purchase-to-pay, and order-to-cash, the honest answer is that the variation doesn't create advantage. It creates cost and complexity.
The programs that succeed are the ones where business leaders make the strategic decision to standardize, and make it early, before configuration begins and before people have invested in defending their current processes. Once configuration is underway, every customization request has momentum behind it that is very hard to stop.
4. Change Management Is Not a Workstream. It Is the Program.
In my experience, SAP transformations budget approximately 10-15% of program spend on change management and training. This consistently underestimates what is actually required. An ERP transformation is not primarily a technology project. It is a business transformation project that happens to involve technology. The systems change in a matter of months. The behaviors and processes they support take years to stabilize.
The change management investment needs to begin at program initiation, not at go-live preparation. Business users need to understand why the transformation is happening, what it means for their roles, and what their obligations are during transition. Super-user networks need to be built and supported throughout the program, not just trained at the end. And post-go-live hypercare, the intensive support period that catches issues before they become embedded problems, needs to be adequately staffed and genuinely responsive.
5. Realistic Scope and Timeline
The final factor is the one that is most often compromised in the face of budget pressure and executive impatience: realism about scope and timeline. SAP transformations are complex programs that take time. The organizations that try to compress timelines beyond what the complexity allows, by running too many workstreams in parallel, skipping testing cycles, or going live before the business is ready, routinely pay for that compression in post-go-live disruption that costs more than the time they saved.
I have seen programs that were technically on schedule at go-live consume two or three times their planned budget in post-go-live remediation. The schedule pressure that drove the aggressive timeline ultimately cost far more than a more realistic approach would have. This is a lesson that seems obvious in retrospect and is somehow reliably forgotten when the program begins.
None of these five factors are surprising. They are widely known. What makes them consistently relevant is that they are consistently underweighted in the face of the pressures that every large transformation program faces. The organizations that succeed are the ones with the discipline to hold the line on these fundamentals, even when the program dynamics push in the other direction.