← Articles

10 January 2022

Stop planning, start pulling!

Push versus pull.
Push versus pull.

In my life I have met a lot of people: some were happy with their job, others hated it. Some were very happy with their family, their car, their relationship with their partner… others less so, and some not at all.

I've noticed, however, that I have never met anybody who said:

"My ERP works really well, I'm very happy!"

When it comes to ERP, everybody complains that theirs doesn't work properly, but, they say, if they could have "another one", all their problems would disappear immediately. Those who have "the other one" complain that it is too complex to use and in the end is not exploited to its full capability, so… it doesn't work. Some orders are still delivered late and, despite hundreds of thousands of euros invested in the new MRP system, people called "expediters" spend their days pushing special orders through the plant.

Why?

The answer is very simple: ERP can never work well. Its failure is already "embedded" in the way it is built.

How do ERPs work?

ERP systems are discrete systems: they take time, divide it into discrete drawers and try to optimise activities according to certain, more or less sophisticated, parameters in order to obtain a certain result by a certain date (e.g. if I want to ship N units of product X to customer Y by date Z, when do I have to order the raw material?).

The baseline is the dependency between events or items: an operation can't start until the previous one is finished, or an assembly can't be completed if a component is missing.

On top of this relatively simple dependency rule, you can add more complex algorithms that try to improve "efficiency" as much as possible, for example reducing setup times by grouping jobs that use the same tooling.

What data do they use?

ERPs can only use the data you give them. If an operation takes an average of 60 minutes to set up and an average of 5 minutes per part, the ERP will book the machine for 60 minutes + 5 minutes × number of pieces. Say the batch is 60 pieces: the ERP will book 6 hours… plus "something".

People who studied physics always expect that, under the same conditions, the outcome of a future event will be the same as that of a similar event in the past… but people who studied statistics have learnt that whenever you try to predict something, you will always make an error.

(Did I really have to study statistics to discover that?)

So if it takes 30 minutes "on average" to get to work and I have to arrive "around" 8 a.m. (but arriving a little earlier or later is not a big problem), I leave home at 7:30.

OK.

What happens if you have a very important appointment (or simply a train to catch, which won't wait for you if you're late) and you know it takes 30 minutes "on average" to get there? Do you plan to leave exactly 30 minutes before?

Not at all! You know the average is dangerous: an average of 30 minutes means that sometimes it takes less and sometimes more, and it very rarely takes "exactly" 30 minutes. So when being on time really matters, everybody stops using the average and starts a more detailed analysis, for example considering the maximum possible time, perhaps multiplied by a correction factor above or below 1 depending on their risk appetite.

The result is that if you have to catch an 8 a.m. train and it takes "on average" 30 minutes to get to the station, you end up planning to leave at 6:30: you know you might hit heavy traffic at 7:30, and that you have to park somewhere that could be a 5-10 minute walk from the station. So if you really need to be there at 8, you plan for the worst case.

Then the day comes. You leave at 6:20 (yes, you also built some margin into the time planned for showering and brushing your teeth…), find no traffic at all and arrive at 6:40. You even find a parking space right in front of the station, since nobody is around at that hour. Fantastic: it's 6:45 and you're at the station. Mission accomplished!

Immagine dell'articolo

OK, OK… you're hungry because you skipped breakfast so as not to lose time, and now you have to wait more than an hour; it's freezing, meanwhile it has started pouring with rain, and the station bar opens at 8… but catching that train was really important, so it was worth the pain!

Back to our process: how long will it actually take to process the whole batch? One thing is certain: it won't take exactly 6 hours. Maybe the person doing the setup takes a bit longer to check that all the screws are properly tightened, or can't find the fixture that was supposed to be there but is somewhere else… or maybe the operator takes a little more than 300 minutes to make the 60 parts because it's the first time they've done that job. Or you're lucky, everything goes smoothly and the operation is completed in 295 minutes, setup included.

The reality is that most of the factors critical to running a plant successfully (as well as a project or a service) cannot be determined precisely ahead of time, whatever MRP, ERP, MES or simulation system you put in place. OK, someone will tell me that something can be done with A.I. nowadays, but in the end A.I. is nothing more than an interpolation system that uses a lot of data: it may be a little more reliable than a simple average, but by definition it will fail to foresee the future.

Your plan and reality.
Your plan and reality.

Everything is affected by statistical fluctuations (closer to or further from the average, depending on how much variability your processes have). And if you think that in the end all the fluctuations will average out and everything will be fine… well, I have bad news for you: most of the time they won't, and you will be in trouble.

When you work within a system of dependent events, unfortunately you have to deal not only with variance but also with covariance… and covariance works a bit like Murphy's law: if it could go well, it will go badly.

Back to the train example and comparing it with a manufacturing plant: if you plan with the average, you will very probably miss your train. So if you plan with averages (the routing times loaded into the system), the number of orders you ship late will be considerably high. And remember that in the example we are considering only one operation (the trip from home to the station), whereas in a manufacturing process with N steps the same concept is combined N times: sooner or later you will miss your train.

So unless you build a very big margin into your calculations, which means building a lot of inventory between operations to bury the planning "inaccuracy", you will end up late.

Let's think about it for a moment: shipping an order late doesn't only mean that your customer will be upset and call you every day for an updated plan; it also means that the cash arrives later and the goods occupy space in your plant for longer. The impact has three dimensions: reputation, financial health and economic result.

On the other hand, if you want to be sure to hit the target and you plan for the worst case, the customer may not accept such a long lead time, and you risk losing the order. If the customer does accept, you will catch the train and ship as promised, but you will lose a lot of time (= poor cash flow and full warehouses): this approach will cost you a lot of money and a lot of customers.

Immagine dell'articolo

If you plan for the best case, you will certainly end up late… it's the typical customer who is happy only when the contract is signed: they toast with your sales director to celebrate the new "partnership"… and then the nightmare begins for everybody: for you and for your customer.

So, what can we do?

My suggestion is to stop relying on planning systems.

You can invest in any ERP you like: the numbers that come out will only be a mirage, and your sense of control will remain an illusion. ERP is the basic principle of a "push" manufacturing system: it looks as if it can work well, but it won't.

Better to start "pulling" and to invest your time and money in reducing variability, starting with strong and clear standard work.

It is variability that kills profit.

Isacco Bettin Originally published on LinkedIn