SCM Automation, Part 1: The Architecture of a Delivery Promise

SCM automation is a three-part KMS ITC series: 1. Delivery promises · 2. Feasible scheduling · 3. Accountable automation.

A customer orders bespoke windows for a construction project. Sales records the delivery date. Engineering releases a configuration. Purchasing raises material requirements. Production fits the work into a schedule. Logistics books a vehicle.

Each department can complete its own task correctly while the business makes a promise it cannot keep.

The glass may arrive after the assembly slot. The apparent spare machine capacity may require an operator who is already assigned elsewhere. A revised frame specification may invalidate an earlier purchase. The finished windows may leave the factory on time and still miss the site’s receiving window.

This is the problem we believe should organise supply chain management automation: how does an enterprise make, authorise and continuously maintain a delivery promise that its operating system can support?

Our position is that a delivery promise should be treated as a maintained business commitment, with dependencies, ownership and evidence. Automation should shorten the distance between a change in those dependencies and an informed response. That position draws on established planning and engineering disciplines; the framework developed here is KMS ITC’s architectural interpretation, not a vendor product specification.

Supply chain management extends beyond the factory schedule

Manufacturing is a useful place to make this argument concrete because physical constraints are difficult to disguise. But SCM also includes commercial demand, sourcing, inventory placement, distribution, returns and decisions about the network itself. ASCM’s SCOR Digital Standard connects orchestration with Plan, Order, Source, Transform, Fulfill and Return. That wider process view prevents production scheduling from becoming a substitute for supply chain strategy. ASCM: SCOR Process — Order.

Consider three decisions with very different consequences:

• Carry a common aluminium profile in stock before customer orders arrive.
• Reserve a constrained assembly cell for an accepted customer order.
• Expedite one late glass delivery at an additional freight cost.

The first changes exposure to demand uncertainty and working capital. The second allocates scarce capacity among customers. The third spends money to recover an existing commitment. They require different evidence, planning horizons and authority.

An automation programme that begins with a list of transactions to accelerate can miss these distinctions. Our preferred starting point is a map of consequential decisions: what triggers each decision, what information it needs, who owns the trade-off, and what must be true before the resulting action is released.

Use different planning horizons for different decisions

Long-range choices about suppliers, capacity and inventory policy shape what will be possible later. Near-term scheduling allocates resources within those choices. Execution then reveals whether the assumptions held.

Decision horizon	Principal question	Required outcome
Network and operating model	Where should capability and inventory exist?	Sourcing, capacity and service policies
Integrated business planning	Which demand and supply balance is commercially acceptable?	An agreed volume, capacity and financial position
Material and capacity planning	What must be procured or made, and where are the gaps?	Time-phased requirements and exceptions
Detailed scheduling	Which eligible resources perform which operations, and when?	A feasible sequence and release plan
Execution and recovery	What changed, and which commitments are affected?	Verified progress and authorised corrective action

These are logical responsibilities; they do not imply five applications. A smaller manufacturer may implement several within its ERP and a disciplined planning process. A more complex network may require specialised planning and execution systems. Architecture should determine the responsibilities and interfaces before selecting the number of tools.

The horizon also changes the useful level of detail. It is reasonable to model next quarter’s demand in product families while scheduling tomorrow’s work by operation and resource. Requiring exact job times months in advance creates precision that the underlying assumptions cannot sustain. Conversely, a monthly aggregate capacity figure cannot establish whether tomorrow’s qualified operator and machine are available together.

A requirement, a plan and a commitment are different business states

A requested date expresses demand. A calculated date describes what a model currently predicts. A committed date carries a business obligation. Actual receipt establishes what happened.

These dates should remain separately visible. If every planning run overwrites the original customer commitment, reporting can show an apparently punctual supply chain whose promises move whenever operations fall behind.

The same distinction applies to supply. SAP’s MRP documentation describes checking requirements against available stock and receipts, including procurement and production elements. The presence of a planning element is evidence within a calculation; its business status still matters. SAP: Net Requirements Calculation for MRP.

For implementation, we recommend making the following progression explicit:

Requirement identified → proposal evaluated → purchase authorised → order issued → supplier acknowledgement recorded → goods received → quality released.

These are not interchangeable confirmations. A suggested purchase has not been sent. An issued purchase order has not necessarily been accepted. A supplier’s acknowledgement can change. Goods on a receiving dock may still be unavailable to production.

This is an architectural requirement for preserving business meaning across interfaces. Every integration should carry enough status and provenance to prevent a downstream system from silently promoting an expectation into a fact.

What evidence should support a promise?

Available-to-promise and capable-to-promise calculations address part of this problem. In Dynamics 365, Microsoft distinguishes material availability checks from CTP calculations that also consider capacity; its guidance associates CTP with assemble-to-order and make-to-order situations. Those are documented product capabilities, whose behaviour depends on the configured engine and features. Microsoft Learn: Calculate sales order delivery dates using CTP.

Our broader proposal is to attach an evidence record to each consequential customer commitment. It need not be a new database product. It can be a governed view over existing records, provided their versions and relationships remain recoverable.

At minimum, that record should answer:

• What is promised? Configuration revision, quantity, destination, delivery window and acceptance conditions.
• On what basis? Material allocations, supplier confirmations, resource reservations, quality requirements and logistics assumptions.
• When was it evaluated? Calculation time, source freshness, planning horizon and assumptions still awaiting confirmation.
• Who accepted the trade-off? Commercial and operational authority, including any exception to normal service or cost limits.
• What would invalidate it? A material delay, changed specification, lost resource slot, quality hold or changed receiving window.

In the window example, the configuration revision is especially significant. An accurate inventory count for the wrong glass specification contributes nothing to delivery feasibility. Engineering changes must propagate through affected requirements, orders and reservations, rather than leave purchasing and production working from different definitions of the product.

Evidence has a useful lifetime. A promise assessed yesterday may need review after a breakdown today. The system should know which evidence changed and which orders depended on it. Recalculating every order after every event is often unnecessary; failing to reconsider the affected orders is unacceptable.

Service, inventory and utilisation must be considered together

A department can improve its preferred measure while worsening the customer outcome. Purchasing can reduce unit cost through larger batches while increasing cash tied up in stock. Production can reduce changeovers while delaying a high-priority order. Logistics can improve vehicle utilisation while missing a delivery window.

We therefore recommend an explicit hierarchy of objectives. Protect mandatory safety, quality and technical constraints first. Then evaluate customer service, total cost, inventory exposure and schedule stability within that feasible space. The exact ordering is a management decision, and it may differ by product or customer segment.

For repeat products sold from stock, replenishment policy and inventory accuracy may dominate. For configurable products assembled from common components, postponing the final configuration can preserve flexibility. For engineered products, design approval and long-lead procurement can become the controlling dependencies. Applying one planning policy to all three disguises the different risks.

Resilience follows the same logic. An alternative supplier has value only if the material is qualified, the commercial terms are usable and the replenishment route fits the required timescale. A second machine is an effective alternative only if tooling, process capability and labour can support the work. Architecture makes these conditions explicit so that management can evaluate the cost of preserving options before a disruption forces the decision.

Tesla and Toyota: two useful manufacturing lenses

The window example makes dependencies visible at the order level. Automotive manufacturing adds another perspective: the shape of the supply network and the way work flows through it. Tesla and Toyota offer useful public evidence, but neither company’s scale or reputation makes its operating model a universal template.

Figure: conceptual synthesis of publicly documented practices, not an internal factory blueprint or a performance ranking. The historical Tesla vignette is discussed in Part 3. Open the full-size infographic. Sources: Tesla 2025 annual report, Manufacturing and Supply Chain, Tesla 2019 annual report, production-ramp discussion, and Toyota Production System.

Tesla: choose which dependencies to own and where to locate them

Tesla’s 2025 annual report describes in-house vehicle and component manufacturing alongside external suppliers. It identifies regional manufacturing, shared components, selective qualification of alternative suppliers, safety stock for key parts and long-term raw-material arrangements. It also reports that its Texas lithium refinery began operating in January 2026. The same filing acknowledges continuing single-source and supply-disruption exposure. Tesla 2025 annual report, Manufacturing, Supply Chain and Risk Factors.

Our interpretation: SCM architecture includes decisions about which dependencies to internalise, shorten, standardise or buffer. A scheduler allocates work within that network; a make-or-buy decision changes the network itself.

For another manufacturer, the useful question is not whether it can reproduce a Gigafactory. It is which dependency most constrains its service and economics. Options might include bringing a critical finishing process in-house, qualifying a nearby supplier, standardising a component across products or agreeing a capacity reservation with a specialist partner. These are alternatives to evaluate, not recommendations to pursue all at once.

Each option transfers risk. Internal production brings responsibility for yield, maintenance, labour and capital utilisation. Regional sourcing may reduce transit exposure while increasing dependence on a local cluster. Common components can simplify procurement while making several product lines vulnerable to one shortage. Test these trade-offs against plausible disruption scenarios before treating integration as resilience.

The public sources establish business practices and risks. They do not establish Tesla’s current internal ERP configuration, scheduling algorithm, dispatch priorities or plant-level planning cadence. We therefore do not attribute a particular finite-capacity engine or autonomous planning system to Tesla.

Toyota: synchronise replenishment and expose abnormal work

Toyota describes two complementary principles: Just-in-Time links production to downstream need, while Jidoka makes abnormalities visible and permits equipment or operators to stop work. Its explanation explicitly includes small stocks prepared in advance and replenishment of what a subsequent process withdraws. It also places improvement of manual work before mechanisation. Toyota: Toyota Production System.

Our interpretation: flow depends on disciplined signals, reliable hand-offs and a credible response when reality diverges from the plan. Inventory policy and exception handling are part of the production architecture.

For the window manufacturer, a repeat-use hardware item could be replenished through a controlled consumption signal, while custom glass remains tied to the specific order and approved dimensions. A machining defect should change the affected part’s availability and trigger review of downstream assembly. A warehouse balance that continues to include rejected pieces would undermine both planning and replenishment.

This is why a pull signal and a delivery-date calculation answer different questions. The signal can authorise replenishment within an established operating policy; it does not by itself prove that a new customised order fits the full material and capacity network. A business can combine replenishment loops for stable components with order-specific scheduling for variable work.

Transfer the principles, then test the fit

These are complementary lenses, not mutually exclusive schools. Both manufacturers coordinate suppliers, people, inventory and technology. The useful comparison is the architectural decision being made:

Decision	Question to bring back to your operation
Network ownership and location	Which dependency merits internal capacity, a closer source or a qualified alternative?
Material flow	Which items suit consumption-based replenishment, and which require an order-specific plan?
Quality and recovery	What event stops unsafe or defective work, and how does that change downstream availability?
Automation scope	Which stable decisions can be delegated, and which exceptions still need judgement?

Do not copy an inventory level, automation ratio or plant layout without its operating conditions. Translate the principle into an explicit hypothesis, then measure its effect on delivery, cost and recovery in your own environment.

Measure the integrity of the promise

SCOR’s perfect customer order measure includes delivery performance, documentation and damage, illustrating why factory completion alone is an incomplete service measure. ASCM: Perfect Customer Order Fulfillment.

For an SCM automation programme, we propose a small complementary scorecard. These are suggested operational definitions, not claimed industry benchmarks:

Measure	Suggested definition
Original-promise reliability	Orders received in full within the original accepted delivery window, divided by orders due
Current-promise reliability	The same calculation against the latest customer-accepted window, with revisions separately counted
Recovery cost	Attributable premium freight, expediting and overtime per fulfilled order
Schedule churn	Released operations whose resource or start slot changes inside the agreed frozen horizon
Decision latency	Time from a material exception becoming available to an authorised disposition
Evidence completeness	Commitments with all mandatory evidence fields current, divided by commitments evaluated

Define exclusions, split deliveries, cancellations and time boundaries before using these measures. Keep the original promise even when a customer accepts a revision. Compare product families and similar operating conditions; a changing order mix can make an apparent improvement misleading.

Evidence completeness is a process measure, not a delivery probability. A record can be complete and wrong. It must be checked against outcomes.

Apply Intent-to-Evidence to the supply chain

The KMS ITC Intent-to-Evidence method offers a practical way to organise this work:

Intent defines the customer outcome and acceptable economics. Context establishes the product, supply, capacity and operating constraints. Authority assigns who may buy, allocate, expedite or change a promise. Decision selects the appropriate mechanism, from human judgement to deterministic rules or optimisation. Action changes operational state. Evidence preserves why that change was justified. Outcome tests the result at the customer. Learning updates assumptions and policies from what actually happened.

This sequence is useful whether the organisation runs a modern ERP, a long-established manufacturing platform or a combination of specialist systems. Established IT disciplines remain central: configuration management, transaction integrity, reconciliation, access control and exception ownership.

AI can help interpret supplier correspondence or explain alternatives. A constraint solver can evaluate feasible schedules. A simple rule can reject an expired approval. Their value depends on how they serve the decision, not on their novelty.

The strategic opportunity is to make commitments inspectable and maintainable across organisational boundaries. Once that foundation exists, faster automation can improve both responsiveness and accountability. Without it, the business risks accelerating the creation of unsupported promises.

Continue with Part 2: From Backward Planning to Feasible Schedules, where we test this argument against material deadlines, parallel production paths and finite resources.

Research reviewed on 7 October 2026. This series develops an original KMS ITC perspective from the supplied manufacturing examples and linked primary sources. The numerical scenarios are illustrative; the company cases are bounded by their cited public disclosures. Neither establishes the configuration or capabilities of any particular Pronto installation.