30 — Implementing the operating model

Implementing this operating model means changing how the business makes and fulfils commitments. Installing connected applications is one part of that work. The first useful outcome is a team able to identify its authorised basis, make a bounded decision and demonstrate what happened afterwards.

Establish accountability and scope

Name an accountable sponsor for the operating-model change and owners for technical definition, configuration, manufacturing planning, procurement, execution and acceptance evidence. Include operational users and suppliers where exchanges affect them. Give the team authority to resolve competing definitions and escalate decisions beyond its mandate. A system administrator cannot settle a disagreement about contractual or technical authority.

Select a bounded product and work scope with genuine interfaces. The cooling module is suitable because it combines mechanical mounting, fluid connections, electrical control and supplier dependencies. Include the bought engine and transmission interfaces and supplier HVAC and harness boundaries where they affect the selected decisions. Avoid expanding the pilot into a complete enterprise redesign before it has demonstrated a coherent transaction.

Define success as observable outcomes. A user can reproduce an issued baseline, identify affected vehicles, distinguish ordered from installed material and retrieve configuration-specific evidence. A customer change can be assessed without automatically overwriting the current manufacturing basis. These outcomes guide configuration and training more effectively than a list of screens to deploy.

Build the minimum information foundation

Agree identity, revision, occurrence and physical-instance rules before migration. Define stable cross-references, applicability and the relationship between engineering bill of materials, manufacturing bill of materials and bill of process. Assign authority at attribute-group level across DOORS, NX, Capital, Teamcenter, SAP and the selected execution and evidence tools.

The initial foundation can be modest. A controlled exception register can support an early pilot if ownership and reconciliation are clear. It must not conceal a missing decision or pretend to be an automated integration. Preserve the identifiers and evidence needed for future transfer so temporary arrangements do not create an untraceable history.

Readiness for the next stage requires agreement on representative cases, not merely approval of a glossary. Demonstrate a repeated part used in different positions, a changed incompatible endpoint, a supplier number mapping and a correction to a physical record. If people cannot explain these consistently, a larger data load will multiply the ambiguity.

Run an end-to-end pilot

Begin with a controlled baseline for the cooling-module commitment. Vehicle 01 is building, Vehicle 02 has major equipment ordered and Vehicles 03–04 are planning. Establish what each vehicle is authorised to receive, what material exists and which operations and evidence remain outstanding. Identify uncertainties explicitly rather than filling gaps with assumptions about the latest design.

Exercise the supplier connector change. Technical authorities assess both mating sides, manufacturing checks access and instructions, procurement disposes of orders and the configuration function records applicability. Verify that the interface can be rejected, corrected and retransmitted without duplicate commitments. Demonstrate retrieval of the earlier basis after the replacement is released.

Then exercise a customer hot-climate requirement change from DOORS. Include cooling and supplier HVAC effects, electrical demand, packaging and verification. Keep its contractual authorisation separate from technical adequacy. Use the payload change as another impact case where appropriate, without presuming a predetermined redesign. The pilot must show that different origins can share analysis while retaining distinct decisions.

Readiness requires evidence that the team can complete these cases and recover from errors. Check that a partial integration failure becomes visible, that the wrong mating pair cannot be treated as complete and that an installation record identifies the actual configuration. Successful demonstrations by developers alone are insufficient; intended users need to perform their own decisions and explain the resulting records.

Migrate with controlled coexistence

Inventory legacy information by business purpose and trustworthiness. Prioritise active commitments, configurations under manufacture, long-lead supply and acceptance obligations. Retain historical material needed to interpret current products. Do not migrate every obsolete file into an apparently authoritative product structure simply because storage is available.

Resolve duplicate identities under accountable engineering and information ownership. Preserve supplier cross-references and original provenance. Where a released baseline cannot be reconstructed, record the limitation and establish a controlled recovery basis. A newly populated database must not imply certainty that the source records never contained.

Rehearse migration on complete configuration slices and compare source and target answers. Test relationship semantics, units, applicability and evidence access as well as record counts. Include software and calibration identities where they affect physical behaviour. An imported hardware structure without the matching control basis can be incomplete even when every mechanical part is present.

During coexistence, specify which source controls each scope and how changes cross the boundary. Avoid allowing two applications to edit the same authoritative attribute independently. Define the cutover event, reconciliation criteria, fallback conditions and responsibility for unresolved transactions. Falling back must preserve transactions made since cutover; restoring an old database alone can lose authorised work and misrepresent current obligations.

Readiness for operational cutover includes users, support and supplier exchanges. Ensure outstanding orders can still be understood, production can retrieve valid instructions and evidence remains accessible. Make rollback or containment decisions before the migration window. A technically successful import is only one part of business readiness.

Train decisions as well as transactions

Train roles through realistic tasks. An engineer identifies the affected occurrences and interface basis. A planner reconciles manufacturing content without silently changing product requirements. Procurement distinguishes a technical release from authority to amend a contract. An operator records actual work and escalates an unsuitable configuration. An inspector links results to the configuration assessed.

Provide concise role guidance, practice environments and named support. Assess competence through demonstrated decisions and recovery from mistakes. Attendance at training does not establish readiness. Managers also need training because unofficial instructions to bypass controls can undermine careful application configuration.

Retain an accessible route for urgent work. Proportionate control allows a bounded low-impact correction to follow a simpler route than a cross-system change affecting expensive commitments. Define the limits and evidence of that route. A permanent emergency process with retrospective approval merely hides uncontrolled commitments.

Expand by capability and evidence

Extend to adjacent assemblies and suppliers after the pilot's unresolved issues are understood and owned. Reuse information semantics and decision patterns while checking local differences. A supplier retaining internal design authority may require a controlled interface package rather than full internal models. A long-running manufacturing programme may need historical baseline retrieval and support access long after the original team has moved on.

At each expansion, assess data volume, query behaviour, permissions, integration recovery and operational support. Millions of occurrences require representative configuration and impact queries; thousands of users require delegated authority and usable access boundaries. Years of manufacture require upgrade compatibility and retained interpretation of older records. These characteristics must be tested rather than inferred from success with four vehicles.

Introduce additional capabilities where a demonstrated need justifies them: specialised systems architecture, software lifecycle management, simulation governance, manufacturing execution or service configuration. NX, Capital, Teamcenter and SAP form the core architecture, but their presence alone does not settle these responsibilities. Choose implementations against the information and decision requirements already established.

Sustain and improve

Use the measures in chapter 29 to identify blocked commitments, implementation latency, rework and evidence gaps. Establish a review cadence with owners able to change the process and configuration. Separate defects in the operating model from training gaps and software faults; each requires a different remedy.

Retain control of configuration customisation and exchange mappings. Changes to workflows, permissions or identifier rules can alter engineering meaning. Test them against the pilot scenarios and historical retrieval before release. Maintain operational ownership after the implementation team leaves, including support escalation and responsibility for failed exchanges.

CM-II remains the change-management basis, but detailed framework terminology and conformance require the selected authoritative reference and competent implementation review. Do not treat this roadmap or a configured workflow as certification. Likewise, sector-specific assurance, security and contractual obligations must be incorporated when established, with corresponding evidence and authority.

Adoption is credible when ordinary work continues to produce trustworthy decisions under pressure. The final readiness question is whether the organisation can explain what it authorised, what it committed, what it built and what supports acceptance, including the exceptions. That capability allows manufacture to advance while the wider design develops, with exposure visible and responsibility attached to each commitment.

Make stage gates operational

A stage gate should identify who decides, which evidence they inspect and what remains forbidden after passage. The sponsor owns investment and scope decisions; technical, manufacturing, commercial and evidence authorities retain their delegated judgements. Passing a data-foundation gate does not authorise production. Passing a pilot gate does not demonstrate enterprise capacity.

A failed gate produces an owned recovery action and a revised decision, not an informal waiver hidden in meeting notes. Manufacture can continue within previously authorised boundaries. For example, a failure in cooling-package migration need not stop stable chassis work if no affected dependency crosses that boundary. Explicit scope makes this judgement possible without pretending that the complete vehicle design is finished.

Recover a pilot exception

During a rehearsal for Vehicle 02, suppose the new fan definition transfers but the harness instruction still refers to the earlier connector. This is a constructed failure case for the pilot, not a claim about a real installation. Hold the affected mating operation and retain the issued package. Establish whether the error originated in engineering compatibility, manufacturing derivation or exchange mapping before changing data. Correcting a mapping cannot cure an incompatible engineering selection.

The technical authority establishes the acceptable pair. The planner reconciles the MBOM and BOP and issues corrected instructions and evidence requirements. Procurement checks whether the supplier has acknowledged the matching supply amendment. The integration owner replays or replaces the exchange under the contract's identity rules, then demonstrates that duplicates and delayed predecessors cannot reactivate the obsolete package.

Execution acknowledges the replacement package and confirms compatible resources and material. Restart requires technical clearance, executable instructions, available resources, acknowledgement and delegated acceptance of remaining exposure for the named unit and operations. Record the decision and check that unrelated work continued only within its authority. The pilot passes this case when users can retrieve both the earlier failure and the corrected basis and explain why restart became permissible.

If a service action is deferred, the receiving owner must accept its affected units, criteria, due event and return-evidence obligation. Transfer closure is recorded separately from physical completion. The acceptance and configuration views retain that distinction throughout migration and cutover; otherwise implementation can lose precisely the obligations it was intended to control.

Own coexistence after the implementation team leaves

Maintain a scope register naming the authoritative source for each information group during transition. A legacy order may remain commercially controlled in its existing process while its technical baseline is referenced in the new environment. Changes cross through a controlled exchange and reconciliation route. Users must know which source to correct and where to report disagreement; a banner saying that both systems are live is insufficient.

Assign operational owners for exchange queues, mapping changes, access requests, evidence retrieval and unresolved configuration records. Provide deputies and escalation routes for supplier and production working patterns. Training should include finding an obsolete package, rejecting an unsuitable instruction, correcting a mistaken installation record without erasing history and recovering a lost acknowledgement. Use observed competence to decide access and support needs, rather than treating course attendance as proof.

Before retiring a legacy source, demonstrate retrieval of the history still needed for active vehicles and contractual obligations, including software/calibration context and deferred service work. Retained exports need usable interpretation and access controls. Decommissioning is complete when the business can still answer its required questions, rather than when the old server is switched off.