Three layers, and what each one is for

The situation

The owner of Sumilon has read the quotation and has one question: "We already have a system that knows the order. What is this second one for?"

It is the right question. Rowena's first answer, "it gives us live production data", is the wrong one. That answer gets a factory a very expensive chart.

Three layers, and the boundary between them

The boundary in the last column is the useful part. A planning system that tries to hold bundles becomes unusable within a season. The number of rows explodes, and none of them survive a re-cut. An execution layer that tries to hold prices becomes a second, worse accounting system. The two are separate because their rates of change are separate. An order changes a few times. A bundle's state changes every few minutes.

An execution layer is a scheduling system that happens to keep records

This is the correction the course exists to make. The verbs of a shop-floor execution layer, in the order they matter, are:

1. Schedule — put the work orders in a sequence against the resources that exist.
2. Dispatch — tell a specific line, machine or operator which bundle is next.
3. Execute — hold the routing, so the system knows operation 40 comes before operation 52 and refuses a completion that arrives out of order.
4. Track — know where every bundle is.
5. Collect — record what happened.

Reporting is not on that list. Reporting is what course 24.3 does with the records that collection leaves behind. A factory that buys an execution layer in order to get charts has bought a scheduling engine. It has paid a scheduling engine's price for a counter.

That is exactly what Sumilon did. FL-318's routing carries 18 operations. In the first season the factory used completion recording on 3 of them: the two cycle-counted sewing operations and the final audit. It used the dispatch function on none at all. Bundles went down the line the way they always had, with a supervisor, a clipboard, and a judgement about which operator was free.

The part they paid for and did not use turned out to be the part that paid

Here is the turn, and it is worth sitting with.

To make the system accept a completion at all, somebody had to type FL-318's routing in. That is 18 operations, each with its standard minute, its machine class and the operation that comes before it. Jonalyn Amistoso did it over two afternoons in February. She complained about it, correctly, as data entry the factory did not need.

That routing is the reason lesson 6's line-balance finding was possible. Cycle counts on their own tell you a machine is busy. Cycle counts read against a routing tell you which operation is the constraint and which has slack, because the system knows what each operation is supposed to take and what comes after it. The finding was worth USD 50,438 a year, and the data it ran on was entered for a reason nobody believed in.

The general shape is this. Reporting is the cheap part of an execution layer. The scheduling model is the expensive part, and the scheduling model is where the value is. A factory that will not maintain a routing should not buy an execution layer at all. It should buy counters, which are much cheaper and honest about what they are.

What the programme cost, and where the money sat

Every figure in that table is this factory's own quotation, for one fleet in one country in one year. It is here so that the shape of the spend can be argued about: which lines are large, which are small, which are wrong. It is not a price list. Nothing in it should be carried into your own negotiation as a rate.

Read the shape rather than the numbers. The software is the largest line and the one everybody negotiates. The integration to the planning system is 9.2% of the total, and it is the one nobody looks at.

Lesson 5 is about what that line actually cost: USD 134,900, which is 41.0% of a programme that finished at USD 329,014. The line everybody negotiated was quoted correctly. The line nobody read was wrong by a factor of nearly seven.