Today I developed some new reports on how accurate our ship promise dates are. I sorted the accuracy into ranges and within the ranges I created we got all the way into five days late or ten days early before 80% of the lines were accounted for.

Most of these were original system-generated promises assigned when the order was booked. But when we start manually adjusting the promise dates things don’t get too much better. Our promise dates are not very stable. Some of this is due to unforseen events such as equipment breakdown. Some of it is vendors missing their promise dates to us, which is partly the hidden cost of low cost vendors.

Some of the problems are a little less obvious. We often hear that while we were waiting for component Y to become available, customer orders depleted component X, forcing us to repromise the product even if component Y came in on the original schedule. This sounds like a moron’s problem; why not lock up all the components needed so they can’t disappear? But we only hear about the problems. We don’t hear about all the times when a customer wanted some of part X and we shipped their order and replaced the inventory before it was ever missed. So how far out do you lock up your components?

Most sensibly, within the component lead time. But our software only supports a single time window for allocation of sales orders. We could also just immediately lock up any inventory that will be needed for a planned build, but if we don’t start hearing from our customers within a week of doing that, we will be hearing from our leadership by the end of the month when they want us to turn every scrap of inventory into invoicable shipments, and worry about the damage next month.

Further degrading our promise accuracy is that we don’t really know what we can build in the first place. That is, our system doesn’t tell us that, given the supply that is past due and the supply that is on schedule, n of unit A can be built today and p of unit B can be built tomorrow. It will tell us when we owe A; separately, it will tell us what we need to build A; separately, we can look up what is going on with those parts needed; but the system does not bring all of this information together. So even assuming we had accurate dates for when our vendors would deliver loaded into the system, that information is not taken into account to delivery, systematically, a straightforward build plan.

Throw in the factor that many components are required across a number of different models, and what often happens is just simple human oversight of some complicating factor that delays the production of the item to be promised.

On this last point I just started last week researching what kind of logic the system would have to apply to bring the whole picture together. But I am already gearing up to be told by our skeleton crew of IT that such a program is too resource-intensive. I mean, looking at all the interrelated layers of supply and demand–that’s a lot to ask of a production control system, isn’t it?