Software that truly supports good decisions
Download as PPT, PDF1 like544 views
The document discusses the evolution of software designed to support managerial decision making in production planning and scheduling. It traces the development from early MRP software in the 1950s, to OPT in the late 1970s, to the first DBR software packages Disaster and Resonance in the 1980s. While these sought to identify bottlenecks and generate production schedules, they were often too complex, did not fully support the Theory of Constraints approach, and did not distinguish well between planning and execution needs. The document emphasizes that software must be designed based on the inherent simplicity of the environment, support good decisions, and involve domain experts to properly model the relevant aspects of the system.
Software that truly supports good decisions
- 1. Software that truly supports good Software that truly supports decisions good decisions Eli Schragenheim elyakim@netvision.net.il Eli.schragenheim@goldrattgroup.com
- 2. Once upon a time • MRP, a software model, emerged in the mid-fifties to support a major managerial decision: How much, and when, should we release material to the floor • It also highlighted the higher level managerial decision: How much of the finished items we could/should produce in the next time period? • In the “old days” the above question meant: – How many units we are able to produce? • Later, more end items and much more competition led to use forecasting of the demand to base an answer to the latter question
- 3. MRP under inertia • Then, MRP developed the capacity management features – It helped to assess the capacity profile that resulted from the planning • But, it did not really guide management to better decisions – Additional MRP features supported the managerial strive for efficiency • By allowing merging work orders, keeping safety stocks, use large batches and calculate the efficiency measurements • MRP further development was based on a lot of inertia – Using separate bill-of-material and routing files – Every single level in the BOM is treated as a separate work order, losing sight of the customer order – A lot of read-write from the disk
- 4. Then came OPT • OPT was a software developed by Dr. Goldratt and his partners 78-86 • OPT answered the first managerial question, assuming there were real capacity limitations What demand can we supply, taking into account capacity limitations and the required due-dated? • Main assumptions behind OPT – Many times the market demand is really limited by capacity – There are only very few bottlenecks, and only the bottlenecks truly matter in determining the real capacity of the shop floor – Still OPT considered more than one interactive bottlenecks to be the norm
- 5. OPT and the traditional management A recipe for a clash • At first OPT was not focused on supporting a strikingly new management approach • OPT provided good answers regarding the validity of the given master production schedule (MPS) and the resulting overall schedule. Thus supported reaching the maximum throughput for the existing demand • OPT did not care for the efficiency of the work centers – Certain work centers found themselves with much less work than they were able to do • Difficulties in the implementations of OPT revealed a gap between the software and the existing managerial support
- 6. The OPT Thoughtware • Realization of how local optimization thinking tampers the implementation of the software created a need for a new managerial approach • At first the new managerial approach was focused on production and was summarized by the nine rules of OPT • OPT then had a motto: The sum of the local optimums is not equal to the global optimum.
- 7. The Nine Rules of OPT 1. Balance flow, not capacity. 2. The level of utilization of a non-bottleneck is not determined through its own potential but through some other constraint in the system. 3. Utilization and activation of a resource are not synonymous. 4. An hour lost at a bottleneck is an hour lost for the total system 5. An hour saved at a non-bottleneck is just a mirage. 6. Bottlenecks govern both throughput and inventories. 7. The transfer batch may not, and many times should not, be equal to the process batch. 8. The process batch should be variable, not fixed. 9. Schedules should be established by looking at all of the constraints simultaneously. Lead times are the result of a schedule and cannot be predetermined.
- 8. From OPT to TOC • The OPT thoughtware was developed into a comprehensive new managerial approach – The nine rules changed into the five focusing steps – While DBR was developed before the five focusing steps it already marked a departure from a sophisticated algorithm – The critical role of simplicity was recognized in the transition from OPT to TOC • From TOC perspective OPT seemed too complicated and not fully supporting the new managerial thinking • For some time TOC developed without a clear need for any software system – Assuming the simplicity of the message could be handled manually, or by forcing MRP to do the right things
- 9. First DBR software packages • After two years of “no need for software”, Eli Goldratt decided that AGI would develop a real DBR package to support the TOC implementations – The name for the new developed software: Disaster ! – The rational for the name was: if you don’t understand what the software is doing this is what would happen to you! – Based on The Haystack Syndrome, written at that time, a competing software package, called Resonance, was developed as well • By Sanjeev Gupta
- 10. Comments on Disaster • Disaster was focused only on planning – Buffer Management was added much later • It considered the possibility of more than one capacity-constraint resource (CCR) – Which complicated the planning – And added a buffer in between any two interacting CCR operations • The program checked the load on the non-constraints to identify peaks of load that exceeds the time buffers – Then the time buffers were enlarged
- 11. Observations • Disaster and Resonance were conceived as a management support systems for the first three of the five focusing steps – Supporting the identification of the internal CCR – Supporting the exploitation of both the market (due-dates) and the CCRs – The main emphasis was on subordination: • Buffering the exploitation scheme • Maintaining the Rope • Checking that the excess capacity levels are about right
- 12. So, what went wrong? • Too many DBR/TOC implementations of the time did not use either Disaster or Resonance – Many of the TOC experts thought that software is not truly necessary • It was enough to focus on the CCR to generate much better results – Disaster/Resonance/OPT were all linked to the current IT systems (mostly MRPs) and the interface was not easy • Too much garbage in the MRP needed to be cleaned • The linkage back into MRP was tricky • The complicating features of Disaster did not really add value
- 13. Advanced Planning and Scheduling • As computers became more powerful, software programs appear that claimed, like OPT, to provide detailed planning of the supply chain – Identifying bottlenecks seemed to be part of most of the new software programs • But, by year 2000, The penetration of the advanced planning and scheduling (APS) systems seemed to fail – Do we fully understand why? – Master Production Schedule (MPS) could have been benefited a lot from better forecasting and accurate finite capacity scheduling – Managing raw materials could have been greatly benefited from the superior forecasting and the precise timely needs of the production system So what went wrong with the penetration of APS?
- 14. The critical problem caused by APS • One of the basic objectives of production planning is to offer reliable due-dates • However, when Murphy causes a disruption, thus impacting the current schedule, the APS program has to run again producing a very different schedule – The strive for optimal schedule causes a reshuffle of the former schedule, including the safe dates of the orders • Frequent re-planning actually gives rise to the total noise in the system, as observed by Dr. Deming • Hence, management cannot rely on giving safe due-dates to the clients
- 15. The distinction between planning and execution • Planning is a decision process that takes place in advance of most of the resulting actions • Problem is that a lot can happen from the planning until its execution • TOC forces the planning to be focused on the most critical areas for achieving the objectives – Any deviation from those decisions could disrupt the objectives • And TOC adds buffers to the planning, thus protecting the planning from Murphy and other uncertainty incidents
- 16. The distinction between the relevant information of planning and • Execution encompasseexs aellc thue tdieocisnions and actions required to materialize the plan • Due to the uncertainty, most of the buffers, which are included in the plan, are going to be partially consumed • Thus, the actual consumption of the buffers constitutes a set of priorities for the execution to follow – This is known as Buffer Management – Other types of execution control information are the short term capacity analysis, violations of the Rope, quality control etc. • So, any TOC software should make the distinction between the planning and its related information and the execution and its own information
- 17. On the criticality of modeling the environment in the software • There are three necessary conditions for any truly successful implementation of software 1. The software has the right features 2. The modeling of the environment within the software is good enough 3. The users know what to do and how to make the right decisions based on the information provided by the software • We usually do not dedicate enough time to inquire what is the right model to be depicted by the software
- 18. Between too simplistic modeling and too complex • No software model contains all the details of the production shop floor • So, what should be the criteria? – How detailed you need the bill-of-material to be? – Do you really need to model all the tools required at each work center? – Do you wish also to add the details of the manpower? • Eventually we need to understand how the software should support the planning and execution decisions – And keep in mind that the operator will always have some more relevant information that would not be in the software • For instance, what is the level of the pressure put by the client to expedite his order
- 19. A key TOC insight • Every organization is based on Inherent Simplicity • A practical translation of the term for production: – In spite of the huge complexity and the significant uncertainty on top of it, what truly determines the performance of the shop floor is the performance of the weakest link – The concept of the buffer stabilizes the performance and reduces most of the damage of uncertainty – Planning is focused only on the areas where deviations are devastating indeed – The decisions in the execution are based on real priorities, provided by buffer management
- 20. The ramifications of sophisticated software solutions • Opening yourself to develop clever algorithms causes the following NBRs – The developers would initiate their own clever ideas simply because they can do that • Not because it is truly needed – A sophisticated solution is much more sensitive to any change in the parameters • Sensitivity means a small change in one parameter would yield very degraded result • This means you are depended on the quality of the data you put into the algorithm • And what about Murphy? Note, less sensitive solutions means huge fluctuations in the results due to Murphy
- 21. Some facts of life regarding software • Most companies already implemented traditional ERP, where the manufacturing part is MRP based • Implementation of a large software system causes a lot of pain, and most companies are not going to go through it again • In most companies the internal IT people like to be engaged in developing additional software capabilities, either within the ERP or adding Excel programs to interact with the ERP
- 22. A possible direction of solution • The solution should incorporate the current internal IT, maybe with minor changes – It seems critical to involve the local IT people with the decisions and to be part of the solution • An add-on software, fully focused on the TOC processes and decision making, should be used • Resist the temptation of letting the local IT develop the TOC functionality – Two big problems: how to ensure that the developed module is really doing what it should – Ensuring no additions / changes to the software would be introduced, some time in the future, by people without the proper TOC education
- 23. The pros and cons of using Excel • Excel is powerful and relatively easy to use • Thus, many TOC solutions can be easily implemented in Excel and do it right • However the two NBRs mentioned in the last slide are very much evident in Excel: 1. It is VERY hard to debug, especially for people with limited experience in developing software 2. It is an open code, where anyone can enter the code and make changes • And, excel cannot support the long-term process, as it does not force the right terminology and the right focus
- 24. Some TOC insights regarding software • A feature that is not truly needed is causing a lot of damage – It causes miss subordination to the constraint(s) • It could waste time for the use, could confuse the user with irrelevant information and thus cause flawed decisions • Every module should support good decisions, either at the planning phase, or at the execution phase • Software is NEVER sufficient to maintain good system performance – You always have to ensure the people using the software know the logic well – Black boxes do not work well in reality
- 25. An important end note Software is a central tool in maintaining and stabilizing the exploitation and especially the subordination processes