From One Factory to Ten: Build an AMR Rollout That Can Travel

The Second Factory Tests What the Pilot Actually Proved

A pilot factory has eight autonomous mobile robots moving components between a supermarket and assembly. The fleet meets its agreed service target, operators can handle routine exceptions, and the project sponsor wants the same result at nine more plants. Purchasing sees an opportunity to consolidate equipment orders. Engineering sees an opportunity to reuse its work. The receiving factories see a launch date approaching. All three expectations can be reasonable, but they depend on different assumptions about what the pilot has made repeatable.

A credible multi-site AMR deployment transfers an application with documented boundaries: the material flow it serves, the interfaces it needs, the configurations it permits, and the evidence supporting those choices. Each receiving plant then establishes whether its conditions fit those boundaries. The practical objective is to reduce repeated engineering while preserving the local work needed for reliable production. Buying identical robots is only one part of that transfer.

The distinction is visible in current industry plans. In its January 9, 2026 announcement, Otto Group described Loehne as the initial full-scale site and blueprint for a wider robotics coordination rollout. The announcement also assigned core interfaces and governance to Otto Group One.O. This was a stated deployment plan, not evidence that the proposed system was already operating throughout the logistics network. For manufacturing buyers, the useful lesson is the separation between a reference installation, an owned architecture, and subsequent site delivery.

This article follows two hypothetical factories and an illustrative deployment schedule. The factories, labor estimates, costs, and numerical thresholds are editorial examples, not reported customer results or universal benchmarks. The proposed management method connects the reference application, each site's differences, and the resources available to resolve them.

Plant A and Plant B Buy the Same Robot but Different Engineering Work

Plant A is the reference location. It uses one approved carrier family, two repeated station designs, a defined connection to the manufacturing execution system, and three trained shift leads. Its successful pilot produced useful operating knowledge. Some of that knowledge is explicit in drawings and software. Some remains in the integrator's memory: which carrier label is misleading, which restart requires a supervisor, and which production planner should be called when priorities change.

Plant B makes a related product and requests the same robot model. Its carrier has the same nominal payload but different supports. Its receiving station uses another controller family. The corporate manufacturing system is familiar, yet the local transaction treats arrival as receipt before the load transfer finishes. Maintenance coverage ends before the night shift. None of those differences is resolved by copying a purchase order.

The first transfer meeting should therefore compare application assumptions before equipment quantities. Ask which outcomes must remain identical, which inputs may vary within an established range, and which changes create a new engineering problem. This makes AMR implementation a bounded project that local teams can price and schedule. It also prevents a recipient plant from being labeled uncooperative simply because its operating conditions differ from the pilot.

There is a useful historical parallel. KINEXON's November 2023 Continental multi-factory case study describes related transport applications in Rheinböllen, Zvolen, and Changshu, alongside location-specific navigation, layout, and production-flow challenges. It is a supplier-published account, not an independent comparative trial. Its relevance here is narrow: a common corporate application area still encountered different local engineering conditions.

For Plant B, the immediate deliverable is a difference register. Each entry needs the affected requirement, the reference assumption, the local condition, the supporting evidence, the consequence, and an owner. Unknown conditions remain unknown until investigated. A blank field should never become an implicit statement that the reference design applies.

Make the Reusable Application Small Enough to Understand

A reusable package becomes valuable when another competent team can understand its permitted use without the original project leader standing beside it. A large folder of presentations, drawings, and backups may contain the necessary information, but it does not automatically explain which documents agree, which configuration was accepted, or which modifications are allowed. The package needs an owner, a release identity, and a clear statement of the application it supports.

Define the service before freezing the technology

Start with the production service: what material moves, when it becomes eligible to move, how the receiving process confirms completion, and who takes responsibility when the normal flow cannot continue. Preserve the distinction between transport arrival and a completed production handoff. A common service definition lets two factories compare their requirements even when their machine controllers, local terminology, or layouts differ.

Consider a mission described as replenishing released component carriers from a supermarket to assembly. The reference package should state whether a partial carrier is allowed, whether quality status can change during transport, and what happens to the empty carrier. These choices determine integration behavior. If Plant B needs a different answer, the program should recognize the difference before calling its installation a repeat of Plant A.

Separate common behavior from local values

Common behavior might include request validation, material identity rules, completion conditions, event definitions, and error ownership. Local values might include station identifiers, destination mappings, shift calendars, and route coordinates. Treating every local value as custom software creates unnecessary branches. Treating every behavioral difference as a harmless parameter hides changes that deserve engineering review.

Parameterization still has boundaries. A configurable maximum load does not establish that every value entered is acceptable for every fixture. A configurable timeout does not establish that every delay is compatible with production. Record who may change each value, the permitted range or selection rule, and the evidence needed when that boundary is crossed. The goal of factory automation standardization is a repeatable decision process with controlled variation.

A common communication protocol can help organize this architecture, but the participating systems must still agree on actions and states. The site's AMR interface interoperability guide explains those layers in detail. For a corporate rollout, preserve the agreed meaning of the interface in the common package and make each local adapter demonstrate that meaning. Reusing field names alone is insufficient.

Package evidence with its conditions

Attach tests to the configuration and conditions they exercised. A reusable software test can establish how an adapter handles a repeated message in a defined environment. It cannot establish that a different receiving station physically transfers a load correctly. A carrier drawing can define geometry; a test record can show what was tested; a local comparison can explain why that record remains relevant. These documents support different decisions and should remain distinguishable.

Dassault Systèmes' FORVIA Faurecia customer story describes both standardized logistics simulation functions and plant-specific AGV modeling and route validation. That combination supports a useful engineering principle: a common modeling method can travel while the model's local inputs still need to change. The account concerns the customer's manufacturing engineering approach; it does not demonstrate that a robot fleet can be copied unchanged between buildings.

Give Every Site Difference a Disposition

The transfer review should end with decisions that alter the work plan. A list of differences without dispositions leaves the same arguments waiting for commissioning. For this article's proposed method, each difference receives one of three outcomes: reuse the relevant evidence with an equivalence justification, supplement it with defined local evidence, or treat the affected scope as new engineering. These are management categories, not certification classes.

Reusing evidence requires an affirmative basis. The recipient configuration must remain within the conditions relevant to the claim, and the reviewer must identify the record supporting that conclusion. Superficial similarity is insufficient. Two stations might look identical yet run different control software. Conversely, a different station name may require only a configuration update and verification if the behavior and physical arrangement remain within the established application.

Supplementary evidence is appropriate when the reference work remains useful but does not answer a local question. The same request-handling logic may be retained while new destination mappings need testing. The same survey method may be reused while the actual routes need measurement. For those physical inputs, link the receiving project to a site-specific AMR readiness assessment, with each finding traceable to the intended mission.

New engineering becomes necessary when a changed condition invalidates a relevant assumption or extends the application. A new type of transfer mechanism, a different recovery responsibility, or an unproven load arrangement can create such work. The response should identify affected design decisions and validation needs. Calling it new engineering does not mean discarding the entire reference package; unaffected components may still be useful.

The disposition must name the decision owner and the party doing the work. Corporate engineering can approve whether a proposed variant belongs in the application family. Site operations can confirm that the intended workflow is usable. The integrator can implement and document the change. The responsible release team can then evaluate the installed system. A single approval cell labeled headquarters obscures these separate responsibilities.

When a site is almost ready

Plant B has closed its carrier question and completed its software mapping, but its night-shift support gap remains. Shipping robots may still be sensible if installation work can proceed productively. Opening unattended production at night is a different decision. Separate permission to deliver equipment, permission to commission, and permission to operate the agreed service. Each can have different prerequisites without turning the project into an all-or-nothing argument.

Where a narrower initial scope is approved, record its limits in operating instructions and configuration, with an owner for extending it. A temporary daytime service should not quietly become a permanent three-shift commitment. The receiving factory also needs a workable transition arrangement for the excluded work. Otherwise the deployment appears complete centrally while local supervisors absorb the unfinished scope through manual intervention.

Calculate the Deployment Rate Your Engineering Team Can Sustain

A mature AMR deployment strategy treats engineering capacity as a scheduling input. Equipment availability does not create integration, validation, or training capacity. If the same specialists are promised to several plants at once, the calendar may show simultaneous launches while the work can only proceed sequentially. The following example makes that constraint visible before purchase commitments fix the wrong dates.

Assume a program has four integration engineers over a twelve-week window. Each has five working days per week, and the plan reserves 25 percent of their time for existing fleet support, coordination, and expected interruptions. Deployable integration capacity is therefore 4 × 12 × 5 × 0.75 = 180 engineer-days. Assume all four can perform the scoped integration work; specialist limitations would reduce the scheduling freedom.

For each receiving site, estimate 16 engineer-days for adaptation and configuration, 10 for installation and commissioning support, 6 for integration-related acceptance work, and 4 for documentation and local handover. That totals 36 integration engineer-days per site. These are illustrative work-content estimates after reuse of the reference package, not elapsed durations or a promise that every plant will require equal effort.

Dividing 180 by 36 gives an aggregate ceiling of five sites for that resource in the window. The calculation does not prove that five sites can be completed. Work dependencies, travel, site shutdowns, access permissions, equipment arrival, and the need for two engineers simultaneously can prevent a theoretically balanced workload from fitting the calendar. The figure is an early resource check, followed by a real schedule.

The validation specialist is a separate resource in this example; the eight specialist-days do not replace the integration team's six acceptance-support days. That distinction prevents the same people from being counted twice. With the stated inputs, three completed sites is the strongest aggregate upper bound. Even three still requires a feasible dependency-based schedule. Adding robot inventory would not remove either the validation constraint or the shortage of production access windows.

Fund the resource that changes the completion date

Suppose the sponsor requests a fourth site in the same window. Buying another integration contractor may have little immediate effect because integration capacity already accommodates four sites in aggregate. The program must first examine validation availability and obtain another suitable production window. If those constraints can be resolved, it should then check whether the revised sequence creates overlapping peaks for the integration team.

This approach also changes how the team describes AMR commissioning. Commissioning work should arrive with the physical prerequisites, configuration inputs, competent people, and approved access needed to use the booked time. Sending specialists to a site that cannot provide a representative carrier or a functioning station consumes scarce capacity without closing the application. A readiness decision protects both the site's launch and the wider program's schedule.

Reserve a visible portion of the plan for uncertainty rather than hiding it in optimistic task durations. If the first receiving plant discovers a common defect, the program needs time to correct the package and reassess sites already in progress. The appropriate reserve depends on the maturity of the application and the known differences. The illustrative 25 percent allocation above is a stated assumption, not an industry standard.

Choose the Next Factory for What It Will Teach the Program

The easiest second site can demonstrate that the deployment package is usable by another team. It may provide little evidence about a very different third site. The hardest second site can expose important weaknesses but consume the entire program's engineering capacity. Site selection should therefore balance readiness, commercial value, and the particular uncertainty that the next deployment can resolve.

For example, select a ready plant with the same carrier family but a different station controller if the program needs to test whether its adapter boundary is well designed. A plant that simultaneously introduces a new carrier, a new transfer mechanism, a new production system, and an unfamiliar support partner may be a valuable project, but it is a poor test of which individual element is reusable.

This is where industrial robot deployment becomes a portfolio problem. Group receiving sites by meaningful application characteristics rather than country or annual robot budget alone. One family may share pallet interfaces and station behavior; another may require conveyor transfers; a third may have more demanding availability obligations. The grouping gives the program a rational basis for deciding which reference work applies and which variant deserves separate development.

Do not turn those families into rigid labels. A site can contain several application families, and a proposed local change can move one mission beyond its current family's boundary. The program should be able to explain the classification using observable conditions. A label such as standard plant tells a deployment team little unless the associated assumptions are available and still true.

Make knowledge transfer observable

Before widening the next wave, ask a second qualified team to use the package to perform a representative deployment task. Can it identify the correct release, configure a permitted variant, trace a failed test, and produce an acceptable handover record without undocumented instructions? The purpose is to discover missing knowledge while the original team is still available to explain it.

MiR's official scaling guidance discusses application-team support, commissioning resources, internal ownership, and global and local service capability. The editorial implication is practical: the customer should purchase and verify deployment capability alongside equipment. A supplier's corporate reach does not establish that the particular local team assigned to Plant B can deliver its station integration or train its night shift.

Ask for named delivery roles, relevant application experience, escalation arrangements, and the training needed for local personnel. Evaluate whether those people are available in the planned window. A qualified person who is committed elsewhere is not usable project capacity. The receiving plant should also identify who will own the process after the visiting deployment team leaves.

Price the Common Package and the Local Work Separately

Comparing AMR deployment costs across factories requires a consistent boundary. Separate shared application development, site adaptation, physical remediation, equipment, software entitlements, production transition, and continuing support. Otherwise the reference plant appears expensive because it funded reusable engineering, while later sites appear efficient because common costs are hidden in a corporate budget.

A supplier proposal should distinguish work included in the reference package from work triggered by local differences. Specify the permitted site count or deployment scope, the right to reuse deliverables, access to configuration tools, documentation formats, required software entitlements, and responsibility for updating adapters. Procurement should obtain explicit terms from the relevant parties; possession of a backup file alone does not explain what future teams are allowed or able to do with it.

Use an illustrative comparison. Independent integration for six future sites is estimated at $70,000 per site, or $420,000. A reusable package costs an additional $120,000 to develop and supports adaptation estimated at $40,000 per site. The six-site program would then cost $360,000 for that defined engineering scope, giving an estimated $60,000 reduction. Robot hardware, buildings, taxes, and ongoing operations are excluded from both sides of this example.

The nominal break-even count is $120,000 divided by the $30,000 engineering reduction per eligible site, or four sites. At four, the modeled costs are equal; beyond four, reuse reduces the modeled total. That result depends on eligibility and consistent scope. If only three plants can use the package at the assumed adaptation cost, the program spends $240,000 against $210,000 for independent integration. The extra investment has not paid back within that three-site scope.

Now suppose the fourth site introduces an unplanned interface requiring $35,000 of additional engineering. That amount belongs in the relevant site or shared-development budget according to who benefits. It should not disappear into a general integration allowance. The purchasing decision is whether funding that extension improves the remaining program enough to justify its cost and schedule impact.

These calculations illustrate a boundary for decision-making, not a savings forecast. Actual adaptation costs should come from the site difference register, defined deliverables, and supplier estimates. The relevant AMR supplier scope comparison can help structure responses. A fleet discount remains useful, but it should be evaluated beside the engineering and local operating work that makes each purchased robot productive.

Keep Local Release Authority and Shared Learning Connected

Corporate engineering should own the reference application's boundaries and approved revisions. The receiving site should own the accuracy of its operating inputs and the readiness of its people and facilities. The integrator should own the agreed implementation deliverables. The parties responsible for release must evaluate the installed application against its defined requirements. Commercial responsibility should remain explicit wherever several organizations participate.

A corporate package approval is therefore evidence for a local decision, rather than an automatic authorization to operate everywhere. The site's AMR site acceptance evidence matrix provides the detailed structure for that decision. The rollout program should identify what evidence can be reused, what must be supplemented, and who accepts the remaining limitations.

Once several plants are operating, local improvements create another challenge. Plant B may solve a problem that Plant A has never encountered. The solution might be broadly useful, limited to one variant, or unsuitable elsewhere. Before promoting it into the common package, identify the underlying requirement, the affected application families, the supporting tests, and the migration work for installed sites.

Use AMR configuration change control to govern those revisions. A reference release and a local deployment record should remain independently identifiable. Headquarters needs to know which package a plant uses and which approved differences it carries. A local team needs to know whether an update is relevant to its application before accepting the associated production interruption.

Measure whether reuse is becoming more dependable

The most informative program measures connect engineering effort to completed service. Track effort by application family, the share of local differences discovered before site work, rework caused by reference-package defects, elapsed time waiting for prerequisites, and successful handover to local operations. Keep scope visible when comparing sites. A plant with fewer interfaces should not automatically become the benchmark for every future installation.

For multi-site robotics, report equipment delivered, applications released, and applications operating within their agreed service conditions separately. Those milestones answer different questions. Counting shipped robots can help purchasing manage supply, but it does not show whether the receiving factory can sustain the promised material flow or whether central experts still provide unbudgeted support.

The final program decision is whether the next group of plants can absorb the released application with the people, evidence, and access available. A disciplined AMR rollout expands when those conditions are credible. It pauses the affected scope when a common assumption fails, corrects the package, and uses what was learned to make the next transfer more predictable.

Focused FAQ

Can a successful pilot be copied to another factory?

Its proven work can be reused where the receiving application remains within the relevant conditions. Compare carriers, station behavior, software interfaces, routes, operating demand, and support arrangements before claiming equivalence. Preserve useful design and test records, but obtain local evidence for conditions the pilot did not establish. A repeatable package explains both its capabilities and its limits.

What should be standardized first?

Begin with the production service and the meaning of its requests, states, handoffs, and exceptions. Then define the supported equipment and software combinations, permitted parameters, deployment artifacts, and test methods. Standardizing a robot model before agreeing on those behaviors can leave each plant implementing a different service behind a common equipment label.

How many factories can one deployment team launch at once?

Determine the answer from resource-specific work estimates and a dependency-based calendar. Include integration, validation, local training, production access, and continuing support for installed systems. The example in this article supports an aggregate ceiling of three sites within twelve weeks, given its assumptions. It is not a general recommendation or a guarantee that three sites fit every real schedule.

Does every factory need the same software configuration?

A program benefits from controlled common behavior, but different sites usually require local identities, layouts, and operating parameters. Keep those variations explicit and governed. A change that introduces new behavior deserves a different review from a permitted configuration value. Shared software should make variation understandable without concealing application-specific engineering.

What proves that the deployment package is ready to scale?

Evidence includes successful use by another qualified team, understood site differences, reproducible configuration, traceable local acceptance, and a workable handover. The next wave also needs available engineering resources and ready receiving sites. For autonomous mobile robot deployment, repeatability is demonstrated by transferring a defined production service under stated conditions, with the remaining work visible before commitments are made.

Professional Sources and Scope of Analysis

Sources reviewed September 24, 2026: Otto Group's January 2026 robotics coordination announcement; KINEXON's November 2023 Continental case study; Dassault Systèmes' FORVIA Faurecia customer story; and MiR's scaling guidance. Each is linked beside the relevant discussion. Announced plans and vendor-reported experiences are identified as such. The two-factory comparison, difference-disposition method, resource estimates, and cost calculations are original editorial analysis and illustrative assumptions, not requirements attributed to those organizations.

#AMRDeployment #MultiSiteAutomation #AutonomousMobileRobots #FactoryAutomation #RoboticsIntegration #IndustrialAutomation #ManufacturingOperations #AutomationProcurement