|
|
1) Abstract:- The theory of constraint (TOC) is an overall management philosophy the has the basis in the manufacturing environment. It recognizes that organizations exist to achieve goal. TOC then focuses the organizations scarce resources on improving the performance of the constraint & therefore bottom time of the organization. The activities that go on in one “link” are dependent upon the activities that occur in the preceding “link” TOC says that management needs to find the weak link in the chain since “a chain is only as strong as its weakest link. Thus company should focus on the constraint! Introduction :- History:- The creation of TOC is primarily . The effect of one mans Eliyabu Moshe Goldratt. He is physicist by education who become involved with production system design to help a friend who operated Goldratt to design a scheduling system. He marketed the scheduling system in the U.S.A under name OPT. At first the term OPT thought- ware was used but this resulted in confusion between the philosophy & the proprietary software. Then the Synchronous Production was used.Then the synchronous management was used but that that terminology proved confusing. The term that finally emerged is theory of constraints. 2.1 What is TOC? In order to define TOC it is necessary to define the concept of a constraint. A constraint may be anything prevents system from achieving what it can achieve .TOC accepts the existence of constraint at least temporarily & focuses the improvement effort on the TOC uses overlapped production to schedules work through batch production environment. There are five steps to the TOC (which we will see in chapter). In step two the drum buffer management are used. Developing a production planning & control system would be simple. Except for the existence of seemingly random problems & the fort that operations are linked, with operations B henceforth. We shall refer to these problems as the problem of random fluctuations & development events. 2.1 The constraints? The fact that we have bottlenecks is not because we designed the plant poorly. It is a must the performance of the manufacturing organization depends on these constraints. These constraints are: - 1) Internal resource constraint 2) Market constraint 3) Policy constraint FIVE STEPS IN TOC
Step 1 - Identify the System’s Constraint
A constraint is anything that limits the system from realizing a higher performance relative to the system’s purpose. Because time is the primary attribute of meeting the purpose of a project (“…complete as early as possible…improved quicker”), then we must determine what are the tasks and/or resources that determine when is the earliest a project can complete. It is widely accepted that the critical path of a project is the longest chain, in terms of time, of dependent steps. So, if time is the primary measure of a project and the critical path is the longest chain, in terms of time, of dependent steps, then the constraint of a project is the critical path/s. See figure below and note that all numbers are in units of days. In this example the critical path is 60 days (determined by adding up the total times for each chain of dependent steps). The only problem with this conclusion is that there maybe multiple tasks on various non-critical paths which are required to be completed by the same resource. Realistically this resource will work on these various tasks in one of the two following manners at different times until all tasks are complete (also known as multitasking, which is addressed in the subordination step of this process), or in some specified sequence (typically of his/her own choosing), thereby completing a task prior to starting another. In either case, the longest chain, in terms of time, of dependent steps may not be the critical path. Therefore dependencies between steps can be a result of a path and/or a common resource. Since the dependencies between steps is not necessarily a result of a path and oor common resource Since the dependencies between the steps is not necessarily result of a path, then the constraints of the project is not the critical path Therefore the constraint of a project is the longest chain, in terms of time, of dependent steps (where the dependencies are a result of paths and/or common resources). Goldratt states this as the definition for critical chain. See figure below and note that X identifies tasks performed by a common resource, and the dashed line with an arrowhead defines the critical chain (which is determined to be 75 days long versus the 60 day long critical path).
Step 2 - Decide how to Exploit the System’s Constraint
Since the critical chain is the constraint of a project, any time lost on the critical chain is lost forever. As a result the project will complete later than expected and the stakeholders will not reap the benefits as quickly as possible. In contrast, any time gained on the critical chain will improve the chances of the project completing early and the stakeholders will reap the benefits quicker. Therefore, it is imperative to do everything you can to minimize any lost time on the critical chain, and take advantage of any gains in time on the critical chain, i.e. exploit the system’s constraint Before defining solutions to minimize impact of lost time on the critical chain and take advantage of time gained on the critical chain, it would be helpful to understood how projects are traditionally scheduled and executed. Generally a project manager and team identifies the tasks to be completed and the expected time to complete each task. Then they add up the times on each path, identify the critical path, and add the critical path time to the expected start date to determine the expected complete date. The problem begins with the determination of expected time for completing each task. Each resource is typically asked to define how long it will take to complete their specified task/s. The resource estimates the time based on his/her last bad experience, thereby injecting safety time to insure completing the task/s on time. If a particular resource’s boss is responsible for several tasks, this boss will inject another level of safety to insure the task/s will complete on time based on his/her last bad experience. After all the expected task completion times are collected by the project team, then they inflate the estimates by another factor. The reason for this is that it is their experience that management will cut the overall project lead time by a similar factor, so the project will be scheduled to complete sooner. It appears that the higher the uncertainty of anyone making the estimates the larger the safety time factor. It is speculated that the typical project lead time includes about 200% safety time (i.e. a project scheduled for 300 days, has about 200 days safety time estimated). There are two issues here - first, why do projects still run late using this process, and second, isn’t this methodology (of adding as much as 200% safety) counter to the purpose of the project?
Step 3 - Subordinate everything else to above decision/s The next step in this process is to subordinate all other activities (decisions, policies, etc.) to the maintaining and/or improving of the critical chain schedule (i.e. completing the project on time or early by minimizing the impact of Murphy and taking advantage of gains on the critical chain). The Golden Rule of Subordination In order to take advantage of gains made on the critical chain, institute the following rule for project execution: When a task completes on the critical chain (and non-critical chains, if the decision does not effect the critical chain), begin the next task as soon as possible. By adhering to this rule, gains made on the critical chain will not be lost because of the student syndrome. This will then improve the project’s ability to finish earlier (the purpose), and reduce even more the potential effects of Murphy occurring in a following critical chain tasks. Gains on non-critical chains decrease the possibility of non-critical chain Murphy events impacting the critical chain. Resource Contention and Resource Buffers Another issue that can cause a loss of time on the critical chain is resource contention. Resource contention occurs when everything is ready for a task to be started but the appropriate resource is working on something else, thereby causing a delay in starting and finishing the task. In the event of this possibility, locate safety time prior to the tasks this resource is responsible. The safety time should be large enough to insure the resource has at least a 50% chance of finishing the specific tasks on time. This safety time is called a resource buffer. A schedule should be created prioritizing the tasks (the tasks included may be on the critical or non-critical chains of various projects) expected to be in that resource buffer according to the following priority critical chain tasks :----- 1 these tasks should be sorted according to the scheduled project completion dates · tasks that are dependent on each other must be sequenced as they are in the project plan · non-critical chain tasks · these tasks should be sorted according to the scheduled project completion dates · tasks that are dependent on each other must be sequenced as they are in the project plan. Each task on the schedule should be completed prior to beginning the next scheduled task (see exploitation step for discussion of multitasking and its contribution to wasting safety time). In doing this the problem of multi tasking should be resovled. The project team should frequently notify the resource of the progress of the scheduled tasks, so that the resource will be prepared when the tasks are available to be started. This notification should begin no later than the scheduled start date of the resource buffer. The resource can continue to work on other tasks until the scheduled task appears at which time the resource immediately starts the scheduled task and completes it before continuing to perform other work. Now that there is an executable project plan in accordance with the purpose, a methodology to monitor the project and identify problems which may impact completing the project as planned must be developed. Buffer Management Remember, the project buffer was established to protect the project planned completion date. Therefore as the project buffer decreases (which is caused by falling behind schedule on the critical chain), the risk of not completing the project early or on time increases (which is counter to the purpose). The opposite is true as well, if the project buffer increases (which is caused by completing tasks on the critical chain ahead of schedule) the possibility of completing early is increased (which is the purpose). The project buffer decreases by the amount of time equivalent to the current date minus the current critical chain task’s scheduled completion date, if the current date is later than the scheduled date. Note, that the calculation for decreasing the project buffer is based on the fact that time lost on the critical chain is lost forever. The project buffer increases by the amount of time equivalent to the current task’s scheduled completion date minus the current task’s actual completion date, if the actual completion date is earlier than the scheduled completion date. This calculation uses actual completion date instead of current date, because the gain is not realized until the task is actually completed. The feeding buffers can be increased and decreased in the same manner. These buffers provide a focused method for identifying and working only the issues that are causing or may cause time to be lost on the critical chain. If the project buffer is decreasing, then the project team can identify the cause, define and implement solutions.The project team should also monitor feeding buffers and make adjustments before a non-critical chain causes problems on the critical chain. The buffers can be divided into two or three areas, each identifying a level of concern and awareness, and used in prioritizing work. As a history of projects is created using the critical chain methodology, a review of the buffers before and after would be beneficial. If the buffers are consistently larger at the end, then you may want to reduce the buffer sizes at the beginning of
Step 4: Elevate the System’s Constraint
The next step in the process is to elevate the constraint, i.e. reduce the length of the critical chain. Remember that the critical chain is defined as the longest chain, in terms of time, of dependent steps (where the dependencies are a result of path/s and/or common resource/s). Based on this definition, you can reduce the time on the critical chain by either reducing the number of dependent tasks, reducing the time to perform specific tasks, and/or reducing the number dependencies caused by common resources. Any opportunity for improvement should be tested using the ROI calculation. Compare the expected incremental improvement in Net Profit versus the incremental investment required to get that improvement in Net Profit. For companies who are project dependent, this approach should take into consideration the impact of this investment not only on the short term of a specific project or projects but over many future projects (e.g. should you hire additional resources or utilize subcontractors, make large technology investments or rent, out source or train, etc.). For companies who are not project dependent, this approach would take into consideration the impact the investment had on the rare project (e.g. should you contract consultants to manage an ERP Software System implementation project, out source some/all of the project’s tasks to subcontractors, etc.). Reduce the number of dependent tasks It would be expected that every task on any chain or path are necessary to the successful completion of a project. But, a review of the critical chain tasks may provide opportunities for eliminating tasks either because they are no longer valid or through some technological advance, thereby reducing the critical chain of a specific project or projects and/or future projects. Reduce the time to perform tasks Assuming that the tasks are necessary, review common critical chain tasks, identify the reasons for the amount of time required to complete, and implement the appropriate solutions. The solutions may include technology improvements, policy changes, training, etc.. Reduce number of dependencies caused by common resources To reduce the number of dependencies caused by common resources, make more available to perform the tasks. Options to increase the resources available to perform these particular tasks include - hiring, cross training, and/or outsourcing to subcontractors. Any combination of these options applied appropriately may reduce the time required on the
Step 5: Do not allow Inertia to become the system’s constraint. If in the previous steps the constraint is broken, go back to Step 1. Elevating the constraint during an active project could cause the critical chain to move. It is important to be careful to consider the following: · incremental improvement in Net profit versus the incremental Investment required to get that profit (ROI = NP/I) · ability of the new non-critical chain tasks and resources to subordinate to the new critical chain · risks associated with disrupting the project If after elevating the critical chain moves, return to step one and follow the process. Be sure a critical chain is not made longer because of invalid policies, rules or sumptions. If the constraint is not broken and a satisfactory project plan is developed, implement the plan. As the plan is executing, utilize the various rules (such as starting tasks on critical chain as soon as possible and no multitasking), measurements (emphasis on time and overall project completion versus cost and individual task completion), and buffer management techniques to manage the project. In the case where elevation is directed at future projects (especially companies who are project dependent), it must be emphasized - be sure future critical chains are not made longer because of invalid policies, rules or assumptions.
TOC THINKING PROCESS TOOLS ON PROBLEM SOLVING
These tools are logical "thinking tools" (known as a group as the Theory of Constraints (TOC) Thinking Processes). They can be used in standalone situations, or together they form a coherent problem-solving and change management system. Their generic purpose is to translate intuition to a format that can be discussed rationally, questioned without offense, and modified to more fully reflect the understanding of the situation. They are used for the construction of common sense solutions to problems as well as to facilitate communication, collaboration, and consensus among those that must be involved in its resolution. THE CONTEXT:--To put any set of tools in context, they must generally support one of three generic objectives that groups are brought together to accomplish. These three objectives are to determine: WHAT TO CHANGE :--. . . Situation assessment, description of "current reality," and identification of the core problem or conflict and assumptions that sustain it -- diagnosis TO WHAT TO CHANGE TO :--. . . Verbalization of vision/solution and description of strategy to attain the desired state -- prescription, decision making, and solution development HOW TO MAKE THE CHANGE HAPPEN :--. Development of detailed plans and tactics that will clarify what needs to happen and synchronize the efforts of the group in the implementation of the strategy -- planning, team-building The Thinking Processes, based on these two logical constructs, get their power from the fact that the human mind seems to be practically "hard-wired" with an innate understanding of when the "if-thens" or the "in-order-to, we-musts" make sense or not, lending themselves to an ease of communication, scrutiny, and revision. They also benefit from graphical formats and presentation, so the mind can readily take in not only the words of the various entities, but also the spatial relationships implied by connecting arrows.The tools serve to communicate or verbalize the intuition of the participants in a way that lends itself to collaboration and dialogue and results in a description of the "common sense" of the participants.
THE TOOLS Tool 1 -- The Evaporating Cloud The Evaporating Cloud is a construct of necessity logic that takes the form: B) Requirement <----- D) Prerequisite / ^ / | v | A) Objective |/| -- conflict ^ | \ | \ v C) Requirement <----- D') Prerequisite and is read: In order to have objective A, we must have requirement B... In order to have requirement B, we must have prerequisite D... In order to have objective A, we must have requirement C... In order to have requirement C, we must have prerequisite D'... But prerequisites D and D' are in conflict... One of the tenets of the Theory of Constraints, reflecting its roots in the application of the techniques associated with scientific method to those "soft sciences" like management and behavior, is that in any system that is brought together for a purpose, there is no such thing as real conflict, but only unexamined assumptions. The cloud allows a clear statement of the perceived dilemma and provides a route for the surfacing and scrutiny of those assumptions..Also known as a conflict cloud, a dilemma cloud, or a conflict resolution diagram, the Evaporating Cloud provides a solvable verbalization of a conflicted situation where solvable is defined as "win- win." Probably the most multi-purpose of the Thinking Processes, the cloud is appropriate for dealing with tough personal decisions, interpersonal conflict or negotiation (think of requirements as needs and prerequisites as wants), and resolution of what I like to call "systemic conflicts" and by extension, a sort of "root conflict analysis." Speaking of "systemic conflicts," new research/experience in the use of this tool is showing that if a group can verbalize the various dilemmas that they face in dealing with both their day-to-day and long-term efforts via clouds, the results can go a long way to delivering widespread favorable impact on their overall effectiveness. These individual conflicts usually turn out to be systemic conflicts, forcing people between "rocks and hard places" when they try to do the right thing for themselves, their individual departments, or the company as a whole. Often what seems to be the right thing for one of these entities results in a dilemma, the other side of which is doing the right thing for another aspect of the endeavor but that is in conflict with the first action. A group's behavior (its culture as well as its practices) is defined by the accumulation of these dilemmas and how they tend to resolve them. It may sound strange, but when you look at these dilemmas together, they seem to exhibit a "fractal" nature in their self-similarity. There is very often (actually almost always) some generic conflict/dilemma of the larger system that they can be translated to. When this generic conflict is identified and addressed appropriately, it can lead quickly to a coherent and consistent set of actions (including appropriate training, measures, and policies) that will result in the mitigation, if not elimination, of the various individual issues being faced throughout the organization. These various applications of the cloud involve both construction and communication. The different uses imply different starting points for building the cloud. Those approaches are best left for another time (or another venue, like a workshop) If stuck on the proverbial desert island of problem solving, I think it's obvious that the cloud is the tool I would want to have in my pocket, because at the core of almost any problem or decision (either minute and personal or broad and strategic) that one faces (or that a group faces) is the dilemma of doing one thing or another, pursuing one direction or another, going for D or for D', even when its as simple as doing something or doing nothing. The cloud tells you that there really isn't a choice involved at all, it's only a matter of examining the assumptions that make you think there is a choice.
Tool 2 -- The Current Reality Tree (CRT)
The CRT is a sufficiency-based logic (if..., then...) tool that is used to fully describe an existing situation. Its purpose is to understand (only to the level of detail necessary for the group to achieve consensus) how the various issues and problems they face are related to each other, to their policies, measurements, and practices and to the generic/root/core conflict identified through the process I described in the discussion of the Evaporating Cloud tool. This understanding provides the guidance for developing a solution, as understanding why X leads to an undesirable Y provides guidance for inserting new actions to either replace X or to cause it to result in a favorable Z instead. The structure of a CRT is hard to draw in the text based format of email, but consists of connected clusters of statements associated with the situation. The connections are "if..., then..." or "if...and if...and if..., then..." cause and effect relationships. (Graphically, they are statements connected by arrows. Note that I have included similar diagrams in the descriptions of other tools -- FRT and NBR -- below.) These clusters are strung together as effects become causes of other effects. The CRT usually has at it's base a variant of a generic cloud, and higher up in the tree, most if not all of the subject matter's stake holders' symptoms/problems/issues linked in as effects stemming from stuff the root. As we are discussing problem solving tools here, it should be mentioned that from a group participation point of view, the CRT is also thought of as a communication and clarification tool. Its construction is not really suited for a group activity. It is usually best if it is built by one person, or a very, very small group, familiar with the subject matter on their own, and then presented to the group for scrutiny and clarification. An alternative approach to using it is to have the individual members of the group build pieces of a CRT related to their area of expertise, and then use the group presentation and scrutiny to merge the pieces into a whole. Construction of a CRT is best as an individual process, scrutiny and clarification is most effective with group effort and input. A well-built CRT will confirm that your suspect generic conflict (or a modification of it) is indeed at the root of the originally identified problems and it will serve as guidance for developing a new view of future reality (vision) to replace the current. The combination of the core/root/generic conflict (the Evaporating Cloud) and the confirmation of the CRT linking it to the particular range of issues facing the group answers the first question that groups come together to address...WHAT TO CHANGE?
Tool 3 -- The Future Reality Tree (FRT) The FRT is similar to the CRT in structure, but with new proposed actions, policies, and behaviors injected into it in order to create a new vision of the future reality of the system. The power of the logical "if-then" construction is that if any one of the lower-level causes are removed or mitigated, everything that is above it is subject to change. If you can develop various "injections" as new causes, then you can, through restatements of the subsequent logic, predict and direct changes to the resultant effects. The classic example of how this sufficiency logic works is:
A CRT: AN FRT: I have I don't have a fire a fire ^ ^ /|\ /|\ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ / | \ I have I have I have I have I have I don't have fuel ignition oxygen fuel ignition oxygen in contact with the fuel
If any one of the three "ifs" of the CRT are removed or modified, the "then" may be removed from consideration as a problem. We might choose to develop a system in which fuel and sources of ignition are isolated from one another to prevent fires. Or if the problem is that a fire exists, we may choose to remove the oxygen by covering the fire with water, CO2, or a blanket. These are all possible injections. (If only all the "fire-fighting" we do were so clear cut! But maybe it can be almost so.) Even in more complex real-life issues, a careful analysis of assumptions, which in this kind of construction become more "ifs" arrowed into the "then," which become more possible sources for things to remove by the "injection" of new actions, policies, or behaviors. If the CRT is based in a generic conflict, then the initial injection comes from the "out-of-the-5-sided-box" solution of that conflict -- the idea that stems from addressing questionable assumptions. (If the CRT was developed simply from linking the various undesirable effects (as it used to be done in the process before the discovery of the generic conflict's existence), then the core problem at the base of the CRT might be a single statement in the tree. The best way to deal with that result is to do a cloud on that statement.) The objective of the FRT is to communicate a vision of how to change the undesirable effects found in the CRT to desirable effects. Again, like a CRT, construction is best done by individuals or very small groups, while the most effective use of group interaction (and that gains from experienced facilitation) is in scrutiny, clarification, and completion of the solution. The FRT is the first step to address the second step in problem solving, figuring out WHAT TO CHANGE TO.
Tool 4 -- The Negative Branch Reservation (NBR) When a proposal to solve a problem is offered by a member of a group, whether in the form of a seemingly complete FRT or in the form of a standalone idea thrown out on the table, there are frequently concerns or reservations raised on the part of other members of the group. In the lingo of the Thinking Processes, a RESERVATION exists that if we act on an injection in the Future Reality TREE, there will result a BRANCH that leads to an undesirable, NEGATIVE result. Hence, the "Negative Branch Reservation" or NBR. The key to "trimming the negative branch" again lies in the conversion of internalized intuition into logical if-then steps that can be rationally discussed while avoiding the feeling of "constructive criticism" or more blatant "pot-shots" aimed at the proposal. The "if-thens" must link the proposed action with the suspected negative outcome. Then we can again apply assumption searches to the arrows, especially those that are merging arrows, not directly related to the initial proposal, in order to find a new injection - a new arrow that will change the outcome of concern. In the following example, it is determined that by instituting a new policy, we will be able to achieve something good for the organization.
We don't really We may get stuff get the good stuff worse than we have we expect now ^ ^ \ / \ / Desired good The policy may stuff happens be misinterpreted ^ ^^ | / | | / | | ___________/ | | / | | / Not everyone | / in the organization We put a new understands the policy into rationale for the place policy
In this simple negative branch, it's easy to see that to complete the solution, i.e., to get not only the desired good stuff, but to avoid the possible negative consequences of our action we might want to replace the lack of understanding of the policy with another action involving education and explanation of the purpose of the policy. By doing so, we avoid the possible misinterpretation and subsequent bad stuff. As a standalone tool, the NBR ranks right up there with the Evaporating Cloud in everyday usefulness in basic facilitation of problem avoidance. The cloud deals with conflicts and dilemmas and the NBR deals with doubts and concerns. They both aid communication so that the conflict or concern can be effectively and efficiently dealt with. In terms of group accomplishment, the NBRs brought up by group members serve to complete the solution developed in an FRT. It also provides a route to buy-in for participants as their contribution to the solution (in the form of actions required to trim their NBRs) gives them a sense of ownership of (at least part of) the overall solution. Actually, even if starting with a single proposal, the identification and solution of NBRs could result in an FRT built on that proposal as open and unguarded discussion of concerns builds upon it. (Some "system-thinking" aficionados may see similarities to FRTs and NBRs in causal loops. Indeed, complete CRTs and FRTs for complex systems do frequently contain loops of causality. In CRTs, these loops most often serve to perpetuate undesirable stuff. In well-designed FRTs, loops will be consciously looked for and strengthened so that they will contribute to getting more and more of the desired outcomes.) The combination of the FRT and NBRs completes the answer to the group objective of determining TO WHAT TO CHANGE TO.
Tool 5 -- The Prerequisite Tree (PRT) OK. We have a solution defined in terms of a vision and strategy that should achieve it (the complete FRT, augmented by the results of adding injections to trim NBRs), but we also have a whole pile of stuff blocking us from doing this part or that part of the strategy. Indeed, for some of the things we've identified as injections in the FRT, we may have no idea whatsoever how to make happen. People are great at finding excuses why something can't be done. In more politically correct language, we refer to that skill as identifying obstacles. The Prerequisite Tree (PRT) takes advantage of people's natural propensity and ability to point out why something can't get done. The first step in building a PRT (after identifying the team's ambitious objective) is to collect all the obstacles that the group can come up with. Then each individual identifies an "intermediate objective" (IO) that would overcome or make moot the obstacle they raised. (After all, the person who comes up with an obstacle has the most intuition about what it would take to address it.) Once all the IOs are identified, the obstacles are used to sequence the IOs into a network that becomes the plan to achieve the objective. Team effort is focused appropriately, since the network points the group to start on those IOs that don't depend on others, and only when they are done, they know they can move on to the next because they've overcome an obstacle that was blocking them. A PRT defines what needs to be done (necessity logic) in what order to accomplish the ultimate ambitious objective. This is a painless way of identifying which "bites of the elephant" we'll gnaw on first in our attempt to consume the whole thing. As a group effort, this process benefits (as does the solicitation of NBRs as reasons we shouldn't take a particular path of action) from the diverse and divergent views of the group's members. The more obstacles that are raised, the more complete the implementation plan of HOW TO MAKE THE CHANGE HAPPEN will be, resulting in fewer surprises along the way.
Tool 6 -- The Transition Tree (TRT) This last tool further supports the need to describe HOW TO MAKE THE CHANGE HAPPEN. Sometimes a plan is developed by a group for other people to use. Sometimes getting from one IO in a PRT to another requires a finer level of detail in terms of action and results. Including the TRT here for completeness of the list of TOC Thinking Processes, it may be a stretch to think of it as a facilitation tool, as it's really a communication and empowerment tool, allowing the recipient of it to follow a path of action with clear understanding of what to expect along the way and why to expect it. It is a simple repetitive sufficiency logic construct that puts the actions/tasks in context with the objectives. Based on simple, "if-then" links, the Transition Tree includes the need for action, the action, the rationale for the action, that desired, expected result and then reason for the next need in a graphical format: Result (IO) ^ ^ ^ / | \ Action Need Rationale ^ ^ | \ | \ Result Reason for (IO) next need ^ ^ ^ / | \ / | \ Action Need Rationale
The transition tree includes all the info you need to build a detailed action plan, assess its ability to deliver results, and includes those results to allow development of alternative actions...a real "results-oriented" task list that encourages "empowerment" to offer new solutions. It sure beats a simple "Do this, then do that, then..." list of tasks that we usually get for instructions.
DRUM-BUFFER-ROPE SCHEDULING The concept of drum-buffer-rope is as follows; Ideally, all nonconstraint stations preceding the constraint on a part’ system routing should being production of part as soon as the part is released to the first station on routing. Thus, parts move very quickly from material release to the constraint buffer. The parts then wait for an indeterminate time in the constraint buffer until the constraint begins to process the part. Once the constraint begins to process the part, ideally all nonconstraint on the routing between the constraint and the shipping dock should also set up for the part, So the part is moved once unit at the time to the shipping point. Thus, drum-buffer-rope schedule development consist of two stages. First, develop a derailed schedule for the constraint ifself,this schedule is called the drum. Second,determine how much time is to be allowed for material to move from material to move from material release to the constraint and, for each and item, how much time should be allowed for material to move from constraint to shipping. This time offset is called the rope, because it links mate-rial release to the constraint so the constraint can pull forward the material as it needs it. A rope also pulls material forward from the constraint to shipping (or, in the case of a good that does not require processing at the constraint, the rope pulls material from release to shipping ). The material that is scheduled to be at the constraint at any point in time is called the constraint buffer. Material that is scheduled to be at shipping at any point in time is called shipping buffer. This description should make clear the origin of the name drum-buffer-rope. There is a second rope that pulls material from the constraint to the ship-ping dock. The length of this rope is equal to the length of the shipping buffer, which is a buffer maintained to protect the shipping schedule. Although each product may have a distinct shipping buffer size, there is usually only one internal constraint and, hence, only on internal constraint duffer size. The unit of measure for the shipping buffer is units of end item. Drum-buffer-rope scheduling thus reduces to: (1) identify the constraint (2) Sequence jobs on the constraint, (3) Decide on the size of the constraint buffers (which fixes the length of the rope from the constraint to material re- lease), (4) Decide on the size of the shipping buffers (which, in effect , for-ward schedules material from the constraint shipping and fixes the promise date to the customer). The job of shop scheduling, thought by most researchersto be extremely complex,is thus reduced to a simple single machine scheduling problem. The simplicity of the problem is conditional on the shop having one or more no internal constraints. A common objection to theory of constraints is the notion that are many interacting constraints in a shop. This notion really is not true. Although most companies that have implemented TOC initially believed they had many constraints, all have found that they had few resource constraints, that they rarely interacted, and that moving the constraint to the market is much simpler than they thought. The schedule created by drum-buffer-rope is entirely provided that the constraint is never permitted to go idle and the efficiency and utilization of the constraint are approximately as predicted. Buffer management, discussed in the next section, is intended to insure the constraint is used as planned, assuring schedule performance.
BUFFER MANAGEMENT There are three types of buffers present in the theory of constraint, two of which have been discussed. The constraint buffer protects the constraint, the shipping buffer protects the promised due date delivery. There is also an assem-bly buffer, which stages nonconstraint parts at assembly points with constraint parts so that constraint parts are never delayed for lake of nonconstraint parts. If all buffers in the shop have the correct material in them at all times and never have material that is not supposed to be there, the shop must be operating on schedule. Any schedule deviation will cause expected material to be missing from the buffer. Management using the theory of constraint is a type of management by exception that reacts only when material is missing from the buffer. Suppose the constraint is scheduled to product the following parts in the next week.
Part Time Units
A 7.5 hours 150 B 8.5 hours 200 C 7 hours 100 D 17 hours 300
Suppose further that the constraint buffer is set to 16 hours. Then, at present, all 150 units of A and all 200 units of B should be in the buffer. For buffer management purposes, the buffer is logically divided into thirds. At present, one-third buffer is above 5 hours. We might choose to call Region I-5 hours, Region II-6 hours, and Region III-5 hours. We could repre-sent this buffer as a visual display The vertical axis shows minutes, each letter represents a vertical distance of 15 minutes, the horizontal axis shows hours, the numbers on the next to last row represent hours in the future, from 1 to 16. Note that the hours 10 through 16 are identified only by the last digit Indicates that for the next 7,5 hours, the constraint will process A and for 8.5 hours after that it will process B, consistent with the schedule presented earlier. As sum that the letter ( A or B) is colored green if the required material is present the buffer and red if the material has not yet been reported as been present at the buffer. Note that this visual could be kept up to date at all times simply by having a PC or a terminal in the constraint area and having the material handler log material in and out as material supply moved. Then anyone walking by the constraint area and glancing at the display could determine in a glance whether the constraint was properly protected . For that matter, with the constraint hooked to a network of PCs or to a central computer, it would be possible for anyone in the plant having access to a PC or a terminal to check the status of the constraint buffer at any time. A red letter occurring in region I of the buffer would literally raise a red flag that immediate expediting is required. A red letter occurring in region II material is taking somewhat too long to move to the constraint. Investigative and corrective action is required, although expediting is not yet indicated. In theory of constraints terminology a hole in the buffer occurs whenever material that should be in the buffer is missing. The shipping buffer and assembly buffer can created and managed in a fashion analogous to the constraint buffer. The size of the buffer is a function of the degree of variability that exists within the shop and of the extent to which nonconstraints are loaded. If the shop has some machines with long setup times, others that break down quite frequently, and nonconstraint machines that are loaded quite heavily, then a large buffer is required to protected the constraint and to permit ample time for jobs to move from shipping to the constraint. Whenever a hole occurs is Region I or Region II of the buffer, the cause of the hole investigated and recorded. Those problems that must frequently appear on the list of causes, such as long setups at machine X or long breakages at machine Y, are high priority items for corrections. It is also important to not that buffer management is a complete shop floor control system, provided that nonconstraint stations on their ability to keep material moving on schedule in to the buffer. In the next section we discuss the use of local performs measures that are constraint with global objectives.
Toc & Performance Measurement A logical question becomes what performance measures should be used by a company operating under the theory of constraint? It is easy to criticize exiting measures, but some performs measures is necessary so that management can properly do its job. The most important performance mea-sure is performance to schedule. Performance to schedule implies that pieces are not made early and they are not made late. Therefore, two performance measures are required, one to measure things done ahead of schedule and a second to measure things done behind schedule. The theory of constraints sug-gests inventory dollar days as a measure of things done ahead of schedule (and hence inventoried) and throughput dollar days as a measure of things done behind schedule. A dollar day is simply one dollar held for one day. If you borrow money from a bank to finance your education or a car, you pay for the use of that money on the basis of the amount you borrowed and the length of time you held the money—dollar days. It makes sense to value inventory that is built ahead of schedule on the basis of dollar days. In essences the company has loaned the using department the resources needed to make the inventory. The department should repay the company based on the dollar tied up in inventory and the length of time the money is held as inventory. It also makes sense to measure shipments that are delayed on the basis of dollar days the delay in shipment will probably result in delay in payment and the number of days that payment is delayed because of late payment Note that this process has two important features, First, the measure is consistent with the actual cost to the company for the mistake that was made. Second, as the problem becomes corrected, the penalty for the mistake is eliminated. Consistency is important so that decisions made on the basis of local interest do not have a negative impact on the of local interest do not have a negative impact on the entire company. The problem with machine utilization as a measure at nonconstraint station is that it is not consistent; there is incentive for the station to produce inventory that is not needed. The elimination of the penalty as the mistake is eliminated is important because it provides an incentive for the workstation to operate efficiently whenever there is work available. The effect of using inventory dollar days and throughput dollar days on a nonconstraint is as flows when work arrives, the worker will verify that the job appears on one of the buffer documents. As long as the job appears on one of the buffer documents, the worker will not be charged inventory dollar days for processing it. Throughput dollar days are computed from the midway point in the buffer. If the work on hand has not reached the midpoint of the time buffer, the worker can avoid any dollar days penalty by processing the job and passing it along before the halfway marker is reached. If the work has reached the halfway mark, the worker is charged throughput dollar output until the work is passed to the next station. The worker has incentive to work quickly either to avoid throughput dollar days or to eliminate and existing dollar day charge. The use of inventory dollar days is particularly effective in tendency on the part of workers to get material early in order to avoid idle time, This tendency is a habit in most shops that have been evaluated on the basis of machine utilization, and the habit will require some effort to break. With the new measure, the worker should soon realize that not only is it not good to work ahead of schedule but that such action will actually incur a penalty. To summarize this section, throughput dollar days and inventory dollar days provide an incentive for workers to flows schedule an to work quickly and careful. They are constraint performance measures in that if the performance of a particular station improves with respect to a measures, the performance of the entire shop most also improve. The performance measures would also work will with an MRP system or a JIT system provided that all workers are made aware of the schedule to be followed.
Comparison of TOC with MRP and JIT 01 Balance capacity and then try to balance Balance capacity and then try to balance Balance flow, not capacity 02 Level of utilization of any worker is determined by its own potential Level of utilization is determined by market demand Level of utilization of any bottleneck isn’t own potential but by some other constraint in the system 03 An hour lost at bottleneck is an hour lost at that resource
---
An hour lost at bottleneck is an hour lost for the entire system 04 Bottleneck temporarily limits throughput but has little impact on inventories Per etermined inventory buffer regulate the rate of production for assembly line and Kanban system. Significant disruption. Causes entire system to stop An hour lost at a nonbottleneck is a mirage, and counts for nothing 05 Splitting and overlapping of batches should be discouraged JIT process one at a time Bottlenceck governs both throughput and inventory
06 process batch should be constant both in time and along its route Process batch and tranfer batch are same. We process one at a time Transfer batch may not/should not equal to process batch. Process batch should be variable. 07 Schedule should be determined by sequentiality Schedule is determined by market demand Capacity constraint resource dictate the schedule based on market demand and its own potential 08 Only way to reach global optimum is by ensuring local optimum
-- Sum of local optimt on is not equal to global optimum.
TOC cast accounting As per APICS, it is defined as a cost and managerial accounting system that accumulates cost and revenues into 3 ares-throughput, inventory and operating expense. It does not create incentives (through allocation of overhade) to build up inventory. The system is considered to provide a truer reflection of actual revenues and cost than traditional cost accounting. TOC accounting provides and simplified and more accurate method that subtract true variable cost (those costs that vary with throughput quanitity.) Unlike in traditional cost accounting system in which the focus is generally placed on reducing cost accounts, the primary focus of TOC account is on aggressively exploring the constraints to make more money for the firm. In the traditional approach, we calculate cost/hr of work centers in isolation taking into consideration that particular work centers operating expenses/hour. Is it a correct method? If the bottleneck center fails for an hour we will be loosing throughput of the total plant for an hour. It is much higher than the amount calculated for that specific work center. In TOC, all these measures are in terms of money – measurement for incoming money (throughput), inventory for money still stuck inside, and one for money going out (operating expenses). TOC says that these three measures are sufficient for us to make the bridge between Net profit (NP) and ROI and the managers daily actions. NP = The-OE ROI = (The-OE)/1 With these three measures (The,I,OE), we can no the impact a decision has on company’s bottom line. The ideal decision will be the one, which increases T and decreases I and OE. But any decision that has a positive impact on ROI is the decision that takes the company towards its goal. The final critera that decides if it is a good decision or not is ROI.
Case study ? There are two workers producing four product. The plant works three shifts. The market demand is unlimited and takes all the products that the workers can produce. The only stipulation is that the ratio of products sold cannot exceed 10 to 1 between, if the maximum sold of any one of the products is 100 units, the minimum of any other cannot be fewer than 10 units. Workers 1 and 2 ,on each shift,are not cross-trained and can only work on their own operations. The time and raw material (RM) costs are shown in the exhibit, and a summary of the cost and times involved is on the lower portion of the exhibit. Weekly operating expenses are $3,000. What quantities of A,B,C, and D should be produced?
solution As in the previous example, there are three answers to this questions , depending on each of the following objectives: 2. Maximizing revenue foe sales personal who are paid on commission. 3. Maximizing per unit gross profit. 4. maximizing the utilization of the bottleneck resource (leading bto maximum gross profit). Objective1: Maximizing sales commission on sales revenue . sales personal prefer to sell B and Drum-buffer-rope (selling price $32)rather A and C ( selling price $30). Weekly operating expenses are $3,000. The ratio of units sold will be : 1A: 10B :1C :10D. Worker 2 on each shift is the bottleneck and therefore determines the output.4 5 days/week * 3 shifts * 8 hours * 60 minutes= 7.200 minutes per week available worker 2 spends these times on each unit: A 20 minutes B 20 minutes C 20 minutes D 30 minutes The ratio of output units is 1: 10: 1: 10.therefore 1x(20) + 10x(20)+ 1x(30) = 7,200 550x = 7,200 x = 13.09 Therefore , the numbers of units produced are A = 13 B = 131 C = 13 D = 131 Total revenue is 13(30) + 131(32) +13(30) + 131(32) = $9,164 per week. Gross profit per week (selling price less raw material less weekly expense ) is 13(30 –18)+ 131(32-22) + 13 (30 – 18) +131 (32-22) – 3,000 = 156 + 1,310 + 156 + 1,310 – 3,000 = ($68)loss. Gross selling Raw Material Profit = Price - cost
A 12 = 30 - 18 B 10 = 32 - 22 C 12 = 30 - 18 D 10 = 32 - 22
A and C have the maximum gross profit so the ratio will be 10 : 1: 10:1 for A,B,C and D .worker 2 is the constraint and has 5 days *3 days * 8 hours *60 minutes = 7,200 minutes available per week As before ,A and B take 20 minutes , while constraint and b take 30 minutes .Thus 10x(20) + 1x(20) + 10x(30) + 1x(30) = 7,200 550x = 7,200 x = 13 Therefore , the number of units produced is A= 131 B= 13 C = 31 D = 13 Gross profit (selling prioce less raw materials less $3,000 weekly expense) is 131(30-18) + 13(32-22) +131( 30-18) + 13(32-22) - 3,000 = 1,572 +130 +1,572 +130-3,000 = $404 profit Objective 3: Maximizing the use of the bottleneck resource, worker 2, For every hour worker 2 works , the following number of products and gross profit result
(1) (2) (3) (4) (5) (6) Units selling Gross Profit Production Produced Price Raw Material Per hour Product Time Per hour each Cost Per Unit (3)*[(4)-(5)]
A 20 minute 3 $30 $18 $36 B 20 3 32 22 30 C 30 2 30 18 24 D 30 2 32 22 20
Product A generates the greatest gross profit per hour of worker 2 time , so the ratio is 10:1:1:1 for A,B,C ,and Drum-buffer-rope Available time for worker 2 is the same as before: 3shifts * 5 days *8 hours *60 minutes = 7,200 minutes Worker 2 should produce 10 As for every 1 B, 1C, and 1D, Worker 2’supply average production rate is 10x(20) + 1x(20) + 1x (30) + 1x(30)= 7,200 280x =7,200 x=25.7 Therefore, the number of units that should be produced is A=257 B=25.7 c =25.7 D= 25.7 Gross profit (price less raw materials less $3,000 weekly expenses)is 257(30-18) + 25.7(32-22) +25.7(30-18) + 25.7 (32-22) – 3000 = 3,084 + 257 +308.4 +257 – 3,000 = $906.40 In summary, using three different objectives to decide how many of each product to make gave us three different results:
1. Maximizing sales commission resulted in a $68 loss in gross profit. 2. Maximizing gross profit gave us a profit of $404. 3. Maximizing the use of the capacity- constrained worker gave us the best gross profit, $906.40.
Conclusion In a sense, the theory of constraints makes the decision-making process much easier. Most managers have an almost endless set of data to track and potential improvement efforts to consider. By identifying those problems that have the greatest impact on the constraint, a manager can limit the amount of data that must monitored and also postpone consideration of certain, a manager can limit the amount of data that must be monitored and also postpone consideration of certain improvement efforts. At the same time, the amount of information that must be passed around the organization can be reduced, as a lot of detail concerning nonconstraint activities can simply not be transmitted. Constraints or bottlenecks in any operation are the root cause of low productivity and hence, low profitability. The entire concept of TOC, is not geared to decrease operating expense as a means to improve profitability, but is instead, focused on increasing throughput.
REFERENCES
1: Xerox from MM-magazine
2: www.rogo.com
3: www.ciras.com
4: www.indiatimes.com
5: Production and Operations Management (Manufacturing and Services)