Don’t Waste Your Time with a Functional Spec

Recently I was called in as an independent third party in a dispute between a modeler and a stakeholder. The stakeholder said “I have significant experience in both my application and modeling and I know what I want, but I am not getting it.” The modeler said “I have been modeling for 30 years and I know exactly what the stakeholder needs, but he just won’t listen to me!

It was obvious that they weren’t communicating well, but not so obvious why two such highly experienced people were at such odds. So my first question was “What was written in the functional specification?” You might guess the answer … “What functional specification?

My second question was “Well then, what did the contract say?” The answer again was unfortunately along the lines of “I’ll give you $x to model this” (refer to a recent blog of mine on this topic).

So in hindsight it is pretty easy to see where the misunderstanding came from. They had not agreed on model scope, approach, animation, units of measure, or even basic modeling objectives! Of course that leaves lots of room for experienced professionals to interpret the problem in totally different fashions and end up with totally different approaches to the problem.

Many people think that doing a functional specification (FS) is a waste of time. But a FS is rarely extra work. Rather it is work that must be done at some point and if it is done early it can have tremendous positive impact on project success. A FS is almost never a waste of time — even if the project is cancelled as a result of the FS, it is better to have “wasted” a few hours on the FS, rather than to have wasted significantly more time on the project before enough was learned to cancel it.

So who was right? I don’t even need to discuss the technical merits. In my perspective it comes down to two things:

1) A modeler who embarks on a journey with little clue where he is heading (an FS) is setting himself up for failure. An experienced modeler should know better.
2) While it is certainly the responsibility of the modeler to attempt to educate and persuade a client of the best approach, ultimately the customer is the one who decides if the project is successful, not the modeler. So in the end, the customer is always right.

Happy Modeling!

How Much Data Do I Need?

I have discussed data issues in several previous articles. People are often confused about how much data they really need. In particular, I frequently hear the refrain “Simulation requires so much data, but I don’t have enough data to feed it.” So let’s examine a situation where you have, say 40% of the data you would like to have in order to make a sound decision and let’s examine the choices.

1) You can possibly defer the decision. In many cases no decision is a decision in itself because the decision will get made by the situation or by others involved. But if you truly do have the opportunity to wait and collect more data before making the decision, then you must measure the cost of waiting against the potential better decision that you might make with better data. But either way, after waiting you still have all of the following options available.

2) Use “seat of the pants” judgment and just decide based on what you know. This approach compounds the lack of data by also ignoring problem complexity and ignoring any analytic approach. (Ironically enough this approach often ignores the data you do have.) You make a totally subjective call, often heavily biased by politics. There is no doubt that some highly experienced people can make judgment calls that are fairly good. But it is also true that many judgment calls turn out to be poor and could have benefited greatly from a more analytical and objective approach.

3) Use a spreadsheet or other analytical approach that doesn’t require so much data. On the surface this sounds like a good idea and in fact, there is a set of problems for which spreadsheets are certainly the best (or at least an appropriate) choice. But for the modeling problems we typically come across, spreadsheets have two very significant limitations: they cannot deal with system complexity and they cannot adequately deal with system variability. With this approach you are simply “wishing away” the need for the missing data. You are not only making the decision without that data, but you are pretending that the missing data is not important to your decision. An oversimplified model that doesn’t consider variability or system complexity and ignores the missing data … doesn’t sound like the makings of a good decision.

3) Simulate with the data you have. No model is ever perfect. Your intent is generally to build a model to meet your project objectives to the best of your ability given the time, resources, and data available. We can probably all agree that better and more complete data results in a more accurate, complete, and robust model. But model value is not true false (valuable or worthless) but rather it is a graduated scale of increasing value. Referencing back to that variability problem, it is much better to model with estimates of variability than to just use a constant. Likewise a model based on 40% data won’t provide near the results of one with all of the desired data, but it will still outperform the analytical techniques that are not only missing that same data, but are also missing the system complexity and variability.

And unlike the other approaches, simulation does not ignore the missing data, but can also help you identify the impact and prioritize the opportunities to collect more data. For example some products have features that will help you assess the impact of guesses on your key outputs (KPIs). They also have features that can help assess where you should put your data collection efforts to expand sample or small data sets to most improve your model accuracy. And all simulations provide what-if capability you can use to evaluate best and worst case possibilities.

Perfection is the enemy of success. You can’t stop making decisions while you wait for perfect data. But you can use tools that are resilient enough to provide value with limited data. Especially if those same tools will help you better understand the value of both the existing and the missing data.

Happy modeling!

Dave Sturrock
VP Operations – Simio LLC

General Simulation Project Approach

People often wonder “When is the best time to incorporate simulation into a project?” The answer, without a doubt, is at the earliest possible moment — when an idea for a significant system change or major investment is first being discussed. While it is true that at this early point in a project there are many unknowns and often very little data, simulation can still provide significant value with often a very low level of effort. While the specific issues obviously vary based on the exact systems, at these early stages you are often looking for gross measures of capacity planning and throughput analysis, impact on other facilities, and early identification of potential problem areas.

With modern tools, you can often create high-level simulation models to study such issues in not much more time than it might take to develop a comparable spreadsheet. But instead of using a spreadsheet that is limited to often misleading static analysis and fairly simple relationships, simulation can take full account of the variation and complexity present in most real systems. And as the project concepts mature, the simulation can expand and mature along with it and continually provide value at each step of the project.

For example a project might go through phases with typical questions like these:

1. Early concept validation – How will this new system work? What is the estimated capacity and throughput? What impact will this have on existing facilities? How can I communicate potential issues to stakeholders?

2. High-level system design – What components should be included? What are realistic design objectives? Evaluation of trade-offs of various investments and level of capability provided. High-level bottleneck analysis. Identify “surprises” while they are still easy to deal with.

3. Detailed system design – What specific equipment should be used (e.g., degree and type of automation)? What procedures should be implemented? What reliability can be expected and how will that impact performance and costs?

4. Implementation –Does the system perform as expected and if not, why not and how can it be “fixed”? What is the optimal staffing? When is a “change order” worthwhile?

5. Start-up – What is the impact of learning curves? What are realistic expectations during transition to full capacity? How long will that transition require? What special procedures should be put in place during that transition, what is their cost, and how soon can they be phased out?

6. Operation – How to plan and schedule the intermediate and short-term facility operation? How to effectively deal with the variability present in all systems (e.g., equipment and personnel problems, demand variation, shifting priorities, …)? How well is the system performing on the actual demand as opposed to the originally anticipated or “optimal” demand?

7. System improvement/re-design – As the system reaches stable operation, new ideas, procedures, and technologies will occur. What would be the impact of incorporating changes? Which changes have the best ROI? How do the changes relate to each other?

Until next time … Happy Modeling!

Simulationist Bill of Rights

In the Simulation Stakeholder Bill of Rights I proposed some reasonable expectations that a consumer of a simulation project might have. But this is not a one-way street. The modeler or simulationist should have some reasonable expectations as well.

1. Clear objectives – A simulationist can help stakeholders discover and refine their objectives, but clearly the stakeholders must agree on project objectives. The primary objectives must remain solid throughout the project.
2. Stakeholder Participation – Adequate access and cooperation must be provided by the people who know the system both in the early phases and throughout the project. Stakeholders will need to be involved periodically to assess progress and resolve outstanding issues.
3. Timely Data – The functional specification should describe what data will be required, when it will be delivered and by whom. Late, missing, or poor quality data can have a dramatic impact on a project.
4. Management Support – The simulationist’s manager should support the project as needed not only in issues like tools and training discussed below, but also in shielding the simulationist from energy sapping politics and bureaucracy.
5. Cost of Agility – If stakeholders ask for project changes, they should be flexible in other aspects such as delivery date, level of detail, scope, or project cost.
6. Timely Review/Feedback – Interim updates should be reviewed promptly and thoughtfully by the appropriate people so that meaningful feedback can be provided and any necessary course corrections can be immediately made.
7. Reasonable Expectations – Stakeholders must recognize the limitations of the technology and project constraints and not have unrealistic expectations. A project based on the assumption of long work hours is a project that has been poorly managed.
8. “Don’t shoot the messenger” – The modeler should not be criticized if the results promote an unexpected or undesirable conclusion.
9. Proper Tools – A simulationist should be provided the right hardware and software appropriate to the project. While “the best and latest” is not always required, a simulationist should not have to waste time on outdated or inappropriate software and inefficient hardware.
10. Training and Support – A simulationist should not be expected to “plunge ahead” into unfamiliar software and applications without training. Proper training and support should be provided.
11. Integrity – A simulationist should be free from coercion. If a stakeholder “knows” the right answer before the project starts, then there is no point to starting the project. If not, then the objectivity of the analysis should be respected with no coercion to change the model to produce the desired results.
12. Respect – A good simulationist may sometimes make the job look easy, but don’t take them for granted. A project often “looks” easy only because the simulationist did everything right, a feat that in itself is very difficult. And sometimes a project looks easy only because others have not seen the nights and weekends involved.

Discussing these expectations ahead of time can enhance communications and help ensure that the project is successful – a win-win situation that meets everyone’s needs.

Dave Sturrock
VP Products – Simio LLC

Simulation Stakeholder Bill of Rights

The people who request, pay for, consume, or are affected by a simulation project and its results are often referred to as its stakeholders. For any simulation project the stakeholders should have reasonable expectations from the people actually doing the work.

Here I propose some basic stakeholder rights that should be assured.

1. Partnership – The modeler will do more than provide information on request. The modeler will assume some ownership of helping stakeholders determine the right problems and identify and evaluate proposed solutions.
2. Functional Specification – A specification will be created at the beginning of the project to help define clear project objectives, deadlines, data, responsibilities, reporting needs, and other project aspects. This specification will be used as a guide throughout the project, especially when tradeoffs must be considered.
3. Prototype – All but the simplest projects will have a prototype to help stakeholders and the modeler communicate and visualize the project scope, approach, and outcomes. The prototype is often done as part of the functional specification.
4. Level of Detail – The model will be created at an appropriate level of detail to address the stated objectives. Too much or too little detail could lead to an incomplete, misunderstood, or even useless model.
5. Phased Approach – The project will be divided into phases and the interim results should be shared with stakeholders. This allows problems in approach, detail, data, timeliness, or other areas to be discovered and addressed early and reduces the chance of an unfortunate surprise at the end of a project.
6. Timeliness – If a decision-making date has been clearly identified, usable results will be provided by that date. If project completion has been delayed, regardless of reason or fault, the model will be re-scoped so that the existing work can provide value and contribute to effective decision-making.
7. Agility – Modeling is a discovery process and often new directions will evolve over the course of the project. While observing the limitations of level of detail, timeliness, and other aspects of the functional specification, a modeler will attempt to adjust project direction appropriately to meet evolving needs.
8. Validated and Verified – The modeler will certify that the model conforms to the design in the functional specification and that the model appropriately represents the actual operation. If there is inadequate time for accuracy, there is inadequate time for the modeling effort.
9. Animation – Every model deserves at least simple animation to aid in verification and communication with stakeholders.
10. Clear Accurate Results – The project results will be summarized and expressed in a form and terminology useful to stakeholders. Since simulation results are an estimate, proper analysis will be done so that the stakeholders are informed of the accuracy of the results.
11. Documentation – The model will be adequately documented both internally and externally to support both immediate objectives and long term model viability.
12. Integrity – The results and recommendations are based only on facts and analysis and are not influenced by politics, effort, or other inappropriate factors.

Note that every set of rights comes with responsibilities. The associated stakeholder responsibilities are discussed as part of the Simulationist Bill of Rights.

Give these expectations careful consideration to improve the effectiveness and success of your next project.

Dave Sturrock
VP Products – Simio LLC

Human Judgment Beats Simulation

Human Judgment, also known as Seat Of The Pants Analysis (SOTPA), is probably the least acknowledged but most widely used alternative to simulation. SOTPA is making decisions by instinct and feelings rather than using objective analytical tools. With SOTPA you never actually have to get out of your chair, or even spend any significant time to reach a decision.

I use SOTPA all the time and you probably do too.

When I am in a hurry to go out and want to know if I should wear a jacket or bring an umbrella, I might take a quick look out the window, reflect on the season and yesterday’s weather, then make a decision. That’s SOTPA. I know that there is a high likelihood that I will be wrong, but I don’t want to take the time to do the weather channel research to get more objective information.

Human judgment beat simulation in this case. But not always.

When I am going on an all-day outside outing and have the same decision to make; the importance of being correct increases. In that situation I will take the time to consult at least two weather sources and even step outside for some direct research. With this objective analysis I can make a more informed decision. Although such an analysis is never perfect, including objective data in my analysis dramatically increases the likelihood that my decision will be correct.

Now let’s say I am a manager and my staff comes to me proposing purchase of a new piece of equipment to solve an important problem in my facility. They may give me technical specifications, maybe some manual or spreadsheet calculations, perhaps even show me a case study about how that equipment was used in another facility. The easy thing for me to do at that point is to make a SOTPA-based decision. After all, I must be pretty smart to get to be a manager, right? Right?? 🙂 And I know THE BIG PICTURE. So who better than me to make the decision? And why should I need more information?

If you haven’t read it, I’d suggest you pause now and read the blog on Predicting Process Variability. Did you pass the test? Don’t feel bad, almost no one does. My facility is much more complicated than that one. If I cannot predict the performance of such a simple system, why should I expect that I can predict the impact of adding this proposed equipment to my facility?

“But I don’t have time to simulate.” I don’t have time to research weather when the penalty of being wrong is low, but I make the time to do it when the penalties are higher. With modern simulation tools you can often get valuable results in a short period of time. In two or three days you can often provide an objective analysis that can save a few hundred thousand dollars. Let’s see, invest $3000, save $200,000 … I think I can make the time for that. How about you?

Simulation beats human judgment when it matters.

When someone else uses SOTPA you might say they bent over and pulled the answer out of their… um, … er, shoe. “What was he thinking?” Don’t let that be you.

Reserve SOTPA for decisions that don’t matter. Use simulation for the decisions that do.

Dave Sturrock
VP Products – Simio LLC

Why Simulation is Important in a Tough Economy

Everyone wants to cut costs. No one wants to spend unnecessarily. When budgets are tight, software and software projects are an easy place to cut. Staff positions like Industrial Engineers are sometimes easier to cut or redeploy than production jobs. I suggest that following this reasoning to eliminate simulation projects is often short-sighted and may end up costing much more than it saves. Here are a few reasons why it may make sense to increase your simulation work now.

1) Minimize your spending. Cash is tight. You cannot afford to waste a single dollar. But how do you really know what is a good investment? Simulate to ensure that you really need what you are purchasing. A frequent result of simulations intended to justify purchases is to find that the purchases are NOT justified and in fact the objectives can be met using existing equipment better. A simulation may save hundreds of times its cost with immediate payback.

2) Optimize use of what you have. Could you use a reduction in cost? Would it be useful to improve customer satisfaction? I assume that your answer would always be yes, but even more so in difficult times. But how can you get better, particularly with minimal investment? Simulation is a proven way to find bottlenecks and identify often low-cost opportunities to improve your operation.

3) Control change. In a down economy you are often using your facilities in new and creative ways – perhaps running lean or producing products in new ways or in new places. But how do you know these new and creative endeavors will actually work? How do you know they will not cost you even more than you save? Simulation helps you discover hidden interactions that can cause big problems. Different is not always better. Simulate first to avoid costly mistakes.

4) Retain/improve your talent pool. Some people who might otherwise be laid off may have the skills to be part of a simulation SWAT team. By letting them participate in simulation projects, they will likely achieve enough cost reduction and productivity improvements that they more than pay for themselves. As an added bonus, the team will learn much about your systems, the people, and communication – knowledge which will improve their value and contributions long after the project is complete.

5) Reduce risk. You are often forced to make changes. How do you know they are the right changes? Will a little more, a little less, or a different approach yield better results? How do you measure? A strength of simulation is its ability to objectively assess various approaches and configurations. Substitute objective criteria for a “best guess”, and, in turn, reduce the risk associated with those changes. In a down economy it is more important than ever that you don’t make mistakes.

In summary, rather than thinking of the cost of simulation, you should think of what the investment in simulation today will save you today, tomorrow and every day following. Simulation is not a cost, it is an investment that may return one of the best ROIs available in a tough economy.

Dave Sturrock
VP Products – Simio LLC

Customer Experience

(Guest article by Renee Thiesing)

I recently found myself in a situation that can only be described as completely frustrating. And as an Industrial Engineer, it was even more frustrating because with just a small amount of reorganization and process enhancement, the customer experience could be improved tenfold. No, this aggravating experience did not occur at the Department of Motor Vehicles, it transpired at a children’s ski school drop off counter.

I arrived with my daughter at 8:45am, which is in the middle of the recommended arrival time slot of 8:30-9:00am. The line of about 6 people was making the very small lobby area seem tiny. Besides the fact that the line was moving incredibly slow, when the person at the front of the line arrived at the counter, there was no clear process that occurred. Some people had reservations, some did not. Some people needed to rent equipment, some did not. Depending on your situation, the time that you spent at the counter when you reached the front of the line, varied. It seemed there was no clear benefit to having reservations. And for those poor people who were renting equipment (myself included), after finally reaching the front of the first line, we were sent upstairs to an even more chaotic ski rental area. As we joined the back of another line, I realized that this line was only for boots. Once my daughter was finished getting fitted for boots, I needed to go to the other side of the room for skis. And was the line I waited in for skis the final line? No. Next, we trekked back downstairs to where we started, only to join another line. Here is where we waited for my daughter to finally enter the ski school. After it was all said and done, it was one hour later and the world was left with yet another dissatisfied customer.

I can’t help wonder how some simple changes might improve the system. What if they assigned a certain number of people to arrive at 8:30am, another group to arrive at 8:45am and yet another at 9:00am? Would this arrival process help reduce the time customers wait in line? I believe there should be a clear benefit to people who have reservations. Would their experience be improved if they had a line separate from the people who did not reserve a spot? One of the most annoying aspects of the system was that we had to go upstairs and wait in line to rent our equipment. Non ski school patrons were mixed in with ski school children in this room. At the very least, ski school participants should receive priority for being served. But even better, I would like them to analyze the costs and benefits of moving some equipment rental downstairs to the ski school. I would like to drop my daughter off and let them employees fit her for both her skis and boots right there in the room where she’ll eventually begin her lessons. By having her sizes in my reservation file, they could have the equipment ready in the downstairs area.

This is a very simple system. But since it is broken, perhaps they need a demonstration of how it can be improved. Simulation anyone?

Renee Thiesing
Application Engineer – Simio LLC

IE Community Service

Someone commented on a recent post indicating they felt that we as IEs don’t do enough to help others.

I completely agree!

But just who are “those people” who don’t do enough? It’s you and me.

Sure, there are a thousand very good reasons why you can’t get involved:
• I’m too busy with work.
• I have family commitments.
• I can’t make a difference.
• I don’t know how to get involved.
• There is nothing in it for me.

But I feel that is our responsibility to give back – even if no one is looking. Industrial Engineers have unique capabilities to contribute. There are many ways that we can each make a difference with even a small time commitment.

Here are just a few:

Community group support – The Pittsburgh IIE chapter solicits the community to discover needs and then solicits volunteers to help meet those needs. Some recent projects that I am familiar with are helping to improve the logistics of a Pittsburgh arts festival, and helping to improve operations and resources use for Habitat for Humanity. Many organizations have such opportunities if you take the effort to ask.

Education – Ask your local school if you can come in and talk to a class about what you do. Most teachers would love such involvement. You can give the kids some career ideas and some encouragement to study hard and take those “tough courses” needed for engineering. Want a bit more involvement? Contact your local Junior Achievement chapter.

Engineer’s Week – There are hundreds of organizations that sponsor events for Engineer’s Week (in February). Again, here in Pittsburgh a couple dozen societies are participating in exhibits and activities at a major science museum to help attract their attention and interest in engineering. These are typically staffed by volunteers like you.

Community Group Management – Join a steering council or board of directors for a community group. For the same reasons that Industrial Engineer’s are highly represented among corporate upper management, they have a lot to contribute to guiding community groups. United Way is one place to go to identify organizations in need.

There are lots more opportunities if you look. And I think you will find that participation brings unexpected rewards.

Dave Sturrock
VP Products – Simio LLC

Six Sigma and Simulation: Part 3

By Jeff Joines (JeffJoines@ncsu.edu) Associate Professor in Textile Engineering

This is the final installment of the three part series on Six Sigma, Lean Sigma, and Simulation. The first part explained the Six Sigma methodologies and linkages to simulation while the second part discussed where simulation could be used directly in the two six sigma processes (DMAIC and DMADV). The final installment will demonstrate how simulation can be used to design Lean Six Sigma Processes.

Recently, the Six Sigma continuous improvement methodology has been combined with the principles of lean manufacturing to yield a methodology named Lean Six Sigma. Recall Six Sigma is a continuous improvement methodology used to control/reduce process variability while Lean manufacturing is a management/manufacturing philosophy that deals with elimination of waste and is derived from the Japanese Toyota Production System (TPS). When people think of Lean, they conjure up Just-in-time (JIT) manufacturing (i.e., parts or information arrive just when you needed and not before). The elimination of waste is key in Lean systems and Toyota defines three types of waste: muda (‘non-value-added work), muri (overburden), and mura ( unevenness). Most people think of the non-value added form of waste when referring to Lean (e..g., a part sits in queue for ten minutes before being processed for one minute which represents ten minutes of non-value-added time). Many of the Lean tools deal with eliminating this form of waste (muda). Toyota indentified seven original common wastes (paraphrased from “Lean Thinking”) that Lean tries to eliminate.

  • Transportation (moving products that is not actually required to perform the processing)
  • Inventory (all raw materials, work-in-progress and finished products not being currently processed)
  • Motion (people or equipment moving or walking more than is required to perform the processing)
  • Waiting (waiting for the next production step (i.e., queue up))
  • Overproduction (production ahead of demand causing items to have to be stored, managed, protected, as well as disposal owing to potential)
  • Over processing (due to poor tool or product design creating unnecessary processing, e.g., over engineered product that the customer doesn’t need or pays for or having a 99% defect free rate when the customer is willing to accept 90%)
  • Defects (the effort involved in inspecting, fixing defects, and/or replacing defective parts)

Lean Six Sigma utilizes the continuous improvement methodology (DMAIC) as a data-driven approach to root cause analysis, continuous improvement, as well as lean project implementations. Lean encompasses a wide range Lean tools hat are used to implement changes as seen Figure 1. Many of the tools still use the Japanese words (e.g., Poka Yoke or mistake proofing)

Figure 1: Graphical Representation of 24 Lean Tools and Their Broader Categories (Kelly Goforth’s Master Thesis at NCSU)

As was the case for Six Sigma methodology, simulation modeling and analysis can be used in many facets of the Lean implementation and can be quite critical in making decisions. Most improvements have to be documented and analyzed where simulation modeling and analysis can be used easily to ascertain the benefits of the improvements to the current process before actual implementation. The following is just a few cases where I have applied simulation.

Value stream maps are a critical step in becoming lean and should be used first to identify areas of improvement before applying tools randomly. Value stream maps differ from process flow maps in that VSMs contain all the value added and non-value added steps/activities, include the information flow along with the material flow to make the product, are a closed circuit from the customer back to the customer, and take into account customer’s Takt time (i.e., the time needed to deliver the product at the customer’s pace). In developing a VSM, typically a snap shot of just a few key products are mapped for a particular day. Once the current state VSM is developed, areas of improvement as well as the lean tools to achieve these improvements are identified; future state maps are then generated to illustrate the improvement potential. The value stream map can be used to develop a simulation model and a wide variety of demand streams and SKUs can be experimented with to determine the VA and NVA times, etc.

Ford in the early 1900’s utilized fixed flow assembly line (i.e., one production line made up all the machines to produce one car in a sequential line) to maximize throughput. However, when the number of products and part categories increased while lot sizes decreased, manufacturing moved to functional layouts (i.e., job shops) where machines were grouped based on function (i.e., drilling machines). Now parts would flow to all the groups necessary to be produced which introduced great flexibility but also increased travel time, waiting, WIP, defects owing to machine setup, etc. The lean concept of cellular manufacturing decomposes the manufacturing system into groups of dissimilar machines that can process a set of part families which ideally decreases transportation, setups, balances load. These are a mix of smaller job shops and flow assembly lines combined. Determining these part families and groups of machines is quite complicated. Simulation can be used to establish a base line for comparison of the proposed new systems. The new systems can be simulated with varying demand variation, maintenance issues to test the design of the cellular groups before the machines are moved or setup in the new manufacturing system.

When people think of Lean they associate it with JIT and simulation has been applied the most in this area. Pull scheduling systems differ from push systems (i.e., a forecast of a set of parts is sent to the first process and are then pushed through the system until completion) in that parts are not produced until they are needed. Kanbans (signals) are sent back to the previous process to replenish parts only when they have been used by the current process. Pull systems ideally have lower WIP and faster through puts but typically only work for stable demand streams. For example, we worked with a large company building a new plant with fairly large lead-times. Parts of the organization had been very successful in implementing Pull scheduling systems to fill their stock inventories. The company had put in place demand leveling as way to deal with widely customer demand variations. They initially asked us to evaluate where should they place supermarkets (i.e., places to store inventory (Kanbans)), what should the size of the respective kanbans for each SKU, etc. After building several simulation models utilizing their historical demand streams, we determined that the total volume that was being placed on the plant was like a tsunami that would engulf the supermarkets essentially turning it into a push system anyways (i.e., everything sent to the first process (raw materials) and the processed to the end). We demonstrated through simulation the supermarkets would have to be large to be effective and these Kanban sizes were just impractical. The simulation model told them before an enormous amount of money and time was spent developing the process and information system to handle it and they could focus on other Lean areas.

Most people are familiar with the last form of waste (mura) and its elimination through Heijunka (production leveling). Production leveling/load balancing works in conjunction with pull systems and these systems can be simulated again to see their impact as well as to determine where supermarkets (e.g., inventory buffers) need to be placed to reach balancing. Total Preventive maintenance (TPM) is another area where lean practitioners can benefit from simulation modeling to ascertain affect of different policies and schedules on the system.

For more information on Lean Manufacturing and the lean philosophy, I recommend two books by the James Womack et al.: “The Machine that Change the World” and his latest book “Lean Thinking.”

Conclusions

The three part series has hopefully shown how simulation practitioners possess a skill set that is extremely beneficial for Six Sigma, Design for Six Sigma, and/or Lean Six Sigma project. These types of projects are not very unique but just general simulation models that require us to learn their particular language. I find it easier to work on Six Sigma projects because the Lean and Six Sigma practitioners understand statistical analysis necessary for input and output analysis even though they typically have only used the Normal distribution.