Here we come to the most significant chapter of the saga.
The MRP system in place at the company at that time tracked three dates for a given order (more precisely, for a line on the order):
- Requested date, when the customer asked for it;
- Promise date, when the factory currently expects to be able to provide it;
- Due date, the date by which the work should be done inside the factory, used to sequence all of the factory work.
Due date is not necessarily the same as the promise date. First, if the factory was running behind overall, due dates could be missed. You wouldn’t want to move only one due date for one order into the future, because it would lose its place in line versus all of the other past-due orders. Also, depending on how the entire system is set up, the production control system that coordinates by due date might not include activities after assembly (transfer to shipping, pack for shipping, consolidate with other items on order, etc.), and in fact in this case the system did not track specific activities for shipping. So a one or two day gap between due date and promise date would allow time for shipping activities, or might be used to provide a small buffer in case of minor delays.
Promise date is not always the same as requested date, because customers can request things faster than they can be built – because of how much they want, or because of a long lead time to get a special component, or because the factory overall is already busy.
Given these three different dates, and the fact that all of them can be changed, what does it mean to be “on-time”?
Customer Request Date would make the most sense. But customers can ask for unreasonable things – they can ask for giant orders of specialized product to be delivered the next day. Orders came in by many means – by fax, by phone, or through an early use of the Internet called Electronic Data Interchange (EDI). Not all of those methods reliably required the customer to specify a request date; if no value was provided, the system defaulted to next-day.
So a significant portion of the request dates were quite out of reach.
Using Promise Date is no good because the promise date can be changed by the factory, so being “on-time” to promise date is a simple matter of updating the field before shipping. Promise date needs to be changeable by the factory so that an indication of what is expected to happen can be provided, but measuring that will only measure how reliably people can change the promise before delivering on it.
Therefore a modification to the system was ordered which stored the first promise date given, the Original Promise Date.
But it turns out that the factory more or less controls the generation of the first promise, as well, so before too long the Original Promise Dates were soaring out into the future, and the factory’s performance to Original Promise Date was improving.
What to do? Well, no problem in people management can be solved by measurement alone. But it’s pretty obvious that the right thing to do in this case would have been to accurately capture what the customer actually wants – the customer being the person willing to pay for what you can provide.
This factory with the on-time delivery problem was not a pizza factory. If someone called asking for pizza, that person would not be a customer. It was not a space ship factory, and if someone called asking for a space ship they would not be a customer. It was also not in the business of providing most products to most customers on a next-day basis, and so most people requesting that would not be asking for what the factory could provide; they would not be customers.
The basic steps toward measuring on-time delivery include knowing what “on-time” means, which means understanding what the customers you can reasonably serve are willing to pay for. That implies two basic points, and a third point follows along:
- Customer request date must be provided. It could be provided once and applied to an entire order, or provided for each line on the order, or the order could be held as “pending” until a customer service agent could follow up and obtain the information. There would be some expense to make the changes to the system. There would need to be some conversations with customers in the habit of getting next-day shipment at no extra charge, when available, merely by lazily doing nothing, that they now have to ask for what they want.
- For most customers in most cases, request dates that would be moderately challenging should require an added expedite fee. If the customer is not willing to pay for the service of quick shipment, they are not a quick shipment customer.
- If you charge extra for what your competitors provide for free, you will lose business. For important deals where an expedite fee would lose the business but it might be possible to provide the order in time, it may be appropriate to waive the fee. This would require diligent investigation on the part of the sales representative regarding what the customer actually wants, and equally diligent investigation as to exactly what the factory is currently able to provide. While this extra effort might seem unwelcome, it should be better for all parties than conversations about why delivery is late – and the intolerable frequency of those conversations was the basis for the whole improvement effort in the first place.
The best situation of all is, of course, to provide what the customer wants instantaneously, at no extra charge. But it is better to only promise what you can actually deliver than to take money for a service (fast shipment) that you cannot provide.
The growing power of Amazon compels a bit further discussion. Amazon got where it is today partly by providing lower prices than its competitors, including delivery. Amazon delivers faster than others, and often for free, and their prices are lower. Many of Amazon’s competitors figured they were not able to do this without losing money. As far as I know, Amazon’s never solidly disproven this suspicion; for years they’ve been so busy spending money growing it’s never entirely certain they’re making profit on their core distribution business. They’ve also muddied the water with the Prime membership program and it’s interestingly flexible definition of two-day shipping, and the possibility of quietly boosting prices for complacent, regular shoppers (hard to prove without having account access to a large sample of customers).
But how Amazon did it is largely irrelevant. If you are certain they subsidized money-losing shipping with investor cash and growth-hype marketing, go do the same. If you think they hide their shipping costs in a membership program, go do the same. Advertising “free shipping” when the shipping cost is baked into the prices is a well-known marketing ploy, and at this point convincing investors to pour money into a unprofitable but growing business is also well-known. In the end, whether the money is coming from end-user customers or investor customers, someone is paying; and whether you are providing actual shipment of widgets or dreams of getting rich off of a unicorn stock, something is being provided.
So, to insist: customers pay for what you provide. If they don’t pay or you don’t provide it’s not a lasting business.
The possibility of considering investors as customers leads us to another interesting wrinkle. It turns out that investors are the customers of every publicly-traded company. (What follows is just a quick review of the classic agency problem; skip five paragraphs to “From the lofty heights” if you don’t need it.)
The investors are represented by the Board of Directors. Directors can be replaced by a sufficiently large contingent of shareholders (investors). To keep their jobs, directors try to keep investors happy.
Directors must approve the compensation plan for the top management. They do whatever they can think of to ensure that the top management will take actions that make the shareholding investors happy.
Shareholders of any size can easily sell stock on any given day. Sell Company A, buy Company B. In general, then, shareholders have no reason to want Company A to do well over the long term. As long as the share price for Company A has increased enough to pay off any costs associated with buying and selling the stock, big share holders always can (and, in a sense, “should”) dump the stock for a better offer at any time.
So investors always want to know that, compared to other stocks with a comparable risk of losing value, the stock of Company A is doing really well right now.
That’s why publicly traded companies tend to want to have really swell results every month, and especially every quarter and at the end of every year. Most businesses have natural ups and downs; ice cream sells better in the summer than in the winter. Peppermint candy sells better for Christmas than for Independence Day. But publicly traded companies do whatever they can to overcome the natural ups and downs of their business, because if they aren’t doing great right now they might get dumped for some other company that’s doing a little better.
From the lofty heights of the stock market this looks like a jolly little beauty pageant. From the ground floor of a factory, it looks like deciding to ship the newer order for plain vanilla ice cream before the older order for vanilla ice cream with organic Oolong tea leaves sourced exclusively from certified fair-trade villagers in Nepal, because the donkey is lame in Nepal and the tea leaves are late and we can ship the plain vanilla order this month, making the profits in this month a little bit better. We could ship the older order for the organic Oolong vanilla two days from now when the tea leaves get in, and if we ship the plain vanilla now we will be out of vanilla for three weeks, making the Oolong order even later. Too bad; that “customer” will just have to wait, because the real customers are the investors and they want to see good profits this month.
In short, resources get borrowed from an older order that can’t ship in order to fill a newer order that can ship. There are many possible reasons why an order might be hard to ship – it requires special components, the customer wants the entire order to ship complete and other items on the order are late, the customer hasn’t passed the credit check, and more.
Clearly this violates the principle of first in, first out (FIFO), or in Toyota Production System terms, continuous flow. It also probably irritates you on general principle; nobody instinctively likes how it sounds. But, as they say, nobody wants to know how the sausage is made; but that doesn’t stop them from eating it. Very likely you will find some practices that make you irritated or uncomfortable behind every nice thing, particularly the nice things that seem remarkably cheap, remarkably convenient, or otherwise mysteriously available to you without any particular effort that you know about.
Let’s ignore the irritation factor. The problem with this scenario goes deeper than just making the organic Oolong vanilla customer wait longer than necessary. This kind of out-of-sequence activity causes rippling chaos that spreads far beyond the visible consequences when the decision was first made. Every part of the production process is designed to work in a basically first-in, first-out way; even if it hasn’t been adopted as part of imitating the Toyota Production System, than at least because it is awfully hard to build the order for five years from now since you don’t know what they are. At some level, you add things to your production plan as you become aware that they are wanted.
In our entirely made-up example of the organic Oolong tea vanilla, perhaps the tea leaves need to ferment, and they were planned to ferment next week when the tea leaves came in; but they can’t be fermented too long before being used, so if we aren’t making the Oolong vanilla until three weeks further out we’ll need to delay fermenting the tea leaves. But that will cause a conflict with fermenting the mint leaves for the mint that was supposed to run that week, so now we have to move that. And then we’ll have to reschedule the chocolate for the mint chocolate, and that will affect the schedule for the chocolate in the chocolate peanut butter; and so on.
It is of course possible to deal with these kinds of disruptions, because they happen whether you deliberately cause them or not. But it should be readily apparent that there is a difference between dealing with problems you tried to prevent versus deliberately causing yourself those problems. Dealing with one specific chain of events is not too daunting, but when the problems occur on multiple components for multiple products on multiple orders over many weeks, and the problems can affect each other, the consequences multiply. It’s not eight plus eight, it’s eight times eight.
The Toyota Production System principle of flow is meant, in part, to reduce those self-inflicted complications. Going from eight root-cause problems (eight times eight, 64) to seven root cause problems (seven times seven, 49) reduces your total problems by 15. Reality is more complex than that simple math, in good was as well as in bad ways, but the principle holds: problems multiply, and keeping things as steady and predictable as you can will make it much, much easier for to work on your real problems without being distracted by all the consequences of problems you caused for yourself.
The crowning irony for this particular company’s efforts to improve on-time delivery was the decision that had been made some time prior to designate certain customers as so important to the business that their orders would ship ahead of all others. Because these were by nature customers representing a significant portion of the total business, their orders tended to affect most of the products. If a particular product was running past-due and a production schedule drawn up to get the oldest orders down from two weeks old to two days old, and then just as the products went to shipping a priority customer order came in, that priority order might use up all of the product. The order could come in and ship out in less than a day, leaving everyone confounded who thought that the old orders would be caught up (the customers themselves, the customers service agents talking to the customers, the factory production planners, etc.).
The priority customers were also fairly likely to be major distributors who carried significant inventory of their own and might not need the product nearly as urgently as the smaller customers with older orders.
As already mentioned, production control software is designed to plan to build things basically in the order they were requested. Typical production software is designed to plan to produce in the future, not to explain why production ran a certain way in the past, so it was not particularly easy to tell why the product meant to ship on old orders somehow disappeared without clearing up the old orders.
And if the product was one model in a family with shared components, and a second production run was made after the first disappeared to really clear up the old orders, that might use up shared components meant for other orders. Again, the problem spreads in a ripple.
All of the issues discussed in this article are some form of rushing: accepting a next-day shipping “request” without checking to see if it is paying business; shipping out of sequence to boost end-of-period revenue; or shipping out of sequence to flatter a key customer (rather than investing in improving basic ability to ship to all customers faster). Although not possible to get an accurate measure on how big the ultimate impact of these rushing efforts were on overall on-time delivery (because production computer system plan future production action, not explain past production action), the principle of problems multiplying and the demonstrated success of the Toyota Production System (and similar philosophies, when rigorously followed) give a pretty good indication that the self-inflicted injuries were severe enough to justify stopping those practices.
Ultimately, to achieve on-time delivery, it is important to stop rushing.