How ERP Phase 0 Prevents Scope Creep, Governance Drift & Data Chaos

What Is ERP Phase 0 and Why Does It Matter?

ERP Phase 0 is everything that happens between the decision to do something about your current systems and the point at which you are ready to mobilise a project. It is not just about selecting the right ERP Software.

It includes the upfront work of defining why you need to change, how you want your business to operate in the future, and what outcomes you expect, as well as the work that follows selection: governance planning, scope definition, and programme readiness.

In this episode of the Comparesoft ERP Podcast, Bryan Oak, a consultant with decades of experience advising leadership teams across manufacturing, supply chain, and complex operational environments, including six years at IBM, explains why ERP Phase 0 is the stage most likely to determine whether a programme succeeds or fails.

He breaks down what Phase 0 looks like in practice, why it gets overlooked, and what happens when organisations skip it entirely.

Why Organisations Skip ERP Phase 0 and Go Straight to Selection

Bryan explains that most organisations do not consciously resist ERP Phase 0. Instead, they unconsciously bypass it. The typical first request he receives is not for Phase 0 support but for help selecting a new ERP system. Organisations have often spent a long time living with the pain of outdated systems. Once senior leadership agrees that something needs to change, the instinct is to move quickly into ERP implementation and product selection.

That urgency is understandable, but it creates risk. Without a clear shared purpose, agreed objectives, and a defined operating model, organisations lack the foundation to make good decisions about scope, requirements, and vendor fit. Bryan stresses that ERP Phase 0 does not need to take months. For a smaller organisation, it can take just a few days. For larger businesses, it may take longer, but the goal is always the same: establish a clear jumping-off point before any product conversation begins.

What ERP Phase 0 Looks Like in Practice

Bryan describes ERP Phase 0 as a structured sequence of activities. The first step is understanding the “why”: what is triggering the need for change, what is not working today, what the current setup is preventing the business from achieving, and where the organisation wants to be in three to five years.

From there, Phase 0 moves into defining how the business wants to operate. That includes the operating model, the way the organisation works internally and with external stakeholders such as customers, suppliers, and distributors. Bryan emphasises that most organisations do not invest enough time in thinking through this picture before moving into requirements.

Once there is agreement on purpose and operating model, the next step is to examine business capabilities and processes to determine what falls within scope. Bryan recommends treating capabilities as building blocks, understanding the data each process needs, the decisions it must support, and the obligations it must fulfil. This approach avoids getting drawn into detailed process mapping too early and keeps the focus on what matters: outcomes, decisions, and data.

Why Data Alignment Matters in ERP Phase 0

Data is consistently cited as one of the biggest challenges in any ERP software programme, and Bryan agrees it cannot be started too early. However, he cautions against focusing on data to the exclusion of everything else during Phase 0.

The priority in Phase 0 is understanding what data you have, where it sits, and what state it is in. It is also about identifying the data that drives decisions and meets obligations. Bryan gives the example of a manufacturer whose commitment to customers is a capable-to-promise delivery date. If the data fields that drive the behaviour of the ERP system are not understood and maintained correctly, those commitments will continue to be missed, regardless of which platform is in place.

Cleaning data in Phase 0 is not always the right move. Bryan explains that what you need to do to clean data for your current systems may differ from what you need for a future state. It is better to understand the landscape first and wait until the destination is clear before investing in major data remediation.

Scoping Challenges in Manufacturing and Supply Chain ERP Phase 0

Bryan has deep experience in manufacturing and supply chain environments, but he notes that the core ERP Phase 0 decisions are largely the same regardless of industry. The consequences of poor scoping are just as significant for a small not-for-profit as they are for a large utility company or a distribution business.

That said, scoping in manufacturing environments presents specific challenges. Organisations tend to think about the four walls of their factory or office when defining scope. In practice, processes extend well beyond those boundaries, into relationships with trading entities, customers, suppliers, and logistics partners. Drawing an artificial boundary around the organisation risks missing critical dependencies.

Another common scoping issue is the boundary between ERP and execution. In a manufacturing context, there is an important distinction between planning and purchasing materials, which is core ERP territory, and shop floor execution and control, which is better handled by manufacturing execution systems or even manual methods like Kanban boards and whiteboards. Bryan warns that forcing too much execution management into the ERP turns it away from its purpose as a planning tool, which is what the “P” in ERP stands for.

What Happens When ERP Phase 0 Is Skipped: A Real-World Case

Bryan shares the experience of an international manufacturer with multiple facilities and complex processes that skipped ERP Phase 0 entirely and went straight into system selection. The consequences were significant.

First, without a shared vision and agreed purpose across the group, the programme suffered from inertia. Every time a more strategically important issue arose, the ERP programme lost senior attention and momentum stalled.

Second, the selection was driven primarily by finance and accounting requirements, with manufacturing and operations treated as a secondary consideration. This created operational resistance, particularly from larger manufacturing sites with a degree of autonomy. The programme team responded by targeting smaller, easier-to-manage businesses first, rather than addressing the more complex sites where the value was greatest.

Third, without standards and guardrails, every business unit that was implemented received a different configuration. Customisations and tweaks accumulated with no consistency. The programme also suffered a strategic disconnect: the first plant selected for implementation was later earmarked for sale by the senior executive team, derailing the work already underway.

Bryan is now leading ERP Phase 0 with the same organisation. The entire senior leadership team has changed since the original programme, and the new board recognises the need to define the operating model, purpose, and outcomes before moving forward. Despite three months of engagement, Bryan describes the programme as being at the very beginning of Phase 0, with a board meeting ahead to formally approve the next stage of work.

How to Time-Box ERP Phase 0 Without Losing Rigour

A common concern with ERP Phase 0 is that it will take too long and lose momentum. Bryan addresses this directly: “Phase 0 should be time-boxed to something reasonable that matches the speed at which the business needs to work and the budget available. A typical target might be three months, with a built-in check at the end to assess whether the organisation is comfortable with its assumptions or needs to go deeper on specific areas”.

The key output of ERP Phase 0 is a business case that the board is prepared to sign up to, along with clarity on how the programme will be run, who will be involved, and what the budgets look like. Bryan describes this as the stage gate. Working backwards from that output helps define what “good enough” looks like at each step.

He also warns against two common traps: spending too long on high-level operating model work and trying to be too specific and detailed on requirements too early. There is a sweet spot in Phase 0 that balances enough shared understanding with enough momentum to move forward.

How Bryan Defines ERP Programme Failure

Bryan takes a broad view of what constitutes ERP failure. At its most serious, failure is about not delivering outcomes and benefits realisation, something that may not become apparent until months or years after go-live. That depends on the system doing what it was designed to do and the business using it in the way it was designed to be used.

The more visible failures, the ones that make headlines, involve disruption to the business at go-live: lost shipments, supply chain continuity issues, revenue impact, and adjustments in annual reports attributed to ERP problems. Then there are the more common tests of timeline and budget, which Bryan acknowledges are reasonable but need to include contingency and flexibility.

Bryan is sceptical of the widely cited 70 to 90 per cent failure rates. He points out that much of this is folklore with no quantified measurement behind it, and that if failure rates were genuinely that high, organisations would stop undertaking ERP programmes altogether. His view is that if a programme lands within a reasonable time window, within a budget envelope that includes contingency, and delivers a product that does not seriously disrupt the business, that is at least a partial measure of success. The deeper question is whether the system gets adopted, used properly, and delivers the outcomes originally intended.

What Separates a Good ERP System from an Outstanding One

When advising on ERP software selection, Bryan is pragmatic. He notes that most ERP products are broadly similar under the covers and that the distinction between a generalist ERP and an industry-specific tool matters most when there is a fundamental mismatch with the business model, such as choosing a process manufacturing ERP for an engineer-to-order environment.

Beyond functional fit, Bryan places significant weight on the implementation partner. He has seen situations where multiple partners pitch the same product for the same client, and the way each partner interprets requirements, plans the programme, and proposes to use the product can be very different. The quality of the partnership, the ability to have mature, transparent conversations about shared interests, and the cultural fit between client and partner are often more important than marginal differences in product features.

Bryan also cautions against over-emphasising requirements and features during selection. He draws a comparison with Excel: most people use a fraction of what it can do, and the same is often true of ERP systems. If two products are roughly at parity on features, the strength of the people, the partnership, and the working relationship should carry the decision.

The One Thing to Get Right in ERP Phase 0

Asked what an organisation should do if it only has the time or appetite to do one thing in ERP Phase 0 properly, Bryan is clear: set out a very clear purpose, vision, objectives, and guardrails.

He references a workshop he facilitated with 30 to 40 experienced consultants, where the overwhelming consensus was that a lack of shared vision, common objectives, and consistent senior leadership commitment was the root cause of programme failure. Purpose and objectives do not need to take weeks or months to define. They can be established quickly and then shared widely. But they must be genuinely shared, and senior leadership must be prepared to enforce them.

Bryan adds an important point: shared buy-in does not mean democracy. Once the organisation has decided to proceed, individuals who are not prepared to get on board may need to be moved aside. Swift, firm action on resistance is essential, both during Phase 0 and throughout the programme.

What CIOs Should Consider During ERP Phase 0

Bryan identifies several areas where CIOs need to provide leadership during ERP Phase 0 that their business counterparts may not fully appreciate.

1. The distinction between application scope and project scope. Application scope defines the boundaries and capabilities of the ERP system itself. Project scope is broader: it includes integrations, interfaces, process changes, organisational changes, and system changes. CIOs need to ensure the project scope accounts for everything the programme needs to deliver, not just the ERP platform.
2. CIOs should surface the topics of data, integration, automation, and increasingly, AI toolsets that can be brought to bear both during the implementation process and in the ongoing use of the solution.
3. The post-go-live support model. Who will own the system after implementation? What does the support structure look like? How will maintenance, updates, and continuous improvement be managed? These questions need to be considered during Phase 0, not after the programme has been delivered.
4. Which ERP Software to select should ultimately be made by the business, not by IT. The CIO’s role is to call out where the business does not fully understand the implications of its choices, but the accountability for selecting the right tool for the right outcomes sits with business leadership. Similarly, business programme managers should manage the overall implementation, while technical IT project managers handle the technology-specific aspects of delivery.