The Conserved Pipeline: Stage Gates, Pending Inventory, and Locating the Constraint in an Order-to-Cash System

1.1The eleven o'clock test

The product's material proposes a test worth repeating: ask a shop-floor supervisor when their team sees a schedule change made at eleven in the morning. If the answer is tomorrow's stand-up, the system is generating reports rather than running the floor.

It is a good test because it is unfalsifiable by a specification sheet and answerable in one question. This paper generalises it. A pipeline whose gate counts are visible and conserved can be interrogated the same way at every stage, and Section 6.3 turns that into eight such questions.

1.2Contributions

1. The order pipeline stated as a conserved cascade, with the identity verified against the product's own reported counts (Section 4.1).
2. Constraint location from pending counts alone, requiring no cycle-time study (Section 4.2).
3. Stage flow time as Little's Law per gate, converting a pending count into days of customer-visible delay (Section 4.3).
4. The cash-cycle extension beyond the invoice gate, and the exact-decimal requirement every monetary computation in it carries (Sections 4.4 and 6.2).
5. An eight-dimension capability reference framework for manufacturing ERP (Section 6.3).

2.1From requirements planning to enterprise planning

Orlicky's 1975 statement of material requirements planning is the founding text. Its central move was to derive component demand from a production schedule and a bill of materials rather than forecasting it independently — dependent demand, calculated, not predicted.

Everything since has widened that calculation without changing its shape: manufacturing resource planning added capacity and finance, enterprise resource planning added the rest of the business. The consequence for this paper is that the object at the centre of an ERP is a plan, and a plan is only as good as its ability to be re-derived when something changes.

Harris's economic order quantity sits underneath the same structure, fixing lot size by balancing set-up cost against carrying cost. It is the reason a production sheet quantity is rarely the sales order quantity, and the reason those two numbers appear as separate columns rather than one.

2.2The boundary the standard actually draws

IEC 62264, adopted from ANSI/ISA-95, separates level 4 business planning from level 3 manufacturing operations and specifies the interface content between them. Part 2 gives the object model that content must satisfy; Part 3 gives the activity models — production, quality, maintenance, inventory — that live at level 3.

The standard is explicit that these are different responsibilities, not different screens of one application. This is exactly the distinction the product's material draws when it says an ERP should be the system of record while high-resolution production data lives where it belongs — a position this paper endorses, because the alternative makes the ERP responsible for data it cannot capture at the required rate.

2.3Why a pipeline is a queueing system

Little's Law relates the number of items in a system, the rate at which they arrive and the average time each spends there. It holds in steady state for any system with a defined boundary, and an order-processing gate is such a system: orders arrive from the preceding gate, wait, and leave.

This is the mechanism that lets Section 4.3 convert a pending count — a status, seemingly — into a number of days. It is also the reason a pending count that stays constant is not evidence of a healthy gate: constant work in process with a low clearance rate is a long delay, not a stable one.

3.1The five documents and the four gates

The chain is observable in the captures. A production sheet carries its own order number alongside the sales order number and the customer purchase order number; the invoice screen retrieves its delivery order rather than being typed against a customer. That is the same identity-at-capture discipline that governs traceability, applied to commercial documents.

3.2Two quantities and two dates on every line

Order lines carry ordered quantity and released quantity as separate columns, and promise date alongside required date. Both pairs exist for the same reason: the number the customer asked for and the number the plant committed to are different facts, and collapsing them destroys the only record of the gap.

The quantity pair is where lot sizing surfaces. Where they differ, the difference is a deliberate planning decision — a minimum batch, a set-up economy, a partial release — and the line records what was decided rather than only what resulted.

The date pair is more consequential, because it is the one a customer feels. A required date is an input; a promise date is a commitment. Section 6.1 argues that the distance between them, aggregated, is a better health measure for a pipeline than on-time delivery against the promise — which measures only whether the plant kept a promise it set itself.

3.3What an order line resolves to

An order line is not always a quantity of an interchangeable item. In the captured deployment — a uniform manufacturer — an invoice line expands to the individual recipients it will be worn by, each with a size and a quantity, so a line for three units resolves to three named people.

This is worth stating because it is the kind of requirement a horizontal ERP handles by adding a free-text field. A per-recipient sub-line is a structural feature: it must survive from order through production sheet to invoice, and it must aggregate correctly to the line total at every gate.

4.1The conservation identity

Let the gates be indexed i = 1..k, with n(i) orders cleared at gate i and w(i) orders pending there, and n(0) the count that entered the pipeline.

The identity is verifiable against the captured dashboard. With 1,087 orders raised: 931 + 156 = 1,087 at the first gate, 771 + 160 = 931 at the second, 520 + 251 = 771 at the third, and 479 + 41 = 520 at the fourth. Four independent checks, all exact.

4.2Locating the constraint

Given conservation, the constraint is the gate accumulating the most work. It requires no cycle-time study, no capacity model and no additional instrumentation — only the counts already displayed.

Applying this to the captured position gives stage losses of 14.3%, 17.2%, 32.7% and 7.9%. The third gate — delivery — holds 251 orders, more than the other three gates combined hold, and loses nearly a third of what reaches it.

That result is worth pausing on, because it is not where a manufacturer looks. The instinct is that a factory's constraint is production. Here production clears 82.8% of what it receives while delivery clears 67.3%, and any capacity added upstream would simply enlarge the queue at the gate that is actually binding.

End-to-end conversion is the product of the four stage conversions: 0.857 x 0.828 x 0.673 x 0.921 = 0.441. Fewer than half the orders raised have reached an invoice, and the single gate responsible for most of that is the third.

4.3From a pending count to days of delay

A pending count is not the unit anyone experiences. A customer experiences days, a promise date is set in days, and a plant manager decides in days. Little's Law converts one into the other.

The separation is the same one that governs response and repair in incident systems: queueing delay is a capacity and sequencing property, service time is a technical one. A gate with a large queue and a short service time needs throughput; a gate with a short queue and a long service time needs the work itself to be faster.

The dashboard supplies the numerator directly. The denominator requires clearance to be counted over a period, which the same document history already holds — so the conversion needs no new data capture, only a query over dates the system stores.

4.4Where the pipeline actually ends

The dashboard's last gate is the invoice. The business's last gate is the receipt of cash, and between them sits the payment term carried on the sales order header.

This changes what the dashboard means. If the operational pipeline runs to a few weeks and the payment term adds fifteen, then the gates the system reports are a minority of the cycle that consumes working capital — and an improvement programme aimed only at them is optimising the smaller half.

4.5The arithmetic a monetary pipeline requires

Every gate in the pipeline carries money — a line extension, a discount, a tax amount, a total. These are not measurements with tolerances; they are exact quantities in a currency's minor unit, and they must reconcile between a line, a document total and a ledger entry.

The requirement is stricter than rounding at display time. A tax amount held as a binary double and rounded only for presentation will differ from the same amount recomputed downstream, and the two will reconcile in most cases and not in some — which is the worst possible failure mode, because it surfaces during an audit rather than during testing.

The rule that follows is simple and worth stating as a requirement for any system of this class: monetary values are stored in exact decimal or in integer minor units, rounded once at the point of computation against the ISO 4217 exponent, and never held in a binary floating-point type at any stage between the order line and the ledger.

5.1Observed properties of the software

None of these is a performance claim. They are structural facts about what the software models, and they are the facts a buyer needs before any benefit statement means anything.

5.2Figures published for this module

The product's material publishes one timing figure: most implementations complete in twelve to twenty weeks for core production planning, bill of materials, routing and sales-order modules, with integration to external systems adding four to eight weeks depending on complexity.

That is a vendor-reported range with no sample attached, and this paper does not upgrade it. Its usefulness is comparative rather than absolute: the fourteen-month implementation the same material uses as its foil is roughly three times the upper end of the range, and the difference in order of magnitude is the claim being made.

5.3A deployment in which this module was one of four

A Tier-1 automotive supplier deployed four MileSoft modules together across two plants. This module served as the system of record behind the line — production planning, sales orders, invoicing and production sheets — while the other three captured the high-resolution production data it does not attempt to capture itself.

The programme reported a phased rollout of eight weeks at the first plant and six at the second, the compression attributed to lessons carried across.

What can be said specifically is architectural: the deployment is an instance of the boundary Section 2.2 describes, with the ERP holding the commercial and planning record and level 3 systems holding the fastening events, the downtime events and the material genealogy. It is evidence that the boundary is workable, not evidence of what the ERP alone delivers.

5.4Modelled effort avoided

The published return model for this product is stated as manual data entry and reporting eliminated. Its assumptions are printed here so a reader can substitute their own.

The 55% is an assumption and the parameter to interrogate. What the model represents well is that the effort removed is re-keying between documents — the same order retyped at each gate — which is precisely what the identity chain of Section 3.1 eliminates by construction. What it represents poorly is the offsetting effort a new system creates: master data maintenance, exception handling and the reconciliation that follows any integration.

6.1On-time delivery measures the wrong promise

Almost every manufacturer reports on-time delivery against the promise date, and almost every one of them scores well on it. The reason is that the promise date is set by the plant.

The order line carries both dates, so the honest measure is available: the gap between the date the customer required and the date the plant committed to, aggregated across orders. A plant meeting 98% of its own promises while promising two weeks later than asked has a customer problem that its dashboard reports as success.

This is the same structural point as Section 4.4. Both are cases of a boundary drawn where the data is convenient rather than where the question is — and in both cases the system already holds what is needed to draw it correctly.

6.2Monetary integrity is not a rounding preference

Section 4.5 states the exact-decimal requirement as arithmetic. It is worth saying why it belongs in a paper about pipelines rather than in an implementation note.

A conserved pipeline makes a promise: that the same order is the same object at every gate. Monetary amounts are part of that object. If a tax amount computed at the order line differs in the fifteenth decimal place from the same amount recomputed at the invoice, then the two documents describe different objects, and the conservation the whole measurement rests on is true of counts but not of values.

The failure is silent by construction. Binary floating point represents most two-decimal values inexactly, so comparisons succeed by luck and fail by luck, and a reconciliation that passes in testing can fail on a production dataset with no code change between them. The fix is architectural rather than defensive: hold monetary values as integer minor units or exact decimals throughout, round once at computation against the ISO 4217 exponent, and never compare monetary values for equality after a floating-point round trip.

6.3A capability reference framework for manufacturing ERP

6.4Generalisability

The conserved-cascade model generalises to any staged process with a fixed sequence and no mid-pipeline entry: claims handling, recruitment, permitting, clinical pathways. The constraint-location result generalises with it, and is at its most useful precisely where intuition points elsewhere.

Two things do not generalise. The captured gate counts are one deployment at one instant, and Section 7 explains why a single observation identifies a candidate constraint rather than proving one. And the payment term is a commercial fact of one customer relationship, not a property of the software.

Appendix B.1Reading the constraint out of five numbers

A pipeline reports 1,087 orders raised and four gates with cleared counts 931, 771, 520 and 479.

Pending counts follow by Equation (conserve): 1,087 — 931 = 156, 931 — 771 = 160, 771 — 520 = 251, 520 — 479 = 41. Stage conversions are 0.857, 0.828, 0.673 and 0.921; stage losses 14.3%, 17.2%, 32.7% and 7.9%.

By Equation (constraint) the constraint is the third gate, holding 251 orders — more than the 156, 160 and 41 at the other three combined. End-to-end conversion is 0.857 x 0.828 x 0.673 x 0.921 = 0.441.

Appendix B.2The same pipeline in days

Suppose the four gates clear 62, 51, 26 and 48 orders per working day, measured over a stable month, with service times of 0.5, 2.0, 0.5 and 0.2 days.

Applying Equation (flowtime): W1 = 156 / 62 = 2.5 days, W2 = 160 / 51 = 3.1, W3 = 251 / 26 = 9.7, W4 = 41 / 48 = 0.9. Queueing delay totals 16.2 days; service time totals 3.2; total pipeline time is 19.4 days.

The decomposition changes the diagnosis. Gate 2 has the longest service time at 2.0 days — it is the real manufacturing work — but contributes only 3.1 days of waiting. Gate 3 does almost nothing to an order and makes it wait 9.7 days, which is half the pipeline. One of these is a technical problem and the other is a sequencing and capacity problem, and only the decomposition tells them apart.

By Equation (cash), with an average payment term of 105 days, order-to-cash is 124.4 days. The nineteen operational days the dashboard reports are 16% of it.

Appendix B.3Why the arithmetic has to be exact

An invoice line carries quantity 3 at 53.00 per unit, giving 159.00, with tax at 5%. In a currency with a minor-unit exponent of 2, Equation (money) gives a tax amount of 7.95 and a net of 166.95.

Computed in binary double precision, 159.00 x 0.05 is not 7.95. The nearest representable double is 7.9499999999999992894572642398998, and the net is 166.94999999999998863131622783840. Rounded for display both look correct.

The failure appears at reconciliation. Sum a hundred such lines and the accumulated error can exceed half a minor unit, so the stored document total and the sum of the stored line amounts differ by a cent — and the two disagree exactly when a ledger, an auditor or a tax authority compares them. Computing in integer minor units — 15,900 x 5 / 100 = 795 — makes the identity exact by construction, and no rounding policy is required at any later stage.