Interesting lean news continues to flow from the UK, and the latest eyebrow raiser is the assertion by the folks at a company called Preactor that lean practitioners who fail to use ERP based systems are ‘Luddites". I find this to be a very curious twist of logic. The Luddites, for those whose knowledge of British history has a gap or two, were a group opposed to the industrial revolution and had no qualms about resorting to violence to prevent mechanization, especially of the weaving industry. In more modern jargon, a ‘Luddite’ refers to just about anyone opposed to change – especially advances in technology. Inasmuch as the ERP crowd in general, and outfits like Preactor in particular, are doing nothing more than pushing variations on MRP packaged in new acronyms and running on slicker computers it is a bit ironic for them to call me a Luddite. It seems to me that those advocating 45 year old solutions with such emotion that they build their marketing campaign around insults and name calling are a bit more Luddish than I am.
The emotional proponents of ERP as somehow being a critical element of excellent manufacturing see a conflict where none exists. Lean folks have never said that manufacturing should be technology free, nor have any of us asserted that every manufacturing or supply chain system is inherently bad. This idea that a titanic conflict exists between lean and the IT solutions crowd exists only in their own minds.
Not being one to shirk from a good name calling battle, however, I would suggest that the ‘Almighty Algorithm’ gang thinks an awful lot like Tim "The Tool Man" Taylor. For those readers fortun
ate enough to have lived a life free of the dregs of American culture, or those too young to remember the old Tim Allen sitcom, The Tool Man was a lovable but moronic guy with an obsession for power tools. Virtually every show included a sequence in which he would apply some tool to a job that went way beyond the bounds of logic, resulting in destruction on a grand scale.
The Tool Man’s problem was that he went into every effort with a bias toward the tools he could use, rather than a practical assessment of the problem and the ability to apply an appropriate solution. In this regard the mammoth IT application crowd is the same as the Tool Man. I recall one episode in which Tim Taylor installed a turbocharger in his wife’s dishwasher, with catastrophic results, of course. The scenario has a lot in common with Lego turbocharging their distribution network with ERP. Both the dishwasher and the Lego supply chain ended up blown to oblivion.
What makes the issue frustrating for the lean community is that the lean practitioners, as a rule, know a whole lot more about enterprise software than the software folks know about lean. Most of us have been there and done that and we are working within lean to find better tools. It renders serious discussion difficult, at best. The article describing me as a Luddite is built around about the most simple minded description of lean you can find. Basically lean manufacturing, according to the fellas at Preactor, is heijunka, or mixed model scheduling. That reflects about as much insight into lean as me describing enterprise systems as nothing more than big calculators.
Lean is a fundamentally different business model. Excellent shop floor practices are driven by management principles far different than those embedded in the old MRP/ERP logic. The global IT people don’t seem to get it. Insulting the lean community for refusing to embrace outdated, overblown tools doesn’t help. Only stepping back and learning what lean is really all about, then developing tools that support core lean principles will restore the credibility of the enterprise systems folks.
Karen Wilhelm says
ERP is just one example of IT impositions that make life difficult. How often do you see IT people on the gemba, whether it’s an office, a pharmacy or the factory floor? I can tell you for a fact that the IT “teams” developing the next generation of factory production scheduling processes in a major auto manufacturer are never in the factory. They rarely even know anyone there.
Jim says
I know I have taken my beatings here before for supporting MRP/ERP… but I just don’t see how you can totally throw out the computer system.
If (for example) you use kanbans, you have to get some starting numbers to base those off of… Where does that usually come from, a forecast and MRP???
Perhaps the root of the issue is that the “right tools for the job” haven’t been mainstreamed yet like O. Wight did back in the day for MRP II.
-Jim
Bill Waddell says
Jim, nobody has totally thrown out the computer system or any other tool. The point is that the MRP/ERP crowd fails to recognize that they are proponents of a tool – not a strategy – not the heart and soul of the business – just a tool that may or may not be the appropriate one for the job.
Imagine someone who honestly believes that there is no way to build a quality house, and that no carpenter can be deemed a professional, unless they are using a Vaughn 21 oz Framing Hammer with Magnetic Nail Starter. No evidence to the contrary sways him, and he writes and lectures on and on and on about the idea that all good home construction revolves around that one tool.
That is what the MRP/ERP crowd does. All computers, and whatever is in them, are simply tools. Excellent manufacturers are masters at all of the tools – including MRP/ERP. But they know when to use which tool for the best results. They do not go into every factory, sight unseen with a preconviction that no matter what they find, they will apply a particular tool.
MRP has great strengths, and it also has great weaknesses. So long as the MRP/ERP crowd fails to acknowledge the weaknesses, or writes them off as unavoidable, their credibility will suffer in the lean manufacturing community.
Finally, I have ALWAYS, in my book, in my articles, in by blog posts and in my advice to clients made it clear that MRP has great planning capabilities that just about everyone can use – including Toyota. The problem is that MRP is a lousy execution system and push manufactuirng creates serious problems in many manufacturing environments. My advice is usually to keep the planning elements of MRP – especially capacity planning – and scrap the shop floor execution elements.I agree that the right tool for lean manufacturing has not been mainstreamed yet. See my article on LRP that addresses that very issue.
http://www.superfactory.com/articles/Waddell_MRP_RIP.htm
Barry "aka the Hillbilly" says
Right on again Bill !
My favorite hammer is a Vaughn 21 oz, have an Estwing and Plumb too. Estwing is still made in USA, don’t know about the Vaughn. I can’t find a use for the fancy ERP software around the homestead. Computers and software no matter of what type are tools, its the humam who ultimately makes the decisions. Too much Data which often is also not timely just ends up being a hindrance. I suspect that one of the problems with ERP is that it is trying to forecast and schedule based upon historical data. Whereas Onosan’s Kanban supermarket pull system transfers the beat of the Market upstream quickly.
Graham Hackwell says
As the person who introduced the concept of ‘The Luddites of Lean’ I’m pleased to see that it is being debated so passionately. I have had conversations on this theme with a number of journalists and as I don’t know which article Bill read or how well it represented my views perhaps I can state my position in my terms.
I have nothing against the fundamental principles of Lean in reducing waste. Any mechanism that helps to reduce waste in manufacturing will help our beleaguered Western manufacturers compete with the lower cost economies. As I work for a company that writes and sells production planning and scheduling software my comments are aimed at the production control system that typically seems to result from a Lean project, i.e. Kanban. In fact there seems to be a bit of a ‘joined at the hip’ view in the Lean community that Kanban production control the only way to be Lean.
So why the Luddite comment (I note that Bill has done a good job of explaining that a Luddite is someone who is afraid of technology and indirectly accuses me of proposing 40 year old technology)? A production control system is just that, a control system for a production process and there are a large number of analogies between the control of production and the control of other processes.
Take the world of aerospace for example. In the US you have the Stealth Fighter (F117) and Stealth Bomber (B2), over here in Europe we have the Typhoon. All three of these aircraft are aerodynamically unstable and for the pilot to be able to fly them they require a computer based flight control system. We could not have built these aircraft 40 years ago because the flight control technology had not been developed.
In manufacturing we routinely use CNC machines and PLC controlled processes to give us the accuracy and flexibility we require. Forty years ago this technology was in its infancy.
We should also look at the cars we drive. My first car had a 1 liter engine that produced about 45 horsepower with the performance to match, and it did about 30 miles to the gallon. My current car has a 3.3 liter engine and around 270 horsepower. It is faster but also much larger and heavier than my first car, however it also does about 30 miles to the gallon. How is this possible? For the most part it is down to computerised engine management, which again we could not produce 40 years ago.
So as we look around the world at all the fields of human endeavour we can find hundreds of examples of how computers allow us to control processes more effectively, except, it seems, if that process is a production system. Here, we are told by many in the Lean community, only Kanban can provide a truly Lean process. In effect we are being told that a production control system that could have been installed in the 19th century is still the best we can achieve in the 21st, and this is the reason for the Luddite tag.
In the production control world it is Kanban based systems that are the 40 year old technology, and they have not changed over that time. IT systems have moved forward tremendously in the last 40 years, and to try and equate the functionality of a 1960’s ERP (MRP then) with current offerings, especially APS and FCS systems, it like trying to compare my first and current cars. They both have four wheels and an engine, but that’s about it.
So let me finish by being even more controversial. Kanban production control is a make to stock system, and the Leanest manufacturing process is where we make to order. It is well known that Kanban systems do not cope well with the all too real world variations in demand, so let’s pose the ultimate Lean question:
You are running a production process and demand dries up completely (maximum variation) for your product, what state will the plant be in when it stops?
In a Kanban controlled plant you will have no finished goods but all the intermediate and raw material Kanbans will be full.
In an APS controlled make to order plant the whole process will be empty.
You decide which is Leaner.
Barry "aka the Hillbilly" says
Onosan at Toyota did not subscribe to the idea that technology was to be adopted blindly, just because it was new and suppose to be better. He said this of the robot craze in particular. The proper analyis has to be done and the impact upon the entire system has to be understood. The technology would be adopted only if it actually helped reduce waste and did so in a cost effective manner. I don’t think Software would be any different. Much of this software is rather pricey. Would the additional cost required for the Software and the underlying hardware really improve a companies performance sufficiently to cover the costs ? Does anyone know what Toyota is using today? Is it one of these Software packages, or have they developed their own?
Josef Horber says
Graham,
if the development of engines would have been primarily driven by software, I am sure, that breaktrough technologies like fuel injection, common rail, turbo charging or hybrid engines would have never been invented… they were driven by engineers and all have reduced fuel consumption considerably. Engine management software has contributed to the last 5% of improvements.
Regarding Your kanban example, a product, which suddenly looses demand from 100% to 0% is not a very realistic one. And even if that would happen, if that loss could be forecasted, a kanban system could have been adjusted to cope with that. If the change was not forecasted, then You are right, You end up with a couple of days worth of inventory in Your kanban totes. But using whatever sophysticated APS / MRP combination, You sure end up with a much larger surplus in the pipeline (on order, supplier´s stock, in transit, inbound warehouse, etc.), simply because Your leadtimes are longer, the lot sizes larger and the feedback loop less direct.
Finally, we lean guys don´t want to shut down the MRP server. We just want to scrap the client PC-s / terminals on the shop floor and in the production control office. MRP I would be still very useful for long term forecasting of material and machine capacity demands. We just don´t need MRP II anymore to do the daily production control. So we don´t put the IT community completely out of business.
Regards,
Josef
Graham Hackwell says
Sorry for the delay in continuing this discussion and for the length of this post, but I feel that Barry and Josef’s comments deserve a full response.
Barry,
I agree with what Onosan and you are saying. It would be bordering on negligence to adopt any technology just for the sake of it, and I amongst many others would also agree with him that robots were an over-hyped technology.
However Onosan does say that a proper analysis of new technology should be carried out, and my main criticism of the Lean Community, and the cause of the Luddite comment, is that there has been no impartial analysis of the alternatives to Kanban as a production control system. From the outside it seems that the Lean Community is saying “We have made up our minds that Kanban is the best production control system, please don’t confuse us with any facts or other ideas”. Can I simply ask you all to review the case studies on our web-site (Preactor.com) and those of the other players in FCS/APS production control arena, so that we can start the analysis.
You mention cost and I am quite happy to talk Dollars if you are. Our entry level software costs less than $500, there are then a number of price points up to the system most of the case studies refer to which is less than $23,000. Of course there will be service costs to add to that, and the scale of these is very much dependent on the needs of an individual client, but the consensus across many Preactor implementers is that between 1 and 2 times the software cost covers the majority of installations. So we are looking at an all up project cost of under $70,000 for most clients.
What are the benefits and the payback period? In our case studies you will find that the benefits are typical of any Lean project, significant improvements in productivity, reductions in all forms of inventory, reduced lead times, improved delivery performance etc. You will also find examples where the payback period was measurable in days or weeks, but for most a year or so would be typical.
I would be interested in a cost comparison with Kanban based Lean implementations, but to date public discussion of fee rates and the number of man-days required has been limited, if not non-existent.
Josef,
In engines, as with most technologies, the development of the control system goes hand in hand with other improvements in the design. The same team of engineers develop the software alongside the more traditional engineering components and it becomes a bit of a ‘chicken and egg’ discussion if you try to split them up.
Probably the biggest gain in gasoline engine thermal efficiency has come from raising the compression ratio. As students of thermodynamics will be aware the thermal efficiency of an internal combustion engine is in proportion to its compression ratio. Going back to my first car the compression ratio was about 8:1, but today 10:1 or more is typical. Over the same period the octane (anti-knock) rating of the fuel has reduced (certainly in Europe due to our late adoption of unleaded gasoline), so how were the engineers able to raise the compression ratio?
Before computerised engine management the ignition timing (timing of when the spark occurs) was controlled by a centrifugal system comprising of bob weights and springs. As the engine speed rises the spark is advanced to allow the necessary time for the fuel to burn, but if as you advance the spark towards the point of optimum efficiency, pre-ignition (knocking, pinging, pinking, etc) can occur. The crude nature of the centrifugal spark control system meant that engines were always run some way from their optimum spark timing to avoid the pre-ignition. Raising the compression ratio also makes the pre-ignition problem worse, hence the fairly low ratios used in the past.
The modern engine management system has an anti-knock sensor on each cylinder and it can alter the spark timing of each cylinder individually so if pre-ignition starts to occur, that cylinder is retarded slightly to stop the problem. This allows both the higher compression ratios and for the spark timing to always be close to the optimum. You can argue that the compression ratio and the more optimal spark timing have actually given the increased efficiency, but it is the software in the control system that enabled the improvement.
The same argument applies with diesel engines. You mention common rail technology, which is a replacement for the old diesel system where a mechanical pump injected the fuel into the cylinders. The timing of the injection is the equivalent of the spark timing in a gasoline engine and the mechanical pump used the same concept of a centrifugal system to advance the injection point as the engine speed increased. The inaccuracy of this injection timing is responsible for a large amount of the knocking and rattling that is still associated with simple diesel engines.
In a common rail system a high pressure line (the common rail) supplies fuel to electrically controlled injectors (in effect solenoid valves). The injectors are in turn controlled by a computerised engine management system similar to those used in gasoline engines.
To get back to the Kanban discussion, I would agree that my example of demand stopping completely is extreme and unlikely to occur in practice, but I use it to illustrate my point that Kanban based production control does not cope well with variations in demand. You said yourself that the Kanban system could be adjusted to cope, but that is exactly my point. If you size your totes for peak demand that occurs, say, 5% of the time, for the other 95% of the time the size is wrong, and you either accept the overhead of re-sizing or you carry more inventory than you need.
You are also making the assumption that the lead times associated with an APS controlled process are intrinsically longer than those achieved using Kanban control. Why should that be so? We have many clients in the fresh food business whose door to door lead time is a few hours and they have still achieved huge benefits from APS control of their process.
I would entirely agree that using large Economic Batch Quantities (EBQ) in your ERP system will create all the pipe line issues you raised, but there is nothing intrinsic in either an APS or MRP system that makes you use large EBQs. It is a reflection of the simple production control system that was, and in many cases still is, in use.
To me the analogy between the production control discussion and the engine management systems is now more striking than ever. The large EBQs are equivalent to having static ignition timing. The engine and the production process will be very inefficient. Moving to the mechanical Kanban system is like using the centrifugal ignition timing. It is much better than static timing, but the engine and production process only occasionally achieves anything close to optimal performance. APS and computerised engine management bring the same benefit of running the process close to its optimum performance most of the time.
Fundamentally for the Leanest process you need the fine and accurate control that a computer brings.
Josef Horber says
Graham,
Nice try of crediting higher engine performance to better sotware.
Once there was a young austrian engineer, who just poured out one car invention after the other to the market, starting with the legendary aircooled 985 cc 25 hp Volkswagen Beetle, then a 35 hp sports car “Type 356”, further developped to a 95 hp “Type 356C”, then a 2 litre, 130 hp “Type 911”, which has been constantly developped until reaching today 381 hp in the “GT3” version. The inventor´s name was Ferdinand Porsche.
Most of his innovations, like aluminium cylinders, pistons, body shells, air cooling, turbo charging, synchronised transmission, disc brakes, etc. were realized at times, when computers were either non-existing or larger then the car itself.
If You would take the old 25hp Volkswagen engine and tune it up with all available software in this world, how far would You get?
Yes, IT and engineering have progressed hand-in-hand at least in the later decades, but IT was not the primary driver, it´s an enabler.
Talking about kanban, it is that easy to operate it, because there is nothing to adjust on it, it adjusts itself, like Your pre-ignition control unit, but without any computer support. If You sell a tote worth of inventory, You make another one, if not, You don´t. That easy.
You don´t have to change the tote (batch) size. The only adjustment You might want to do is to reduce the WIP, when sales are constantly low. The procedure therefore is:
·The team leader sees a supermarket location, that hardly ever gets emptied. He says: Well, well!
·The team leader takes one kanban card of an empty box and throws it into the waste basket. He says: Now, let´s see!
·Next time, his supplier will make one less, but he does not even know about it; the lane gets emptier. The team leader says: Aha!
·He might take out another card, until the supermarket location´s quantity goes up and down the way he likes it. Then the team leader says: Cool!
·Should the sales ramp up, he will start adding cards again, saying: All right! It´s show time again!
It might be difficult to believe, but I swear, he does not need a computer to do that.
You are right, there is no “intrinsic code” in the MRP making large batches. The only problem is, that those responsible for the almighty algorithm are not on the shop floor, don´t see the supermarket location in action and don´t “smell” the improvement opportunities. They only rely on reports.
I just talked to a collegue few days ago, who was ordering pallet loads of diapers with the same EOQ formula as a handfull of pills, completely unaware of the two products’ different warehousing and handling costs. For her, buying 10 pallets * 100 EUR is the same as 10 blisters * 100 EUR. That´s the problem with MRP. Yes, I know, there is software which can handle this, but nothing is as effective, as standing with 10 pallets behind You in front of a rack with 2 empty locations and saying “Oops!”. If You did this once, I am sure, You will never ever order 10 pallets again.
Regards,
Josef
Graham hackwell says
Josef,
You describe the software in an engine management system as an enabler, but it is an intrinsic part of the system and it is the part that has moved on the most in the last 40 years. If you replaced the engine management system on a modern engine with the old mechanical equivalent the power output would drop. Similarly, to answer your question about the 25hp Volkswagen engine, if you applied a modern engine management system with no other changes you would get more power. Why, because the ignition timing would be set to the optimum point all the time rather than the non-optimum ‘average’setting that the mechanical system used.
I’m not trying to decry the work of engineers such as Ferdinand Porsche. If he had been working over the last twenty or so years I’m sure he would have embraced the improvements that computer based control systems have brought, much as he embraced the mechanical improvements of his era.
Your comments about the team leader removing the Kanban card are fundamentally about visibility, and I would agree that decisions made without visibility of the results are a major problem in some companies. However Kanban control is by no means perfect because the visibility is limited in two fundamental ways:
1.The visibility is always retrospective. In your example the supermarket team leader only reacts after the event when the inventory has already been made. Where is the look ahead capability that enables him/her to make the decision before the problem occurs?
2.The visibility and the decision making is locally based, so no one has an overall picture of the process to enable them to make the trade off decisions that are inevitably required. For example the extra tote of, say, component A that the team leader has now decided is not required at the supermarket has already consumed resources to make it which could have been more usefully deployed making something that is in demand.
What APS production control gives you is visibility of the current state of your process and the future state if no action is taken. In other words it gives a look ahead and ‘what if’ capability so you can see the problems before they occur, and then test different strategies for overcoming the problems.
It also removes the 1984 element of Kanban control. If you are running a multi-component cell under Kanban control and you have cards/totes for more than one product how do you decide which to make first? In the egalitarian world of Kanban all products are equal, but in the real world some are more equal than others. The component for the product with declining demand can wait while we make the components that are in demand, but the cell supervisor cannot see this because his/her visibility is limited.
In an APS controlled process the planner can see the whole picture and can modify the instructions about what/when to make (or buy) to satisfy the KPIs the company is trying to meet. The planner can, for example, decide if and when overtime is required to meet the current delivery profile, and if the delivery profile allows it they can batch like products together to give some economies of scale.
To me the fundamental question is “What is so special about a manufacturing process that it cannot benefit from the improved control that computers have brought to every facet of human endeavour?” If we cannot identify these ‘special characteristics’ then the Luddite theory that started this debate would seem to fit the situation.
Regards,
Graham
Barry "aka the Hillbilly" says
Thanks for all of the commentary from both of you.
I will say Graham I don’t really have any problem with using computers when it makes sense. I was involved with a Neural Network Control application on a three phase Electric Arc furnace application. It was a good idea and did prove its worth. The company provided good support for a time. The problem was there were only so many EAF’s in the US and they eventually shut down. I don’t know what level of support their customers now have.
I think too many people and companies have this belief that if it involves a computer then it must be a good thing. A lot of companies don’t have the manufacturing accumen of Toyota. I suspect it would be pretty hard to pull the wool over Toyota’s eyes. A bunch of slick Computer guys probably wouldn’t get far with the students of Onosan. But many US companies have spent untold amounts of money on the next big thing always chasing the next big leap in technology.
The problem with computers is that they only operate within the box that has been created for them. The code is what they know and that’s what they run. If you want any kind of decisionmaking outside of the code, then the computer is stuck. You need a human for that.
Having been exposed to computer applications, both control and erp versions, I have seen a number of problems. Many of them revolve around the fact that the Computer people go home, back to where they came from. Then when there are problems or some unusual condition occurs, well then you have to go try to get support. Sometimes its available in a day or so, but many times it takes a while. Sometimes it even requires a code change. It just seems to be a hassle in general. I think the computer world has a third world mentality concerning customer service.
Microsoft would be the poster boy of that Third World menatality. I think I have downloaded hundreds of patches just to try to keep the thing secure and running. Thank god they aren’t into autos. I can’t wait till the day I get into my car and try to start it and see a microsoft logo on the screen and it says downloading. No thanks.
Onosan seemed to trust the information flow to people who actually manufactured the product. Instead of some Production control person sitting in some comfortable office chair deciding upon what comes next.
And I am not really sure if the software you are talking about plus the Hardware and the network wiring or hubs and all really would give you something that was much better than kanban. Onosan talked about type 1, 2 and 3 companies in his last book. The point was that since Toyota still had to keep Inventory in the pipeline moving to Dealers and also the Dealers had to keep some inventory, that there wasn’t a need for a more sophisticated control system beyond simple kanban.
But at the end of the day the proof is always in the pudding. How much is saved by employing a computer based system versus the simple kanban. I suspect you might know of case studies that explore that very topic. It would be interesting to know what Toyota is using today. I think if a computerized kanban system had merit, Toyota would be using it.
Take care,
Nigel Shires says
On the subject of control systems, I first met Graham more than eighteen years ago when I presented a paper at “Control 88”, a conference of the IEE (Institution of Electrical Engineers, UK) back in 1988. My subject was not engine management control, but was about applying the control techniques used in many continuous processes to a very discontinuous process, namely discrete batch manufacturing. As a Production Engineer (Industrial Engineer in the US) I was an interloper in foreign territory at the IEE!
However, in my conference paper I recognized that in the same way that you have a controller for your domestic heating and temperature (timers, thermostats, control valves, microprocessor with a controlling program, user interface), a factory is a system that has inputs, outputs and requires some sort of controlling program. This idea that a factory is a system that can and should be controlled is still difficult for many CEOs and production managers to appreciate. We have heard countless times “we put an order in to the factory and actually have no real idea when it will come out”. If you tell me you’ve never heard this sentiment I wouldn’t believe it!
Why should this be the case? Why is a factory so special that it can’t be controlled and work in a reliable and predictable manner?
There are many reasons for this lack of control, which often gives the planning department (with their comfortable office chairs that you refer to) a very bad name. But who’s fault is it really? Anecdotal evidence such as “the CEO is the main disturbance to the schedule” and inconsistence performance measures (utilisation, due date performance and ROI of expensive capital equipment) often lead to the factory doing anything but following the sequence of work put out the planning department. Everybody always knows best and certainly better than the planners! How come the people on the shop floor who are experts in manufacturing the product are suddenly also experts in planning what should be done next on which machine? Are they also experts in everything else as well? Sounds like anarchy to me.
The factory has to be brought under control (which means that it works in a reliable and predictable manner), and if this means that the factory’s KPI is reduced to just one single measure, namely the degree to which they have achieved the schedule, then the planning department will suddenly (and unusually) be responsible for actually achieving the performance to the usual KPIs of utilisation, due date performance etc. (A radical notion).
So how do we bring a factory under control? One way is to simplify the problem (always a good idea). Do some physical things such as moving the machines to minimise wasted material movements. Improve the reliability and predictability with better QC feedback and better tool changing mechanisms, CNC machines, better training of personnel etc.
You will still need some sort of controlling program, and that is where Kanban and APS come in. Kanban is a “controlling program” implemented in a very physical, understandable and non-computerised way and hence doesn’t fail, doesn’t need rebooting from time to time or start downloading and installing updates just when you don’t need them! (unless of course you are using the rather perverse notion of “Electronic Kanbans”).
Kanbans are usually found controlling a relatively small self-contained area within a factory rather than the complete production process from beginning to end. This is because the more decision points there are within the kanban loop (e.g. which of these waiting operations shall we do next on which machine?) the less predictable the output of the kanban-controlled cell and the more out of control the resources will be.
This unpredictability increases with the size of the kanban loop because of the multiplying effect of a change in the sequence in which operations are loaded affecting the productivity of the cell, especially if there are sequence-dependent set up times.
Another problem within a kanban loop is the rule used to arbitrate between two jobs competing for the same resource. If the control algorithm is “choose the job with the biggest pile of kanban cards”, it’s not a very sophisticated algorithm (being polite).
In any case, the question still arises “Can we predict that if put an order in to the factory today that it will be completed on such and such a date?” To be able to answer this question is essential to accurately promise delivery dates and win repeat business in a jobbing shop (make solely to customer order) environments.
To answer this question an appropriate scheduling program (usually used on a computer, but sometimes a manual card-based system) is useful as part of the “controlling program” and in fact is best used together with the input and intelligence of a human planner as part of the program (as you have mentioned, a computer cannot possibly know everything and certainly does not have anything approaching human insight into problems. Of course it can only do what it has been programmed to do). Controlling Programs which operate as a “black box” where no-one understands why it works in the way it does are doomed to failure, together with those where people expect it to do things it hasn’t been programmed to do (will it make the tea as well?).
Many times we hear “we cannot use a scheduling system because…” “there are too many variables”, “there are too many disturbances”, “we can’t possibly predict that”, “we don’t have the data” and so on…
My reply to these so-called problems is “why is this the case?” Why don’t you have the data? Why are there too many disturbances? Why, Why, Why? What is actually the problem – Are these symptoms of a culture which doesn’t actually want to make decisions and choose between jobs competing for resources in an informed, open and visible way? A culture change is required (sometimes with the corresponding culture shock).
Installing a classic control and feedback loop around the factory (with the appropriate KPIs and will to succeed) will result in the convergence of “Expectation” and “Performance”, usually within a very short time (weeks not months), because the difference between what is expected (the schedule) and what actually happens (the real world) can be examined at regular intervals and the question asked “why couldn’t you follow the schedule? The answers are usually surprising to the management (but never to me) and can reveal a lot about missing materials, production equipment not functional, and a whole pile of problems (there is another word for this pile) that the production guys are dealing with every day. Perhaps we should talk to them more often!
The result will be a factory which is in control within a reasonable accuracy and starts to perform in a systematic way, reliably and predictably and responding to adjustments – you may even be able to turn the performance up using that conceptual “productivity” dial.
To summarise, it is amazing that everyone is happy to purchase a relatively sophisticated control system for our domestic heating and temperature (timers, thermostats, control valves, microprocessor, user interface) for hundreds of dollars, yet for a factory production system which is vastly more complicated and expensive, factory managers are not prepared to even consider that it can be controlled, never mind purchase and implement a control system!
To have reliability and predictability and to promise delivery dates you not only need to identify and solve the day-to-day production problems but you also need to have your factory under control with a properly designed control system. Otherwise you might as well gaze into a crystal ball to promise your delivery dates!
Barry "aka the Hillbilly" says
Nigel,
Thanks for all of your insight. I have enjoyed the dialogue, even though I wasn’t the initiator originally.
I am an Engineer myself who has worked in the Automotive and Quality field for 20 years. I have been around quite a few control systems also, some of the simple PID loop variety and a few of the more sophisticated sorts (Nnets).
I basically believe that Onosan thought the whole production process thing through pretty well. I have a great deal of respect for what Onosan and the others (Kiichiro, Eiji, Ishida, and Shigeo Shingo-consultant) did at Toyota.
I believe that Onosan was correct in constructing a production system which forced the information to flow backwards from the customer all the way back through Toyota and finally to its suppliers. In this way, you don’t need a BIG BROTHER Type of Production planner sitting up somewhere trying to anticipate what the customer will order next. Inevitably the best forecaster isn’t very accurate.
Onosan created a system that took order information and fed it backwards keeping it near production and in the hands of the folks who add the real value to the product. I actually think that its important to have the production folks handling that information. I think that’s better than having some Master Production Schedule posted weekly and broken down by day and shift. Onosan even went so far as to state something to the effect that waste could not be eliminated if the worker knew what the next part was going to be ahead of the time it was required.
As a customer myself, if given the choice, I would not be willing to pay for the computer hardware and the software and the support of the computer consultants piled on the top of the price of the product. I would rather buy the product produced using Onosan’s system at a lower price. I would much prefer that the money saved by not buying a plant wide ERP system be used to conduct DOE’s and appropriate plant level engineering in order to improve the quality and reliability of the product.
When it comes to creating an effective plant level control system, Onosan showed how that is done. The real work that adds all kinds of value isn’t in spending a bunch of money on some Plant Wide control system that just highlights the plant problems. Most plant people if you ask them already know quite a bit about the problems anyway. The very same ones you mentioned. Plant Equipment reliability, production variability, personnel, etc. No the real value is in finding out what local and/or system factors create those problems. That work is not easy and I believe while the production people can be a valuable part of the team to address these problems, often times it requires dedicated management and engineering efforts.
The best thing to do is to connect upper level management in a very personal way to these problems. Onosan with his belief in the Gemba (Go and See for yourself at the spot) and his stubborn application of the scientific method (An idea can be tested right away on the plant floor and then we can know which way is better) got management and the workers involved right where the problems were actually occurring.
The real beauty of what Onosan did was that he created a simple system that connected the wants (orders) of the Toyota customers directly to the very people who were creating those products. This system was operated in such a way as to always apply pressure so that the problems would naturally be exposed. Toyota then had the discipline to stop production and at least attempt to determine what were the inputs which had created that problem. I’m guessing that Toyota must not have had very many Accountants at that stage either, that would have made it a whole lot easier to shut things down and find the true root cause of a problem.
The real value is in fixing these problems and then implementing preventive measures to make sure the problem does not show up again. Toyota usually builds in automatic controls to their production process. The Jidoka concept. Once you have done this, scheduling is a snap. It’s not hard to schedule processes with equipment that operates at a six sigma level and produces a product with quality characteristics at that level also.
I see a Plant Wide ERP system as something similar to just another layer that protects Western Management from rolling up their sleeves and getting dirty and solving the real problems that hamper productivity and cause quality and long term reliability issues.
What is surprising even to me is the ability of Toyota to apply their production system ideas to their engineering and design activities. Selling their products at the price levels of the Mass production companies has allowed Toyota to make huge profits. With Design and Engineering processes focused upon continually increasing the value delivered to customers, and the resources to conduct very substantive research, it appears that their won’t be many who can keep up with them.
But Hey, I could be wrong ! It would’t be the first time. Let’s do this, why don’t we wait 10 years and then take a look at things again. Lets see which style of system wins out in the end. Systems like Toyotas or those with layers of insulated Management using enterprise wide ERP style planning.
Which one of them in the end will deliver the most reliable products to customers and provide sufficient returns to the companies to create ever more valuable products.