Bruno Billy, President & CEO of APGAR North America, advises organizations on the operational reality of data and enterprise transformation.
Enterprise resource planning (ERP) transformations remain high on the agenda for many large organizations. Mergers and acquisitions, consolidation and modernization are driving significant investment. For SAP customers, the approaching end of mainstream ERP Central Component (ECC) support adds further urgency.
But replacing an ERP is much more than replacing technology. It affects nearly everything about how a company does business, from processing customer orders to managing its supply chain and reporting financial results. The scope makes it notoriously difficult and expensive to execute.
The expense creates enormous pressure to get moving. Teams responsible for different workstreams often start before the organization agrees on how the new ERP should represent the business. Often, those differences start with the most basic assumptions about how the business operates.
Here’s a simple question that comes up surprisingly often during ERP transformations: what is a customer?
The obvious answer is the person or organization purchasing your products or services. Simple enough, right? But consider a manufacturer that sells through distributors. For finance, the customer might be the distributor that places the order and pays the invoice. For service, it might be the business actually using the product. Neither is wrong. Both definitions serve legitimate business needs.
An ERP needs to accommodate these nuances through its business objects, relationships and hierarchies. If implementation teams decide how to represent customers independently, they risk embedding conflicting assumptions in data mappings, system configurations and business processes.
Those conflicts may not become apparent until integration testing or financial reconciliation. By then, resolving them can require substantial rework, increase project costs, delay go-live and potentially disrupt business operations.
Three Data Foundation Decisions To Make Before Your ERP Migration Gets Too Far
You won’t resolve every business requirement before an ERP migration begins, but there are three decisions I’d recommend making before the teams get too far into configuration and data migration.
1. Define your future-state business model.
Start by agreeing on how the business will be represented in the new ERP. For each major data domain, define the business entities, their relationships and the hierarchies needed to support operations and reporting.
This is particularly important when consolidating systems following an acquisition. In one organization I worked with, acquisitions had left the business operating six different ERP environments, each with its own representations of customers, suppliers and products. Supplier records in separate systems, for instance, may refer to subsidiaries of the same parent company. The future-state model should preserve those relationships so procurement can understand total spending across the supplier organization and negotiate accordingly.
Before approving the model, test it against actual legacy records. Can the migration team determine what each record becomes, which hierarchy it belongs to and how it relates to other entities? If the answers differ depending on who you ask, more business-design work is needed.
2. Decide what should be global and what should remain local.
Not every difference needs to disappear. Some reflect legitimate regional or business-unit requirements. Not every local variation is inefficiency. Some may actually reflect a competitive advantage.
A manufacturer may sell the same product in several countries while using different packaging or meeting different regulatory requirements in each market. I find it useful to distinguish between what should be written in ink and what can be written in pencil.
• Write in ink the definitions, identities and relationships that need to remain consistent across the enterprise.
• Write in pencil the attributes and classifications that must accommodate local requirements.
Make these decisions with future rollouts in mind. The first implementation often establishes conventions that subsequent regions are expected to follow. A model designed exclusively around the first region’s needs can become an expensive constraint on everyone else.
3. Establish authoritative sources and business ownership.
Decide which systems are responsible for maintaining master data and, equally important, who has the authority to make decisions about it.
A customer record might originate in the CRM, while finance maintains credit information and payment terms. Authority may therefore need to be defined at the attribute or business-process level rather than assigned fully to one system. For each major data domain, identify who can create records, approve changes, resolve conflicts and authorize exceptions.
Consider a customer changing its legal name. Who determines whether that requires updating an existing record or creating a new legal entity? If CRM and finance reach different conclusions, the ERP can end up with conflicting information even when both systems are functioning correctly.
Establish these governance processes before go-live and sustain them afterward. Customers merge, suppliers reorganize and businesses expand. Without ownership and change management, the fragmentation you worked to eliminate will quickly return.
Making These Decisions Before They’re Expensive To Change
It is understandable to worry that business-model discussions will slow an already demanding program, but these decisions must be made eventually. The longer they are deferred, the more configuration, mappings and processes are built on assumptions that may need to be revisited.
Making the decisions early reduces rework and gives implementation teams a common foundation. It also creates value beyond the migration itself. The same business definitions and hierarchies can support reporting, analytics, future acquisitions and even AI applications.
An ERP doesn’t merely store your business’s data. It encodes a model of your business. If you haven’t agreed on that model before implementation starts, the implementation will make those decisions for you.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?