Software that truly supports good decisions

Eli Schragenheim

elyakim@netvision.net.ilEli.schragenheim@goldrattgroup.com

Software that truly supports good decisions

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

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

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

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

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.

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.

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

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

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

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

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

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?

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

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

The distinction between the relevant information of planning

and execution• Execution encompasses all the decisions 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

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 features2. The modeling of the environment within

the software is good enough3. 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

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

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

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

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

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

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 software2. 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

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

Software is a central tool in

maintaining and stabilizing

the exploitation and

especially the subordination

processes

An important end note