Why Daily Plans Fail

At 6:00 Monday morning I create a plan for my day starting at 7:00. That doesn’t seem to be such a difficult task. Why is it that by 7:30 my plan already shows signs of being hopeless?

I’ve done the obvious things. First I upgraded from a magnetic Gantt chart based on hand-written information to Advanced Planning and Scheduling (APS) software. That was much easier to use, but frankly the results didn’t dramatically improve. Feeding it with live data from my Manufacturing Execution System (MES) got me a good starting point, with a lot less effort than the paper approach, but my plan still didn’t hold up to the test of time.

I then realized that my software was based on standard lead times and it assumed infinite capacity — it was constantly overestimating my production capability. So I updated to Finite Capacity Scheduling (FCS) software. That helped a lot. But I still had a lot of problems because the FCS tool was based on a “standard” data model for my industry. I guess we do things a bit different than most people in our industry, but the schedule it generates doesn’t recognize those differences.

So I updated to a general purpose simulation product with the flexibility to model my system as it really is AND generate the Gantt charts and other reports I need for scheduling. So now I can account for that problem aisle where my lift trucks get so congested. And I can account for that machine cluster that shares access to a single crane. As a bonus I also got an animation that lets me “play out” the day and visually see what I can expect.

Now I have a much better plan that is realistic and accurate as long as everything goes well. But it is always optimistic. While I can put in preventative maintenance, there is no way to factor in that my Cobalt 120 machine is 30 years old and breaks down almost every day. Or that my supplier for Jenkins 257 material is often way behind their promised delivery. I can pad the schedule to allow extra time, but that just guarantees that I will waste valuable production time when things go well.

In my simulation tool I can run my model with all that variability accounted for (stochastic analysis) and it gives me good long-term capacity analysis. But since there is no way to predict a specific “random” problem, like an equipment failure, I can’t use that knowledge in generating my plan for today — I am limited to a deterministic schedule … or am I?

Actually there is a new technique available called Risk-based Planning and Scheduling (RPS) that first generates a deterministic plan, then applies a stochastic analysis to that plan. It actually tells me how likely it is that I will meet the plan. For example, orders that require the Cobalt 120 machine or Jenkins 257 material may show a high risk of not completing on time. Since I know this before the shift starts, I have more options on how to deal with it – like adjusting labor assignments, rerouting a process, or expediting a material. I can even evaluate the various alternatives to determine which one performs best, and then base my plan on the alternative that generates an acceptable risk at the lowest cost.

Now that’s a plan I can live with!

Happy Modeling!
Dave Sturrock, VP Operations, Simio LLC

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!

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!