An old, very esoteric, post got a four word comment today that sent my mind thinking. And because the topic is esoteric, this post is as well – my apologies.
The post, Is the MRP Algorithm Fatally Flawed, gets a lot of search hits because of the title. The post discusses an obscure PhD dissertation that asserts that the underlying logic of MRP systems share defining characteristics with a debunked model for computational intelligence. The researcher makes a compelling case.
The comment, from Indonesia, said “please send for example”
Assuming I did not misinterpret the comment, I believe the writer was asking for examples of what does not work.
Here is what got me thinking.
In order to refute Dr. Johnston’s thesis, we have to find a non-trivial case where an unaltered application or the MRP algorithm works as intended. Just one. Then we would have to carefully understand that instance to determine if it was truly a case where MRP is working as intended, or something else.
Ironically, the working examples I have seen have gotten there by combining work centers into value streams with pull and systematically turning off the inventory netting and detailed scheduling functions of their MRP. In other words, they are migrating the system toward something that directly connects supplying and consuming processes with each other. These systems are far more able to respond to the small fluctuations that trip up the MRP logic. Those examples, however, confirm, rather than refute, what Dr. Johnston is saying.
Considering that the vast majority of factories are still trying to make the MRP algorithm work, does anyone have an example of where discrete manufacturing order scheduling of each operation actually gives a workable production plan that can be followed without hot lists and other forms of outside-the-system intervention? Just curious now.
LOL.
I can hear the crickets chirping…
Hi Mark:
A friend advised me to respond to this post. I concur with you that ERP (and earlier MRP-II, and before that MRP) continues to offer the wrong IT solutions to industry. The underlying assumption of ERP is forecast-driven manufacturing, process layouts, batch production, factories that are not organized into cells, and whole lot more false/wrong assumptions. But, because ERP systems have bundled the MRP-scheduling function inside HR, CRM, etc. functions that are indispensable, all users are condemned to using MRP. But, I have something positive to offer — if readers access websites like http://www.preactor.com, http://www.waterloo-software.com, http://www.optisol.biz you will see a new generation of IT-aided scheduling systems that, in principle, are doing the RIGHT thing that MRP never will! Readers may want to pick up a copy of Mike Liddell’s “Little Blue Book on Scheduling” or the classic by Kirchmeir and Plenert “Finite Capacity Scheduling”. Keep up the good work!
Shahrukh
P.S. That being said, I fully concur with you that unless the factory layout, unless the people’s thinking, unless the cross-training that is needed, etc. are in place, no software will deliver a dime!
I guess I would say that any system that tries centrally scheduled predictive execution is going to have the same inherent problem.
Hi Mark,
I would not agree with your “guess work”. If you seek practical evidence, I am ready to offer it to you.
There is no guess work involved.
I am citing peer reviewed academic research that is, in turn, build on a foundation of work out of MIT that has been validated in real life.
If you care to offer any refutation, first read the dissertation in the link, then look at the research foundation he uses to build his conclusions, then offer citations in quality research that refute the claims made by Dr. Johnston.
The thesis you referred to was written in 1998. Due to the exponential growth in the power of computer applications during the last decade, most of what is written about finite capacity scheduling (FCS) software is no more valid.
Please read the page 176 where the author writes about the problems with FCS software while saying “A number of quite sophisticated PC based finite capacity scheduling packages are now available”. All those issues are now resolved in many job shops with the help of new and sophisticated algorithms, excellent shop floor data collection systems, powerful information systems and PCs with tremendous power and memory. Nowadays, the execution time of the current FCS tools is in seconds not in hours (as in the past). The increasingly adopted job tracking systems currently provide strong support to FCS tools. The scope and development of IT applications after 1998 have been phenomenal. You can chose to ignore all the developments after 1998 to maintain your view based on old thesis.
Prasad-
If you want to make a case, simply saying “It is all fixed now” does not do so.
The thesis cites very specific characteristics of classic computational planning systems, and demonstrates why they are ineffective at dealing with real world issues. Note that this general case is actually outside of the context of manufacturing systems, it comes from research breakthroughs in computational intelligence that were made at MIT. The general case also specifically mentions that order of magnitude increases in computational power made only a trivial difference in performance. After making a GENERAL case, Johnston then makes the argument that MRP systems are an instance of the general case.
Now, it may very well be that these newer systems have, as you put it, “resolved all of those issues.”
Great. But if you want to make the case that the information in this dissertation is now superseded, you will have to make the case that these newer systems do NOT fit into the general population of computational planning systems that Johnston describes, or make the case that the research from MIT that he cites is somehow flawed.
Also please note –
You are getting very close to the ad-hominem type of argument that may work in other forums, but I simply will not tolerate here.
If you want to comment, you will keep the discussion on the technical issues.
MRP was developed to match with what was then the in-thing in factory design — functional departments. So it is not surprising that software designed to plan, worse yet schedule, a physical layout that results in complex and unmanageable flow logistics is not going to work. But, if one looks beyond Toyota for other best practices, around the same time as Toyota, a UK manufacturer, Serck Audco Valves, pioneered the design and operating principles for cellularly-organized (now the term is “Value Stream”) factories. These decentralized and autonomous work groups are small enough that, when needed, they CAN be scheduled with software that Prasad alludes to. I would not suspect the viability of FCS software like that from Preactor!
Mark, I joined this thread only to offer a positive response to your query, “Does anyone have an example of where discrete manufacturing order scheduling of each operation actually gives a workable production plan?”
Great.
I would love to see your example, and understand specifically why it works when so many mainline scheduling attempts fail.
I know that every mainstream ERP implementation out there uses MRP at its core for scheduling, and I have seen one attempt at finite capacity scheduling layered over the ERP, and part shortages are no better – but probably because they don’t have good control or understanding of the underlying algorithms.
What makes pull systems work where MRP does not is that each supplier / customer connection is direct and the small fluctuations in real-world that trip up MRP schedules are smoothly absorbed in a direct-link pull type system.
Of course it has to be set up correctly, and the processes must be planned with adequate capacity, and the system must be sized to handle the anticipated demand levels, but if it is done well, it works well.
If you would like to describe the technical details of how these newer scheduling systems connect supplier and customer processes differently than MRP does, I would like to hear that.
If it is too long for a comment, then click on “Contact Mark” shoot me an email, and we can discuss the details, and the best way to educate my readers.
Hi Mark, Thanks for your interest to look at my example in this context. I already gave you contact information for an example through direct email.
I am one of the harsh crtitics of MRP scheduling. A vast majority of ERP vendors sell poor and inefficient scheduling modules to their customers in high-mix, low-volume (HMLV) environment, which poses difficult problms in planning and scheduling. I used to strongly criticize those scheduling modules on major ERP forums without finding any objection or protest. I often felt that these modules caused immense damage to the notion of computer-based production scheduling. However, there are a few best-of-breed scheduling tools based on rigorous finite capacity scheduling (FCS) logic. Each one of them will work very well in some industries but poorly in some other industries. One has to try them to see their practical merit. These tools also have numerous failures due to many reasons including inappropriate application, inadequate functionality, cumbersome and unfriendly features, and lack of input data, interest, discipline and common sense in the tool usage. Therefore, I always advise industry people to properly evaluate any scheduling software on shop floor with actual data before purchasing it. These tools can bring good benefit wherever they can work well.
For any low-cost scheduling tool which really works well, people on shop floor do not bother about its underlying algorithm. Any powerful scheduling software does require some common sense in its application. Its output is essentially a guideline for production people.
I think that it is best to design a system without computers. Run the system for a year or more. When it works well, then and only then see if computers can do the same thing with less effort.
In other words don’t buy a computer to perform a function that you are not already doing by hand. I have seen many instances where a process was designed with computers in mind and it never worked correctly. But I’ve seen success many times when computers are used to help run a manual process that is already in place.
I agree what has been said in this forum about ERP limitations when it comes to finite scheduling. Regarding the way one can implement a good planning and scheduling tool APS/FCS) depends on what is the level of “intelligence” required to handle the actual scheduling task. If we leave decision making to a production planner and provide him/her a tool which speeds up planning and eliminates human errors that should be enough. For instance if you are satisfied with a tool that automates the scheduling task of a production chain backwards and forwards and takes care of placing an order to a gantt chart automatically based on the promised delivery date why should seek for an expensive optimization software? In most cases planners do not want tools which make them useless.