6 Tips to Drive a Successful Multi-Company ERP Implementation

The complexities of a multi-company ERP implementation

A multi-company ERP implementation is a major undertaking. It will be one of the most costly, disruptive, and risky projects that you will ever undertake.

For mid-sized and enterprise-sized companies, this type of ERP project can cost millions of dollars and span multiple years.

To be successful, a project demands that your best and brightest departmental employees be assigned for at least 50% of their time. While on the project, they’ll be re-engineering your company’s business processes, migrating data, testing the system and training other users.

With so much at stake, it’s critical for your project to be delivered on time and within budget. And, being able to measure a project’s performance assumes that there’s a proper plan in place that establishes measurable baselines for scope, schedule, budget and performance.

Here are six ways to help you set your project up for success.

Tip #1: Ensure that your project scope includes a clearly defined corporate business structure.

Enterprise and mid-market companies are oftentimes made up of multiple legal and logistical entities with varying degrees of centralized (or decentralized) business functions. Some companies have multiple sites or facilities in the same country. Others have business operations in multiple countries. Some have a conglomerate of diverse businesses under a corporate umbrella. And others foster internal competition among business units.

Each type of business structure drives system requirements. For example, a vertically-integrated company might want to apply separate costing methods to different business units, but have common master data files (to facilitate intercompany buy-sell relationships). As another example, a centralized business might want the ability to plan requirements across various facilities.

Before starting an ERP implementation project, it’s important to define the relationships among business units and with the parent company. These will inform ERP software requirements relating to organizational structure, master data, intercompany transactions, security, and central processing and administration.

Here are five typical business structures as they pertain to an ERP implementation:

  1. Global business units have total autonomy. Under this model, the parent has little involvement in the processes, systems and structures of its business units. The implication is that each can operate a separate ERP system if it so chooses.
  2. Headquarters has minimal control over local processes. Under this structure, business units have autonomy in all areas except financial accounting and reporting. Each unit usually chooses, implements, and maintains its own ERP software, with financial consolidations managed at the corporate level.
  3. Headquarters coordinates transactions between business units. In this model, business units have a high degree of autonomy in how they operate. However, headquarters manages the global supply chain through its access to local information about purchasing requirements, inventories, and production schedules. As such, there are generally opportunities for efficiencies relating to standardization of certain master data structures and transactional processes.
  4. Business units coordinate with each other. Under this model, local operations have access to each other’s data, allowing for lateral coordination without a high degree of centralization or top-down control. This model is more typical of business units that have at least a minimal degree of product market overlap or vertical integration. In the areas that overlap, there could be benefit to common standards and coordination.
  5. Business unit operations are fully centralized. Headquarters has total control over local decisions, determines which ERP system to use, and standardizes almost all of the business processes. Centralized ERP implementations are the most complex and prone to failure. However, they provide the greatest opportunities for efficiencies and cost-benefit.

 

The above framework isn’t rigid. Rather, it’s intended to be a starting point for defining the business structure and associated intercompany relationships. Many of our clients straddle structures. The important take-away is that you should define the business models, business unit interrelationships, and implications on security, data, system needs, and business process management. Key areas for consideration include:

  1. Costing models
  2. Sales and purchase pricing models
  3. Operational master data models
  4. Finance, general ledger and reporting structures
  5. Intercompany transfers and transactions
  6. Central business processing
  7. IT, database and business systems administration

Tip #2: In the project scope, map high-level system capabilities to the business structure requirements.

Once the business structure requirements are established, it’s important to map how the system is going to satisfy those requirements.

Different systems handle multi-company structural requirements differently. Some were developed with strong capabilities. Others have supplemented functionality initially developed for simpler business structures.

For example, some Tier II ERP systems require master data files to be duplicated across legal companies and maintained through synchronization routines. Other systems allow a single logistical entity to cut across multiple legal entities.

Once your business structures are defined, it’s important to identify whether there are any system gaps and how any gaps will be worked-around.

In general, there are four common types of ERP configurations relative to business structures:

  1. Multiple financial/multiple operations. This type of ERP configuration is best-suited to a country-based organizational structure of a typical multinational business. Many international automobile manufacturers have adopted this approach to configuring ERP software for their multi-country operations.
  2. Multiple financial/single operation. An organization with a single manufacturing facility (or several that are managed as an entity) and sales offices in different countries might select this type of multisite ERP software configuration. It is well suited to handling the diverse accounting regulations, currencies, and languages of many international businesses. This set-up also provides for an ability to centrally manage functionally-integrated operations across multiple countries. Some systems are better-suited to this business structure than others. For example, some permit MRP and resource planning across financial entities. As another example, some permit warehouse transfers across country lines with automated intercompany accounting and without the complexities of buy-sell transactions.
  3. Single financial/multiple operations. Certain complex organizations choose a configuration in which there is a single legal/financial company with multiple operational entities (e.g. multiple manufacturing and/or sales and distribution units). This configuration allows organizations to accommodate different business processes, possibly as a result of different product types.
  4. Single financial/single operation. Simple, geographically centralized organizations normally select single site ERP configurations. More complex organizations with multiple plants and distribution centers might also choose single site software configurations if:
    1. They operate as a single management entity within a single country.
    2. They have common business processes in their plants and distribution centers.
    3. Their flows of material and finished goods are managed centrally from headquarters.

Tip #3: Define your project teams and resource budgets in a Resources Management Plan.

Your prospects for ERP implementation success depend on the strength of your team, which is comprised of both internal personnel and external consultants. In our experience, 70% of ERP implementation failures are caused by problems with the team, not problems with the technology.

During the planning phase, it’s critical that appropriate teams be established, along with the roles of responsibilities of each team member.

ERP project teams

Labor costs will be the biggest expense item on an implementation. Any task or need that triggers a non-trivial resource requirement should be planned and budgeted in a resources management plan, including internal personnel commitments, backfilling needs, cross-training plans and external consulting support.

With respect to project governance, a core ERP project team should be created with key users from each impacted area (e.g. AP, AR, finance, purchasing, sales, planning, etc.). These team members must be the top-performing employees in their departments, as they will be responsible for redesigning and reengineering your business processes.

Allow your core team to commit at least 50% of their time to the ERP implementation. You may need to backfill their positions, so they have the time to dedicate to the project.

One effective strategy is to formally dedicate one or more backup personnel to each core team member. Create a cross-training plan that delegates lower-value tasks from the core team member to the backup. In addition to freeing-up needed capacity, this process will provide you with a contingency plan in the event that a core team member leaves or is removed from the team.

To the extent that your organization needs to hire new employees (either temporary or full-time) to support the project, these positions should be budgeted as part of the resources management plan.

When building a core team, select members with the following skills:

  1. Knowledge of their department’s business processes.
  2. Cross-functional knowledge of how other departments operate.
  3. Strong communication skills, as they will need to give presentations and keep others informed on the status of the ERP project.

 

We use a skills-matrix to help our clients build their core teams. This matrix gives our clients a structured method to assess candidates, build custom training plans to fill critical skills gaps and plan supplemental external consulting support.

ERP skills gap

In addition to your internal, core ERP team, you will also need to bring in a team of consultants. The consultants will be responsible for installing the software and training your staff on how to use it. Your consultants should possess the following skills:

  1. Functional and technical knowledge about the ERP system.
  2. Domain knowledge about the business. For example, the distribution person should understand warehousing.
  3. Strong communication skills. The consultants will need to train core team users and interact with others in your company.

Before signing a services agreement with the consulting firm, make sure you first qualify the consultants who will be staffed on the project. Evaluate their skills (with systems and operations) and fit. Talk to their references. Ultimately, you’re going to need to trust that they’re making recommendations that are right for your business.

Tip # 4: For needs that span business units, create cross-company teams

If a standard, single-site ERP implementation requires cross-departmental collaboration, a multi-company ERP implementation might require cross-company collaboration.

The extent of cross-business unit involvement depends on the nature of shared processes and data. For example, business units that use common parts will want to ensure that the item master data is designed in a way that suits the needs of all.

Referring back to the business structure models in Tips #1 and #2 above, it’s important to build teams that account for the common needs of the various business units. So, in a multi-company ERP implementation project that’s staggered across business units (where Unit #1 implements first, followed by Units #2 and #3), personnel from Units #2 and #3 should participate in Unit #1 implementation project tasks that will impact their future business.

Tip #5: Follow a deliverables-based methodology.

A deliverables-based methodology offers you an ability to track project progress and minimize surprises. By breaking your project down into a set of tangible and measurable outputs, you’ll be in a position to know whether you’re on track to a successful outcome. And, if you stray from the success path, you’ll want to know at the earliest reasonable opportunity and give yourself an ability to course-correct with minimal impact.

The following extract from our ERP implementation book, Milestone Deliverables, 2nd edition, shows critical milestone deliverables relative to project phases.

ERP Project Plan 1 ERP Project Plan 2

One critical success factor is to align key project deliverables with major project milestones such as: planning, core team training, process walkthroughs, piloting, data migration, end-user training and cutover.

Another critical success factor is to ensure that the core team members own the deliverables. In other words, the team should be responsible for producing acceptable and timely outputs. For business process reengineering, for example, the team members should document their own “to be” processes, should present those processes in walkthrough presentations and should test those processes through structured piloting. In contrast, if the consultants design the processes, there is a major risk that team members reject the outputs.

Upon completion of a critical milestone, internal project management should update the steering committee as to the status, including any new risks, gaps or issues.

Tip #6: Ensure strong communication among the teams and stakeholders.

Since the entire organization is impacted by an ERP project, you must communicate both up and down the organization. For example:

  1. The project manager must report to the steering committing (oftentimes the CEO, CFO, COO and CIO) when the project requires more money, the core team desires (or requires) a change in scope, or a critical issue needs to be resolved.
  2. The core team must communicate with the end-users whose jobs will be impacted by the ERP implementation.
  3. The steering committee must communicate with the core team at least monthly during the project to provide status updates, to re-confirm its commitment to the project, and to report any major issues that could impact progress.
  4. The core team must communicate with external stakeholder groups that might be affected by the project. For example, customers and vendors should be involved in the project to the extent that their processes for interacting with your company will be changed.

Organizations put a lot at stake when they embark on ERP projects. Taking the steps above will increase your chances of a successful outcome.

Do you want to follow a time-proven ERP implementation methodology? Check out the 2nd edition of our book, Milestone Deliverables: ERP Project Management Methodology.