Multi-Site MES Implementation: How to Roll Out Across Multiple Plants

To roll out a manufacturing execution system (MES) across multiple plants, agree a shared process template, document justified local differences and test it at a representative site before expanding. Give each plant clear ownership of its data, training and readiness checks. Move sites into live operation only when their workflows, integrations and contingency arrangements meet agreed acceptance criteria.

The difficult decisions often sit in the details. Two plants may use the same word for different production statuses. One records material consumption when a build starts; another records it afterwards. An approval handled by a dedicated quality team at one site may sit with a production manager elsewhere.

These differences need attention before they become software settings. A useful multi-site MES implementation makes production information consistent enough to understand across the business while supporting the work each plant actually performs.

Start with the work you want to improve

Before discussing rollout dates, identify the problems the implementation should address.

Perhaps planners cannot compare available capacity across sites. Production records arrive in different formats. Jobs transferred between plants lose their connection to earlier inspections. Operators enter the same information into several systems.

Choose a manageable set of outcomes and establish the current position. For example:

• How much time do planners spend collecting site updates?

• Which production records are regularly incomplete?

• Where does duplicate entry occur?

• What information is missing when work moves between plants?

• How long does it take to retrieve a completed part’s production history?

Define the scope alongside those outcomes. Specify the sites, processes, departments, job types and system connections included in the first release.

A rollout covering production tracking at two similar plants is a different project from one replacing scheduling, material records and quality workflows across several technologies. The plan, budget and acceptance criteria should reflect that difference.

Build a common process template

The common template describes how work will be represented and controlled across the organisation. It should be understandable to production staff before anyone configures it in software.

Start by following representative jobs through planning, production, post-processing, inspection and release. Compare what happens at each plant, including the exceptions people usually handle through calls, spreadsheets or handwritten notes.

Then agree the shared foundations.

Template element	What to agree across sites
Job and part identification	How orders, parts, builds and site references remain distinguishable
Production statuses	What each status means and what must happen before it changes
Required records	Which information must be captured at each applicable stage
Responsibilities	Who records work, reviews results, places holds and authorises release
Revision control	How users identify the approved instructions and production requirements
Exception handling	How delays, failed inspections, rework and missing information are handled
Reporting definitions	How measures are calculated and which work they include

In additive manufacturing, pay particular attention to the relationship between orders, builds and individual parts. Several orders may share one build, then follow different finishing or inspection routes. The template needs to preserve those relationships without treating every part as though it has the same history.

Give the template a named owner and a version. Record changes, approvals and which sites use each version. Otherwise, a useful shared starting point can gradually become several undocumented local configurations.

Allow local differences that have a clear reason

Plants do not need identical workflows to produce information the business can trust.

Different machines, materials, customer requirements and production responsibilities can justify different routes. A site using an external heat-treatment supplier may need a dispatch and receipt step that another plant handles internally.

The important question is whether a difference serves a production need.

For each proposed variation, record:

• What differs from the common template.

• Why the difference is needed.

• Who owns and approves it.

• Whether it changes data exchange, reporting or support.

• How it will be tested.

Consider a hypothetical two-site AM operation. Both plants record inspection results before release. One customer also requires an independent review at the second plant. The shared template can retain a common release status while that site uses an additional approval step.

That is a justified variation. Calling unfinished work “complete” at one plant because the local team has always done so creates a reporting problem.

Review variations as the rollout develops. A workaround needed during the first launch may become unnecessary once an integration or process change is available.

Give central and site teams clear responsibilities

A central project team cannot make every local operating decision. Equally, individual plants should not have to resolve organisation-wide data rules independently.

Agree who makes each decision and who supplies the evidence.

Responsibility	Typical owner
Shared process template and reporting definitions	Central process owner, with site representatives
Local routes, staffing and operating readiness	Site implementation lead
Record requirements, holds and release controls	Relevant quality and process owners
Migration preparation and record reconciliation	Named data owners
Interfaces, access and technical testing	IT and integration owners
Configuration and supplier deliverables	Implementation team and software supplier
Go-live decision	Named business authority, supported by site, quality and IT sign-off

One person may hold several responsibilities in a smaller business. What matters is that the responsibility is explicit.

Include operators, planners and quality staff early enough to influence the design. They can often identify practical problems that a process map misses: a shared workstation that is too far from the job, an approval unavailable on the night shift, or a required field whose information does not exist at that stage.

Choose a pilot site that will teach you something

The easiest plant to launch may leave important questions unanswered.

Select a site or bounded production area that represents enough of the wider operation to test the common template. Look for relevant job types, production steps, system connections and people who can support the evaluation.

Keep the scope manageable, but include meaningful exceptions. A pilot that handles only straightforward jobs tells you little about rework, shared builds, delayed approvals or material holds.

Define what the pilot must prove before it begins. Useful tests include whether:

• Operators can complete assigned tasks using the correct instructions.

• Parts retain their order and build relationships through downstream work.

• Quality staff can apply and resolve holds through the agreed process.

• Planners can identify incomplete work and delayed updates.

• Required records can be retrieved without rebuilding the history manually.

Our guide to running an additive manufacturing workflow software pilot explains how to turn these questions into observable acceptance tests.

Use the results to revise the shared template, training and rollout plan. Record unresolved issues and decide which must be fixed before another site starts.

Decide what data to migrate and what to retain elsewhere

Migration needs more detail than “bring the old records across”.

Separate the information into categories:

• Master data: resources, materials, users, approved routes and other reference information.

• Open work: jobs already in progress, including their current status and outstanding requirements.

• Historical records: completed production histories and supporting documents.

• Reference material: instructions, specifications and other controlled documents used during production.

Not every historical record necessarily needs to move into the new MES. Some may remain in an accessible archive, depending on retention, retrieval and contractual requirements.

Whatever the approach, users must know where the authoritative record sits.

For open work, choose an explicit transition point. A job might finish under the existing process, transfer at a defined operation, or move entirely into the new system. Test the chosen approach before cutover.

Check more than record counts. Sample the relationships that make the data useful: part to order, part to build, material lot to recorded use, inspection to the correct item and revision.

Rehearse the migration and record how long it takes. Identify who resolves rejected records, how changes made during the transition will be captured and how the final result will be reconciled.

Test integrations using complete production scenarios

An interface can successfully send a message while still producing the wrong operational result.

Test the full journey. For example, an order arrives from an enterprise resource planning system, becomes production work in the MES, changes during planning and later receives a completion update. Confirm what each system should contain at every stage.

Agree ownership of each data item. Which system controls the order quantity? Where is the approved revision maintained? Who resolves a disagreement between records?

Include failure scenarios:

• An update arrives late.

• A message is sent twice.

• A required field is missing.

• A connection becomes unavailable.

• A job changes after production has started.

Check how users recognise the problem, who receives it and how the records are reconciled. Do not assume that repeating a failed message is always harmless.

Test site permissions too. A user should be able to perform their authorised work without gaining unintended access to another plant’s records or settings.

Where sites share infrastructure, include representative combined activity. Passing a test at one quiet plant does not establish performance during overlapping shifts across the organisation.

Prepare a cutover plan people can follow

Cutover is the point at which the new process becomes the agreed way of working for the defined scope.

Write a timed plan with named owners. It should cover final data preparation, any restrictions on changes, migration, interface activation, access checks and the decision to start live work.

Make the transition visible to everyone affected. Operators need to know which jobs use the new process, where to find instructions and how to raise a problem. Support teams need to know who is on duty and which issues require an immediate response.

Prepare fallback arrangements before the launch.

A rollback may be practical before new transactions begin. After operators have recorded production, material movements or inspections, reverting to an earlier system can create conflicting histories. The plan must explain how those new records will be preserved and reconciled.

For some failures, the appropriate response may be to pause affected work or use an approved temporary process while the issue is corrected.

Our article on maintaining production control when an AM workflow system is unavailable covers the records, responsibilities and recovery decisions that a continuity plan should address.

Require site acceptance before expanding

Installation is only one part of readiness. Each site needs evidence that its people, workflows and supporting systems are ready for the agreed scope.

Set acceptance criteria before testing starts.

Area	Example acceptance evidence
Production workflow	Representative jobs complete the applicable route with required records
Quality controls	Authorised users demonstrate holds, reviews and release steps
Migrated data	Agreed checks confirm record accuracy and required relationships
Integrations	Routine exchanges and selected failures produce the expected results
Access	Users can perform their roles with the agreed permissions
Performance	Selected tasks meet agreed response expectations at representative load
Training	Relevant staff can complete their tasks and report exceptions
Continuity	The site has practised the agreed interruption and reconciliation process
Support	Escalation routes, responsibilities and coverage are confirmed

Separate critical failures from minor issues with agreed workarounds. Give every outstanding issue an owner and a resolution plan.

After launch, allow time for close support and review. Define when the site can move into normal support based on evidence such as unresolved incidents, record completeness and staff readiness.

Use consistent definitions when measuring results. Comparing cycle time between plants is misleading if one measures printing alone and another includes post-processing and inspection. Establish the baseline and boundaries before claiming improvement.

Where Authentise fits

For AM operations, Authentise FlowsAM provides tools for planning and tracking production, managing material information and maintaining production records.

Those capabilities belong in the rollout tests. Ask the implementation team to demonstrate your shared-build relationships, local routes, required records and system connections using representative work.

Agree the proposed configuration, integration scope and responsibilities for each site. A successful first installation provides useful evidence, but the next plant still needs its own readiness checks.

Start the rollout with one practical deliverable: a shared process template that the first site can test. Improve it through real jobs and exceptions, then use the results to prepare the next plant. That gives each launch a clearer foundation and makes the lessons reusable across the business.