Lesson 3: Elephant orders and freak orders

The elephant

A maker of hand tools sells mostly in small orders: 100 to 500 dozen of a file, with a production buffer of 12 days. Its constraint makes about 1,000 dozen a day. Then the export team lands a big one: 10,000 dozen of a single item.

Released as one order with the usual 12-day buffer, it does predictable damage. Work in process jumps. The big order can’t finish in time, because it alone needs ten days of the constraint. And while it sits at the constraint, every small order behind it waits: they go red, then black, in a cascade that lasts long after the elephant has left.

The obvious answer is to give the big order a bigger buffer. The planners resisted, and they had a point.

Ten thousand dozen become ten orders of a thousand, each released with the 12-day buffer, one a day. Each lot’s touch time is small again; the colours mean what they always meant; and the customer can be told the date of the last lot, or take deliveries as they come.

Giving each lot a full day of the constraint is the fastest way to finish the elephant, and for those ten days it takes all of the constraint. If smaller orders must keep moving, give the elephant only part of each day. The order finishes later, but nobody else goes black.

The freak

A maker of storage systems had two kinds of work. High-volume, standard parts were made inside, with a production buffer of about three days that covered most orders. Low-volume, special parts went to subcontractors and took two or three weeks. After two months of DBR, the inside operation was close to stable.

Then one order of 2,000 beams with a Z-shaped profile reached the paint line. Painting a Z-beam needs a slower gun speed to coat properly. The line, which handled about 2,600 beams a day, dropped to about 600.

The welding shop, the constraint, was releasing about 2,000 beams a day, and the paint line had about 30% protective capacity. The arithmetic of the cascade is short:

The Z-beams take about 3.3 days of paint.
Meanwhile about 6,600 regular beams pile up in front of it.
With 30% protective capacity, the paint line clears only about 600 extra beams a day, so the queue takes about 11 more days to clear.

One order upset the plant for about two weeks.

Pause and think: the plant’s buffers were well sized for its normal orders. What went wrong?

The buffers were too short for the plant, and should have been doubled for every order
This order’s content didn’t fit the assumptions behind the standard buffer
The paint line had no protective capacity at all, and needed a second line

When buffers are designed, the majority of orders are considered. An order whose touch time at one resource is far outside the normal range is not noise; it changes the load on that resource. Before TOC, manual priorities and early release hid such orders. With a choked release, they show.

What to do with freaks

Two options were discussed for the Z-beams:

A bigger buffer: release them earlier with a 7-day buffer (2 days through the constraint plus 5 to paint), and limit them to a third of each paint row, so that two thirds keep carrying regular beams.
Split and stagger by the paint line’s output: this keeps the queue small but adds set-ups. Each change costs about 2.5 hours at the constraint, where no improvement had yet been done.

Either can work. What matters more is not to meet the next freak by surprise. A freak order is one whose content doesn’t fit the standard buffers:

unique content, unlike the standard products;
a very large quantity (an elephant: split it);
a different flow, which moves the bottleneck of the plant for a while;
a manufacturing step the plant has never done before.

The rule is a short procedure:

Write the standard release rules (for example: large orders are split and staggered against the constraint; orders made at subcontractors and finished inside get their own buffer).
When an order doesn’t fit a rule, discuss it and give it a buffer at the time of solution mapping, the way a small project is planned.
Quote marketing the lead time and due date that follow.
Update the standard rule, so next time it is not a freak.

There are two environments in one plant: a production environment, where buffers are attached to orders by rule, and a project environment, where each order is evaluated for its content. Freak orders belong to the second.

Check your understanding

Answer all five. Get four right to complete the lesson.

1. Why does an elephant order with the normal buffer go late?

Its paperwork takes longer than for small orders
Planners give it low priority because it is a single item
Its touch time at the constraint uses most of the buffer
Export orders always go late

Ten days of constraint work inside a 12-day buffer leaves almost no protection.

2. The assumption broken by splitting the elephant is…

It must be released and processed as one order
Every order needs the same buffer
Work in process must be controlled
The constraint makes 1,000 dozen a day

Split into lots of a day’s capacity, each is a normal order with the normal buffer.

3. Giving the elephant 100% of the constraint each day…

Is always the best choice, because it finishes the order earliest
Is forbidden by buffer management, which only allows one order per day
Lowers the throughput of the plant
Finishes it fastest, but blocks every other order at the constraint

Giving it part of each day keeps the small orders moving.

4. One slow order at the paint line upset the plant for two weeks mainly because…

Painters refused to change the gun speed back
Its queue could be cleared only with the paint line’s small spare capacity
The constraint stopped releasing beams during those days, starving the paint line
Customers cancelled their orders

About 6,600 beams queued; at about 600 extra a day, recovery took about 11 days.

5. The lasting answer to freak orders is…

A bigger buffer for every order in the plant, so that no exception can hurt it again
Refusing orders that don’t fit
Standard rules, an agreed buffer for each exception, and an updated rule
Waiting until it goes red

Treat the exception like a small project, then make it part of the rules.