02 — The enterprise and its delivery model

The enterprise promises an outcome

The customer needs a capability that can be used. In the fictional programme considered here, four customised combustion-engine utility vehicles must perform their intended roles with suitable people, equipment, facilities and support. A vehicle containing the ordered equipment is an important achievement, but it does not by itself establish that the customer can operate the vehicle as intended. Delivery must connect the physical product to operating arrangements, training, maintenance and evidence that the agreed need has been met.

The customer also has decisions to make. Operational priorities can compete with affordability, delivery dates and the resources available to support the fleet. Additional equipment, for example, may require more electrical power, maintenance capacity or space. Engineering can explain consequences and propose solutions; the authorised customer decision-maker must resolve changes to the agreed need. A supplier or vehicle integrator cannot silently redefine capability because a particular solution is easier to deliver.

Here, enterprise means the organisations and responsibilities that together make delivery possible: the customer, programme leadership, engineering, commercial teams, supply chain, manufacturing, quality, assurance and support, including major suppliers. They need not belong to one company. The practical question is how their separate commitments combine into an acceptable vehicle and a usable fleet.

Responsibilities meet at decisions

Programme leadership brings together scope, dates, cost, resources and exposure. Engineering establishes and justifies the technical solution. Commercial staff establish contractual obligations within their delegated authority. Manufacturing teams determine how authorised work can be carried out with available facilities and resources. Quality and assurance provide checks and evidence required by agreed arrangements. Support specialists establish what will be needed to keep the delivered product usable.

These responsibilities interact without becoming interchangeable. An engineer may conclude that a supplier's substitution is technically acceptable, but that does not authorise a price increase, amend a delivery obligation or accept the vehicle. A buyer may negotiate favourable terms without authority to approve a technical departure. A programme manager may prioritise resources without being entitled to declare unresolved technical evidence satisfactory.

Each consequential commitment needs to identify its decision owner, the scope of that authority and the contributing judgements required. When several decisions are needed, record them separately and connect them. One meeting can coordinate them, but attendance should not count as implicit approval of every consequence.

Information ownership is related but distinct. One person may maintain the equipment specification, another the installation plan, and the supplier its detailed internal design. Ownership includes keeping information fit for its intended use and resolving questions about it. It does not automatically confer authority to change a contract or accept operational risk. Organisation and authority develops these distinctions into explicit roles.

The cooling module connects several responsibilities

Consider the cooling module in our four vehicles: a radiator, fan, hoses, electrical connection and mounting brackets. The enterprise buys the combustion engine and transmission, designs the chassis and mounting brackets, and obtains supplier-designed heating, ventilation and air conditioning (HVAC) and harness assemblies.

Engineering must establish how the cooling arrangement serves the engine under the agreed operating conditions. The supplier needs a defined responsibility boundary; the integrator must coordinate coolant connections, fan power and control, airflow, mounting, packaging and service access. A supplier's module analysis cannot alone establish the performance of the installed vehicle.

Assembly boundaries serve different decisions. A radiator and fan might be installed together as a manufacturing module while remaining separate service replacements. Their electrical and thermal functions cross that grouping. Someone must own the compatibility of each cross-boundary connection, even when the mating parts come from different suppliers. Connection definition, the operation that makes the connection, and evidence that it was completed answer different questions.

The purchase therefore needs agreement about the supplied definition, interface information, delivery dates and evidence. Reserving supplier capacity, authorising bracket manufacture and authorising module installation are different commitments. Calling all of them “module approval” conceals which information may safely be used for which work.

Commercial commitments need technical meaning

A contract connects obligations to commercial consequences. For the cooling module, the parties should be able to identify which technical definition the supplier undertakes to meet and which information the vehicle integrator must provide in return. Dates for interface information can be as consequential to vehicle build as the equipment delivery date.

Payment, receipt, technical acceptance of a deliverable, permission to use information and final acceptance of the supplied product are separate events. The contract needs to establish how they relate. Paying an agreed milestone need not establish that every package requirement has been verified; receiving a model need not make it suitable for bracket manufacture.

Commercial staff need engineering input to understand these distinctions, while engineering needs commercial input to understand what the enterprise has promised. If a requested interface change affects supplier price or delivery, technical agreement must connect to the appropriate contractual decision. Informal correspondence saying “acceptable” can leave different teams acting on different understandings.

The customer and supplier contracts also need compatible responsibilities. If the enterprise promises vehicle performance but purchases only equipment delivery, someone must still own integration and the evidence supporting vehicle-level performance. Buying a package does not transfer every consequence of its use to the supplier. Major contracts and supplier engineering develops this subject.

Evidence makes commitments assessable

A delivery plan describes intended progress; evidence establishes what has been demonstrated or completed. The enterprise needs both, and must know precisely what each item of evidence supports.

For the cooling module, requirements state necessary performance and constraints. Architecture allocates responsibility between the package and vehicle systems. Analysis supports judgements about adequacy. Product definition specifies equipment and interfaces. Manufacturing planning defines how brackets and connections will be made and checked. Execution records show the work actually performed. Acceptance evidence relates observations and results to agreed criteria on an identified configuration.

These information categories answer different questions. A calculation predicting adequate flow is not a record that the installed system achieved it. A completed installation task does not establish that every acceptance criterion has been met. A passed supplier test may support module acceptance while vehicle integration tests remain outstanding. Teams need a connected account of remaining work, not a general claim that the equipment is “done”.

A useful completion record identifies what was completed, the definition used, the acceptance criteria and any unresolved conditions. Programme leadership can then distinguish a completed design activity from an accepted physical outcome and see where evidence is still missing.

When the customer changes the requirement

In our programme, customer requirements are held in DOORS. When a customer requests a change, the programme first needs to understand its consequences and agree how to respond. Recording the request does not authorise everyone to begin implementing it.

Suppose the customer raises the required payload after Vehicle 01 has entered build and Vehicle 02 has major components ordered. Engineering must assess chassis, suspension, braking and powertrain consequences; a stronger bracket alone is not an established solution. Alternatively, a changed hot-climate requirement calls for assessment of engine cooling, heating, ventilation and air conditioning (HVAC) performance, fan and other electrical demand, packaging and verification conditions. These are distinct customer requests, each requiring an explicit scope and assessment rather than a predetermined redesign.

The assessment starts from the previously agreed requirement and the request to change it. Engineers trace the consequences into derived requirements, architecture, interfaces, analyses and product definitions. Manufacturing and commercial teams establish which plans, orders, supplier commitments and work already in progress rely on that definition. Support teams assess any consequences for maintenance and spares.

The result needs to say which existing evidence remains valid, which analysis or testing must be repeated, and what each affected vehicle needs. Technical agreement, customer agreement and contractual authorisation are recorded by the people who hold those responsibilities. The resulting plan connects the revised requirement to the work and evidence needed to implement it.

Vehicle 01 needs an assessment of actual build status and possible rework; Vehicle 02 needs an assessment of committed orders and supplier work before instructions change. Vehicles 03 and 04 can incorporate an accepted change in planning, but only where it applies to their agreed requirements. A customer might request the higher payload for one vehicle or hotter operating conditions for selected units. Neither request establishes fleet-wide applicability. Each vehicle needs a recorded disposition, including any authorised retention of its existing basis and resulting limitations.

This customer-originated change complements the supplier-originated interface change below. Either may affect the other: a customer change may alter supplier commitments, while a supplier proposal may affect how a customer requirement is met. Requirements and specifications, configuration and effectivity and CM-II change management carry the detailed treatment.

Speed depends on justified commitments

Chassis fabrication can begin while the wiring harness and cooling installation are still being designed. This overlap can shorten delivery time, provided the team knows which decisions are stable enough to build against and which remain open.

For the cooling module, a mounting-bracket decision might require a sufficiently stable module envelope, mounting loads, attachment arrangement, installation tolerances and service access. It may not require every internal supplier detail. Electrical installation requires different inputs. Teams should establish what information is sufficient for each proposed use, rather than treating overall design percentage as a substitute for judgement.

Before authorising early work, the responsible people need to agree its scope, the information it relies on, the assumptions still open and the consequences if those assumptions change. They also need a way to detect a change before dependent work proceeds beyond the agreed limits.

Suppose the connection arrangement remains uncertain. Manufacturing engineering could propose fabricating unaffected chassis members while withholding unresolved mounting holes and hose supports. Engineering must establish whether the reserved space and interfaces are credible. Planning must assess later access and sequence. Commercial staff must resolve any supplier commitments involved. Programme leadership then has a concrete choice between time gained and remaining exposure, within its delegated authority.

The useful measure of speed is progress towards accepted delivery. Early fabrication can lose its benefit if later changes require removal, replacement and retesting. Measures of progress need to account for accepted outcomes and rework; drawing counts alone cannot show whether delivery is getting closer. Detailed readiness and concurrency mechanisms belong in progressive definition and concurrent engineering.

Four vehicles create four delivery situations

Assume instead that the supplier proposes a revised fan electrical connector. This is a supplier interface proposal, not a customer requirement change. It may leave the agreed performance requirement intact while changing the means of satisfying it. Engineering must assess both mating sides, pin assignments, electrical suitability, sealing, routing and service access, with supplier and harness responsibilities identified. A changed coolant outlet would similarly require assessment of the mating hose, routing, supports and installation access; it should not be treated as the same technical change as a connector revision.

Vehicle 01 is in build. The enterprise must establish which module and harness instances are present, whether connections have been made, and which inspections or tests have occurred. Adoption could require replacement parts, revised instructions, physical rework and renewed evidence. An uninstalled module on the shop floor creates a different exposure from an installed, tested one.

For Vehicle 02, major components are ordered. Purchasing must establish which supplier definitions and manufacturing states those orders cover. Engineering agreement to the connector does not amend the order or authorise a supplier to substitute it. For Vehicles 03 and 04, the proposal can be assessed before their first commitments, while preserving their individual requirements and planned configurations. A common revision is a possible outcome, not proof of interchangeability.

Type or part identity describes what is specified; a revision identifies a changed definition; an occurrence locates a use within a vehicle structure. Applicability states where a definition or decision is to be used, and a baseline records an agreed reference configuration. The physical instance is the actual equipment unit, which may have its own serial identity and history. The product information model and configuration and effectivity develop these distinctions.

The enterprise must decide which vehicles adopt the supplier change, what work implements it and what evidence demonstrates completion. CM-II change management develops the process connecting those decisions.

Delivery extends into service

At handover, the operator needs a trustworthy account of what is installed, what limitations apply and how the equipment is supported. For the cooling module, that includes applicable maintenance instructions, spares arrangements and relevant test and modification history. If Vehicle 01 retains an earlier connection arrangement, its support information must remain accurate even when later vehicles adopt a common revision.

A support problem can expose an earlier delivery decision. A replacement radiator may fit the specified envelope yet be impossible to remove through the available route. Maintenance considerations therefore need to influence design and installation while those choices can still be changed. Through-life outcomes include sustained usability and the ability to make later modifications against an understood configuration, as well as initial acceptance.

Support deliverables need owners and acceptance criteria alongside those for equipment and installation. Responsibility for maintaining the configuration record after handover must also be clear, with a route for reporting in-service changes to the relevant engineering and supplier teams. Through-life support develops detailed support and retirement arrangements.

Scale changes the coordination burden

In a major defence or infrastructure programme, the same kinds of decision extend across millions of part occurrences, years of manufacture and thousands of people. Several work fronts may be active against different supplier baselines and multi-million-pound contractual commitments.

Coordination at that scale depends on delegated authority, bounded work packages and traceable decisions. A central team cannot personally assess every occurrence, but local decisions still need a discoverable agreed basis. A requirement change may expose several suppliers and years of completed work. Programme leadership needs a consolidated account of affected commitments, retained evidence and outstanding implementation, while specialists retain responsibility for their own judgements. The depth of control should follow consequence and dependency, rather than impose the same bureaucracy on every task.

From enterprise decisions to implementation

The programme uses DOORS for customer requirements, NX for mechanical design, Capital for electrical systems, Teamcenter for product lifecycle management and SAP for enterprise resource planning. Their integration needs to reflect the responsibilities described here: who creates information, who authorises its use, what commitment relies on it and how completed work is evidenced. The architecture must also assign responsibility for systems models, software, manufacturing execution and service records. The implementation chapters explain those boundaries and the choices involved.

The next chapter, the engineering lifecycle and technical reviews, explains how technical decisions and evidence develop across the lifecycle. Model-based systems engineering then develops relationships between needs, architecture and evidence. Together, they build on this chapter's enterprise question: can the organisations involved explain what they have committed to deliver, who has authority to decide, and what demonstrates that each vehicle fulfils that commitment?