This is a continuation of a conversation I recently had with one of our clients. They were talking about buying a new—and costly—APS (Advanced Planning and Scheduling) application. The goal, of course, was to improve their company’s performance.

 

Let’s pick up in the next step of our conversation. Remember, some minor changes have been made to protect the confidentiality of our client.

-----------------------------------------------------------------------

In the hope of providing a more accurate and even clearer picture of my concerns, I have taken some time to rework your CRT (Current Reality Tree) from what I learned while working with you and your team some time ago. I recognize that some things have probably changed since I was with you, and I assume you will take those things into account from what you know that I do not know at the present time.


Nevertheless, I think the analysis may raise some cogent points for your consideration as you move forward.

CRT Partial RootsOnly.jpg

As you know, at the bottom of the CRT we find the ROOT CAUSES (provided our CRT accurately represents “reality”). [Note: the accompanying image is only a small portion of the CRT I provided in my correspondence with the client.) Here, in my analysis, I find nine (9) roots, which I have listed in the following table, along with some general comments:

 

Root

Comments

[1] Some materials are damaged during the manufacturing process

Because this contributes to so many UDEs further up in the tree, time spent on Pareto analysis of the causes of such defects and damage would probably have a significant pay-off (if you have not already undertaken this as part of your POOGI)

[9] Production scheduling and resource allocation is generally ad-hoc

It appears to me that you are thinking that you are addressing this root cause through the application of your PlanetTogether Galaxy software. My question is whether this will add complexity without correlated benefits. I will discuss why I have this concern further in this correspondence.

[8] Customer service processing delays sometimes lead to shortened production lead-times (release of order to required ship date/time)

Here again, some amount of time spent in capturing the causes of delays and ongoing Pareto analysis of the causes would probably have some relative immediate payback (if you have not already undertaken this as part of your POOGI)

[7] Company policies allow customers to create “Rush” orders

This may be unavoidable, but should be carefully reviewed in terms of policy and pricing.

[12] Inventory status is not easily correlated to production demand

In a fast-paced, make-to-order (MTO) environment, this is never easy to do. MTO multi-level BOMs/Routings virtually assure that almost every MTO order will show that one or more components are not presently available. This is where TIME and CAPACITY buffers, rather than STOCK buffers, can be a powerful tool in sustaining FLOW.

[15] Some inventory items may be out-of-stock or unavailable in sufficient quantities

See comment on [12] above.

[13] All production demand for all BOM levels is released to production at once (daily)

The virtual “flood” of paperwork that accompanies a daily release probably needs to be looked at in a fresh new way.

[11] A single finished good may require 4, 5 or more work orders (multi-level BOMs / Routings)

While this may be a given, and it correlates closely with [13] above in producing the resulting “flood” or paperwork, innovation may provide a key to reducing the “flood.”

[33] Little’s Law: More WIP = longer lead times

This is a given. The larger your WIP, the longer your lead times. This is all relative in terms of touch time, queue time, and wait time. In one plant we might be talking about six weeks versus three weeks; however, in your plant we might be taking about six hours versus three hours.

 

On Quality Failures and Rework


I don’t know how big the rework UDE (Undesirable Effect) is in your production environment today, but I recall that it was a relatively BIG ISSUE at the time of my last visit. As you can see from the CRT, regardless of the issue’s present size, it affects lots of areas:

 

What I do not see is how any APS (advanced planning and scheduling) system is going to account for, or provide support for, any level of rework in your system. The very best you could hope for, I should think, would be to reduce your estimated production capacity at each resource by some allowance for rework. However, that means that all your production schedules will have slack everywhere in the system. This is not, likely, a good approach.


The problem is, the APS cannot possible know what materials and which resources will be involved in rework in any given day or hour of the day.


This is where too much complexity and attempts to plan and control at too finite a level actually makes matters worse and more confusing than the implementation of higher level, simpler signals and controls—which is what [a demand-driven scheduling solution] provides. Time and capacity buffers, and the signals stemming from these buffers, simplify management and provide clearer priorities for action.


Production Scheduling and Resource Allocation


In the message you sent [earlier], part of the “Future State” with regard to “Capacity Planning” was the hope that [the APS]’s capacity planning capabilities would allow you “to determine available capacity” and do “Long-Term and Short-Term Capacity Planning based on accurate schedule dates.” [Emphasis added: there’s that word “accurate” again—that sounds so good in theory.]


My concern is that it won’t work out in reality like it sounds in theory for some of the very reasons I mentioned in my [earlier] message, and those above, as well. In the absence of a huge data maintenance effort, ongoing throughout the production day—day-in and day-out—[the APS]’s finite scheduling mechanisms will remain ignorant of the impact of rework, “busted” schedules due to late-discovered materials shortages, or changes in CCR (Capacity Constrained Resource) capacities resulting from unexpected adjustments and adaptations being made on-the-fly on the shop floor.


Since employees and managers almost always want to do a good job for the company, their ad hoc decisions on the shop floor will virtually always be made in favor of FLOW (read: high levels of customer service), but the finite scheduler in your APS will not be updated with these changes—wise though they may be. This means the time, money and effort you put into having a complex finite scheduler produce a sound theoretical schedule for you by 8:00 AM, may be entire wasted and the shop floor may be running entirely “by the seat of its pants” by 10 AM—and this might happen several times a week!


Advanced Planning and Scheduling Systems and “Murphy”


APS finite schedulers work beautifully in theory, but they do a lousy job of accounting for “Murphy.” And, without constant data maintenance (throughout the day), and the processing of potentially dozens of what-if scenarios, no APS will be able to give you clear priorities for actions when Murphy disrupts the schedule issued earlier in the day. In fact, running a what-if scenario one way may tell you to do ‘A’, while running the scenario a different way may tell you to take action ‘B’, and a third what-if scenario may give you an entirely different action ‘C.’ This is of little use where the need is fast, accurate decision-making. Do you draw straws? What if the managers can’t decide which of the variety of actions to choose?


The simplicity of buffers and signals from buffers—whether they be STOCK, TIME or CAPACITY BUFFERS—provides the entire management team with clear, unequivocal action signals upon which everyone can agree because they know and understand exactly what the signal means and how it is derived. [Demand-driven planning and scheduling systems] essentially provide these kinds of action signals, which is why they are so simple and effective.


Continuing to Read Up Your CRT


As you can see from the CRT [which I had attached to the email], even if you may have some difference of opinion on the logic—because we didn’t build this together (as I’d prefer)—what is happening at the roots of the tree affect everything in the sense that they lead to INCREASES in both TVCs [Truly Variable Costs] and Operating Expenses, and likely reductions in revenues, as well. All of this combines to REDUCE THROUGHPUT (a direct product of FLOW), REDUCE PROFITS, and REDUCE CASHFLOWS across your enterprise.


I’m happy to discuss this matter further with you, but this probably enough (maybe too much) for one message.


            Thanks for bearing with me and these long messages.

-----------------------------------------------------------------------

 

We love hearing from you. Leave a comment to share your thoughts and experiences related to the post.

 

If you would like to have a PDF copy of the full CRT (Current Reality Tree) mentioned in this article, make your request here.

 

Follow us on Twitter: @RKLeSolutions and @RDCushing
LIKE us on Facebook: RKL eSolutions and GeeWhiz2ROI