How Much Does Yesterday Cost?

Typical sales compensation schemes have a lower limit, a minimum sell price (or margin percentage) below which the sales representative will not earn a commission. This makes obvious good sense: if the company is not going to earn a profit from the sale, the sales agent shouldn’t either.

It’s also common that businesses sometimes need to waive this common-sense requirement. When a sale represents a first break at a coveted major buyer, when a sale is expected to lead to additional purchases or service work or other additional revenue, it can make better sense to take the initial sale at lower than usual profit – sometimes even at a loss – in view of the longer-term payback.

Both of these expectations ought to incorporate delivery schedules. No company is in the business of delivering products before they are ordered (but nice try, Amazon); most business-to-business (B2B) companies with a sales force that receives commission cannot offer instant delivery. Usually if a sales rep makes a commission in a B2B context, the product must either be configured or selected from a complex range of options that require specialized knowledge to make a good choice.

In other words, the sales rep needs to know the product.

Expanding on that, the sales rep needs to know the capabilities of the product and of the company – how they support the product in terms of training, warranty service, spare parts availability, and whatever else goes along with that particular product’s complexity that justifies paying a sales rep.

Barring exceptional and pre-approved circumstances, a sales rep who sells a product at no profit has done a disservice to the company, neglecting his duty, and does not deserve to be paid.

A sales rep who sells a product requiring faster-than-usual delivery has also done a disservice to the company and does not deserve to be paid—again, except in pre-approved situations. I would argue that it is actually worse than selling below cost.

Selling below normal margins has an obvious, easily countable cost; fewer dollars come in. The number is right there in black and white.

Rushing an orders sets off a chain reaction of costs, most of which are not measureable or are not clearly attributable directly to that one order. Rush orders usually first affect the salaried staff, whose pay is rolled into the overall operating overhead of a company. Depending on the business and the size of the rushed order, responding to a rush order can take up time from the highest-paid people in the company. Again: sometimes this is the right course of action. But the endorphin rush of responding to an “emergency” makes it all too easy for business managers to forget that the best use of their time is planning the company’s future. Any time an upper-level manager gets involved in the present, it is a signal that the day-to-day processes of the company are not meeting the needs of the business; it is the managerial equivalent of a machine break-down.

Managers rushing around saving the day inevitably impacts the workers, too, who must halt their usual practice (ideally following a reliably excellent process) to accommodate the boss’ special request. This might immediately lead to overtime and measurable, attributable costs incurred. But more of the cost is likely to hide in the shadows: skipping inspection or maintenance or documentation, something where the cost of the sacrifice won’t be felt immediately, and won’t even matter if the skipped step is skipped just this once.

It is never just this once.

Once the sales rep has learned that he can delight his customer with the exceptional performance, he’ll ask for it again – he’ll need it again. Once managers learn that they feel like heroes when they orchestrate the impossible, they’ll want to do it again. And once production workers learn they can skip a step without noticeable repercussions, they’ll do it whenever they need to.

A rush order is not really like a house on fire, despite the frequent reference to “putting out fires.” A house fire is catastrophic; nobody just “gets used to it.” A rush order is more like a small stone hitting your windshield. Nobody dies. Maybe it makes a small chip or crack. Maybe it doesn’t even make a mark! But if it happens all the time, you will lose that entire windshield. So how often is too often?

Generally a business won’t improve until its customers demand it. Prices don’t fall unless sales are slipping. Quality doesn’t improve unless orders are lost. The wake-up call that faster delivery times are needed will generally come in the form of these rush orders, these expedites that shake the tree from bottom to top.

Managers must recognize that an expedite is the operating failure of the machinery they are responsible to keep running.

Sales reps must recognize that an expedite is never free.

Rushing to Fail (Part IV)

(This is the fourth post in a series; see earlier posts I, II and III)

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):

  1. Requested date, when the customer asked for it;
  2. Promise date, when the factory currently expects to be able to provide it;
  3. 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:

  1. 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.
  2. 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.
  3. 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.



For Want of a Nail (Part III)

(This is the third part in a series; see Part I , Part II and Part IV)

In the previous installment we saw how neither the human operators nor the computerized information system had a clear, timely understanding of what inventory was meant to be in a specific location or reserved for a specific purpose. The material handling processes in place did not conform to the principle of visual control (“mieruka”). Although the system was intended as a form of kanban, it did not conform to the principles of kanban because the role of the spare parts pickers had not been considered, and there was no visual feedback for them. This could also be considered a lack of mistake-proofing (“poka-yoke”), and potentially a lack of “5s”, specifically Sort and Set In Order, again from the perspective of the spare parts picker who had no means to distinguish parts available for shipment and parts reserved for production. It also should be considered a dangerously incomplete IT systems implementation of a process, but a reliance on IT systems to “make things work” is itself not understanding the principle or benefit of visual control.

Today’s episode has to do mainly with leveling (“heijunka”). Leveling is always a sore point in implementing a Toyota Production System based process because it is in direct tension with the principle of responding to customer demand. There isn’t any case where customer demand is level and unwavering; even for oxygen, although we are always breathing, as we need more oxygen when active or excited than when resting.

But leveling is fundamental to quality, or more specifically to being able to observe whether results are in line with expectations. If you expect your production line to produce 100 units every day, all of the workers should be working at the same pace every day, and you should minimized if not eliminate mistakes caused by rushing. Further, without having a standard pace for the entire process, it is all but certain that some parts of the process will be able to operate faster than others, and the faster steps will accumulate work in process behind the slower processes. The extra inventory allows the faster process to “hide” errors by recovering while the slower process catches up, a short-term success that obscures the potential for small problems to grow into big ones.

In this particular factory, leveling production was made difficult by the large number of different end products, some of which had constant demand (although varying in total volume) and others with only occasional demand. If the occasional-demand items would politely take turns the production could be leveled and still tied directly to demand, but of course this serendipity was not reliably present.

So the basic system for moving components from storage to the production line relied upon a crew of material handlers to monitor several assembly lines and restock all of them as needed. Most materials we provided via a “two-bin” system: in concept, you start with two full bins. When the first is empty, it is taken away and refilled before the second is used up. (Sometimes more than just two bins are used.) Because the bin quantities were not all aligned to have enough parts for the same number of finished products, and because some parts were used in common across several end products (but other components were not), the rate at which parts would need to be replenished was not reliable. A change-over from assembling one product to another would mean refilling many bins simultaneously; if several lines needed to change over at around the same time, work might back up considerably.

Further, since production lines might build a number of different products and not all were built equally quickly, and not all lines were always producing, there was drastic variation in the level of support needed from material handlers. At the end of the month, and especially at the end of the quarter, pressure to build as much as possible went up sharply.

To compensate for the changing work load on the material handlers, the more senior members of the assembly team were also authorized to retrieve components from storage. When the urgency to maximize production was greatest, production planners (typically responsible for balancing available component parts with current final product demand, a desk-based job) would assist in moving components to the line so that none of the potential builders would lose time moving parts.

The production people were trained, expected, and performance measured in terms of production of complete products. Precision in counting and handling component parts was not part of how their success was evaluated in any direct way.

When parts arrived at the last minute, material handlers (full time or temporary fill-ins) would retrieve the parts directly from the receiving dock, before they had been counted, quality checked, or received into the system at all. Combined with the other uncertainties afforded by the process, the question of how much of an item was available and where it was stored was always unclear.

Several component parts were springs, or spring-like items, which could easily become entangled with one another. These parts, and all small, lightweight parts, were shipped in bags or boxes. Taking parts out of storage, or out of a bin during the assembly process, is very likely to involve pulling out more parts than desired; disentangling was not a straightforward process, and it could be expected that one or more parts could drop off, roll, or bounce into places unknown. These were always small, cheap parts; when pressure was on to build, build, build, it hardly seemed worthwhile to spend time chasing runaway parts. There’s always tons more in the bin.

Ultimately it was not clear how often dropped parts caused shortages versus parts not ever being shipped. Most small, light parts were shipped loose packed in bags or boxes and the count of pieces in each bag or box could vary. The suppliers would write on the box the count, but there was no routine verification by weight. Checking by weight as parts were removed was complicated by the light weight of the parts; they weighed little enough that plastic or cardboard would count as significant number of parts.

It would be relatively straightforward to establish the weight of the parts, establish a minimum stock by weight, and write off the continual shrinkage due to dropped parts or undetectable short shipment. But the parts were bought and tracked by each, and the each-count was always off, and so production was halted for small, cheap parts as often as it was for large expensive parts.

Better than allowing dropped parts and potentially short shipments would be designing purpose-built containers using rods or grooves to keep parts in a consistent orientation, clearly marked with a weight corresponding to an exact count. While it would require a modest investment to design and produce the specialized containers, and possibly working with the supplier to help establish a reliable process to transition the parts from their production equipment to the containers, the payback in reduced uncertainty would have paid back such costs.

For want of a nail, the shoe was lost;
For want of the shoe, the horse was lost;
For want of the horse, the rider was lost;
For want of the rider, the battle was lost;
For want of the battle, the kingdom was lost;
And all from the want of a horseshoe nail.


Ordinary Challenges for On Time Delivery (Part I)

This is the first part in a multi-part series about on-time delivery. If you are familiar with manufacturing (light machining and assembly), all the topics in this post will seem quite mundane. But they deserve to be mentioned because ordinary problems with ordinary solutions can still be part of the chaos even when there are some special causes. Part II describes the inventory chaos resulting from using visual control systems inconsistently across overlapping processes. Part III describes how lack of work leveling leads to inconsistent responsibilities and lack of accountability. Part IV describes how an emphasis on metrics rather than fundamental customer relationships, and on immediate results rather than process capability, skewed efforts to improve.

I spent a significant amount of time trying to help one company improve its on-time delivery.  My primary responsibility was to identify causes for late deliveries. Some of the causes were pretty straightforward:

  • Inventory inaccuracy resulting in component shortage
  • Quality non-conformance requires rework or scrapping part
  • Traffic jams in production processes
  • Supplier late delivering to factory

Since the nature of these problems was pretty ordinary, possible improvements are also not hard to imagine. Inventory accuracy could be greatly improved by locking up inventory and restricting access to authorized personnel who are trained and held accountable to always update the system on how much inventory was released and for what purpose. Although there was a fairly limited number of people who were “usually” responsible for transferring inventory from storage to point of use, there was quite a large set of people who might do it to help out – on second or third shift, when many assembly lines all needed replenishment at the same time, or for any number of other real or imagined reasons. Consequences of restricting access might include delaying some assembly lines if the demand for parts at a given point in time were too great for the authorized staff to handle, or paying authorized staff to stand around and do nothing during periods when demand for materials were lower than peak.

There were also a surprising number of cases where inventory accuracy was hampered by material packaging and presentation deficiencies: pieces dumped in bulk into plastic bags with no clear indication of count, or a count indicated but no corresponding weight with which to check the count. Some parts were packed in bulk even though they were highly prone to hooking and catching on one another, making it quite easy to take more than needed and drop some during handling. More often than not, it was difficult or impossible to tell how many parts were supposed to be in a container at any point in time. Imposing packaging requirements would likely result in an increased component cost.

Quality issues for parts produced in house were, like most quality issues, the result of process variation. Contributing causes might include the condition of the tools or fixtures, contamination of fluids, or unfinished components not to specification. Standard practices for quality control were known and discussed, but the recurrence of issues is a telling indication that corrective actions did not reach to actual root causes. Symptoms of not addressing the root cause include if the corrective action involves rebuking an individual, increasing manual inspections with the addition or alteration of inspection methods or tools, or other changes which would cause the process to take longer and must be done by the worker (not automated equipment) without any change to the way the worker’s performance is measured or evaluated by their immediate supervisor. In other words, instructing the worker to get the same amount of production but follow steps that take longer to do.

Traffic jams occur when the cascading effect of a problem affects later jobs which themselves have no problem, but are started late and finish late due to the problems on other jobs.

Supplier issues, whether late delivery or poor quality, generally have the same types of causes and possible solutions. Much as with internal employees, the main thing that matters in the long run is how suppliers are held accountable. Informing suppliers that you are displeased will have little result if there are not increasing consequences, starting with charges for nonconforming material and ending with discontinuation of the business. Dropping a supplier for quality or on time delivery issues can result in higher costs for buying from higher performing suppliers.