13 — CM-II change management

A change is complete when the intended outcome has been implemented and demonstrated in every affected place. Approving a new cooling-module drawing is only one step. Orders may still specify the old module, a harness supplier may be using an incompatible connector, and an installed vehicle may require inspection or modification. Change management connects the decision to its consequences across the business.

CM-II provides the change-management basis considered here. IpX currently presents its framework as CM2. Its public course description explicitly addresses closed-loop and fast-track change, enterprise assessment, business decisions, implementation oversight and planned versus actual change records. These establish the scope of the framework; the public overview does not establish a complete process specification or demonstrate that an enterprise conforms to it. IpX CM2 framework, IpX CM2-04.

The lifecycle below is a concrete enterprise operating model. Its role labels and records describe responsibilities rather than a verified reproduction of CM2 training or a vendor schema. Exact framework terminology, edition and conformance criteria require a governing reference before a formal compliance claim can be made.

Receive a request without accepting its consequences

A change request records a desired departure from an identified reference. It needs an originator, reason, affected need or problem, current reference, desired outcome, urgency and known applicability. It can arise from a customer requirement, supplier notification, defect, improvement or obsolescence. A suggested solution is useful but must not conceal the underlying need. “Fit a larger fan” is not equivalent to “operate under the revised hot-climate conditions”.

Customer requirements are held in DOORS. A newly received requirement revision must be compared with the agreed baseline and linked to a change assessment. Receipt, contractual acceptance, technical approval and downstream implementation are distinct events. The requirement identifier and revision, source baseline, proposed vehicle applicability and disposition must remain traceable even if the integration is initially a controlled manual exchange. No automatic synchronisation or automatic acceptance follows from using DOORS.

The change coordinator checks completeness, identifies a responsible assessment lead and searches for related requests. Two requests may affect the same cooling module without being the same change. A payload increase and hotter operating conditions may interact through powertrain demand and thermal performance. Linking them allows coordinated assessment while preserving their separate customer decisions and contractual origins.

Assess the enterprise impact

Assessment establishes what would have to change and what would happen if the request were rejected or delayed. The technical lead brings together requirements, architecture, analyses, interfaces and product definition. Manufacturing examines work instructions, tooling, access, material and work in progress. Procurement asks suppliers about commitments, lead times and cancellation or amendment options. Programme planning assesses dependencies and resources. Quality, assurance and support identify evidence, obligations, spares and field implications.

Impact analysis begins with where-used information but extends beyond it. A changed fan connector affects the mating harness, cavity assignments, terminal selection, electrical protection assumptions, installation access, inspection and service identification. Some affected information may have no direct bill-of-materials relationship to the connector. The assessment lead must therefore combine structured queries with discipline judgement and supplier confirmation.

Each impact has a disposition: change required, assessed unaffected, or unresolved. An unaffected decision needs a reason and an accountable assessor. An unresolved supplier answer must remain visible as uncertainty; absence from a query result is not proof of no impact. Assessment should identify both the intended configuration and the actual state of affected vehicles, stock and orders.

Make the business disposition

Technical feasibility does not by itself authorise expenditure or a contractual variation. The business decision compares benefits, costs, risks, schedule consequences and the consequences of doing nothing. It can approve implementation planning, reject the request, defer it against a stated trigger, or request further assessment. The decision records its scope and assumptions. Approval of a concept must not be read as permission to issue every affected definition.

The programme authority owns delivery trade-offs within its delegation. Design authorities retain technical decisions, procurement retains purchasing authority and authorised customer representatives retain contractual decisions. Where these conflict, the issue is escalated with options and consequences. A committee vote cannot create technical evidence or override obligations outside its authority.

Routing should be proportional to impact and uncertainty. A correction with no changed technical meaning, no affected external commitment and agreement from all relevant consumers may use delegated approval. A connector substitution with unresolved compatibility, installed products or contractual effects requires broader assessment. Fast routing preserves the necessary decisions and evidence; it removes unnecessary queues. IpX identifies fast-track as part of its framework, but the precise criteria used here must be established in the enterprise procedure rather than inferred from a course overview. IpX CM2-04.

Plan before issuing incompatible information

The implementation plan translates an approved outcome into sequenced work. It identifies definition changes, verification work, material disposition, order amendments, manufacturing-plan changes, supplier notifications, service updates and physical interventions. Each task has an owner, dependency, completion evidence and relevant vehicle or material applicability.

Release and implementation dates may differ. The new connector definition can be released before a compatible harness is available. A plan that simply marks the connector effective immediately could then authorise an impossible build. Effectivity describes the conditions under which a definition or change applies; implementation planning must ensure that those conditions are coherent across both mating sides and all consuming records.

The plan also defines the transition. Existing stock might remain valid for Vehicle 01 while new material serves Vehicles 03–04. Alternatively, commonality or performance may justify retrofit. Neither outcome follows automatically from revision order. Procurement needs instructions for open orders, stores needs identification and segregation rules, manufacturing needs a safe cut-in point, and support needs the resulting applicability. Plans should include recovery if a dependency slips.

Release, implement and close

Definition owners create and check the changed information. Technical authorities approve it for the intended use. Configuration management coordinates the controlled issue and baseline relationships. Consumers acknowledge receipt and implement the planned changes. A released engineering bill of materials does not prove that a manufacturing bill of materials, process plan or purchase order has changed.

Closure compares planned and actual implementation. It requires completed tasks, resolved exceptions, reconciled applicability and evidence for affected physical products. If Vehicle 01 retains an authorised earlier configuration, closure records that disposition rather than falsely claiming fleet-wide replacement. If a retrofit is deferred to service, an accountable service action and its control boundary must remain explicit; administrative closure must not erase outstanding work. Transfer to a service action requires an accepting owner, identified vehicles, completion criteria and a tracked due event. The change record must distinguish closure of the transfer from completion of the physical intervention; the latter remains outstanding until unit-specific evidence is returned and reconciled.

For the supplier connector change, Vehicle 01 may already contain the old module and harness. Vehicle 02 has major components ordered, so supplier progress and order terms determine feasible options. Vehicles 03–04 remain in planning and may adopt the new arrangement with less disruption. The assessment identifies both endpoint occurrences, connector definitions and revisions, installation instructions and required evidence. Engineering controls compatibility; execution records establish which physical connector and harness were installed and checked.

A customer payload change follows the same lifecycle but has a different assessment boundary. Structure, suspension, braking and powertrain implications must be examined before selecting a solution. Changing the DOORS requirement alone cannot establish the vehicle’s capability. The accepted requirement baseline, technical implementation and acceptance evidence must eventually agree for each applicable vehicle.

Defects and emergencies

A defect is a failure to meet an applicable requirement. Its immediate containment and physical-product disposition are distinct from changing the design. A damaged connector may require replacement under the existing definition; it does not necessarily justify a revised part. Conversely, repeated failures may reveal a design problem requiring a controlled change. Link the defect, investigation, corrective action and change without treating them as interchangeable records. Detailed nonconformance disposition belongs in chapter 22.

Emergency change compresses elapsed time because delay creates unacceptable exposure. It still needs identified authority, a bounded scope, immediate instructions, affected-unit identification and recorded evidence. The emergency route should specify who can stop work, who can authorise temporary action and when normal assessment must catch up. Urgency does not confer permission to waive an external obligation. Temporary action needs an expiry or replacement decision so that an improvised arrangement does not become an undocumented permanent configuration.

Tools and scale

Teamcenter offers configurable change workflows and impact-analysis capabilities; Siemens also describes closed-loop execution. These are useful platform capabilities, not proof that the selected installation contains all required links or implements this lifecycle. Siemens change-management fact sheet.

The logical change record should link its initiating request, assessed baseline, affected objects and occurrences, decisions, implementation tasks, effectivity and closure evidence. NX and Capital provide discipline definition, Teamcenter coordinates controlled product information, SAP carries relevant order and material consequences, and DOORS retains customer requirement context. Execution and service evidence need an explicitly selected authority; the four named platforms do not automatically supply every required capability.

Across millions of occurrences and years of manufacture, overlapping changes can invalidate each other’s assumptions. The change coordinator must detect shared affected definitions, competing cut-in plans and newly discovered physical states. Thousands of participants need concise queues showing their decisions and dependencies rather than universal attendance at a single board. Proportionate delegation and durable implementation evidence make closed-loop control practical at scale.