What's the Difference between a Buffer and a Shock Absorber?

Lately, in industry publications and social networks, you can read a lot about shock absorbers and how to apply them in supply chain planning to reduce variability or absorb it. Apparently, many thought leaders have been replacing and complementing buffers with these shock absorbers… at least in theory. Not wanting to get into anybody’s conversations but I do have my own view on the topic. In my opinion a buffer and a shock absorber are not the same thing and therefore I do not use them interchangeably.

Let me explain my thinking. A buffer is a medium (inventory, capacity, time) that blocks and swallows up a signal... like a firewall prevents heat getting through to the other side. A shock absorber takes the signal in and absorbs it to a certain degree. When the signal is big enough and the absorber‘s buffer is exhausted, there is no holding back anymore.

To use an analogy, think of  driving your car into a pool of mud at 50 miles an hour and you know how a buffer acts. Drive that same car through a pothole 10 inches deep and you get an idea what shock absorbers do… they let you feel what a big change in variability there may be, while a buffer simply stops you right in your tracks.

The problem with buffers is that a part equipped with a buffer doesn’t ‘see’ when a big change in demand is on the horizon. The buffer simply blocks all that’s coming at it. The shock absorber, however, swallows up the little changes but carries through the big ones. That can be very helpful in some situations but annoying and inefficient in others. This is why both buffers and shock absorbers are awesome tools to take the noise out of your supply chain. You just have to use them in the right situation and not mix them up because that can lead to chaos and bad planning.

In the same way one certainly doesn't want to drive a brand new BMW into the mud to slow down when there are a few bumps in the road. But coming down from a mountain pass in a 14 wheeler with failing brakes, you’d be happy if there’s a buffer coming up absorbing all that energy.

Who needs a rough-cut capacity check anyway?

Just recently I was visiting with a manufacturing company that builds parts for the automotive industry. It’s a repetitive business and they use Make To Order and Make To Stock strategies. The problem is that there is a humongous backlog, because there isn’t enough capacity and there is too much of the stuff nobody requires and too little of the stuff they desperately need.

I do not want to go into the specifics why I think the backlog is there (no flow and therefore wasted capacity, missing parts and therefore orders stuck in the line wasting capacity, no scheduling system and therefore inefficient schedules and therefore wasted capacity). No… I want to ask why there is no planning? All over the internet there are discussions going on where everybody pitches in with the newest and greatest planning methodologies… Advanced Planning & Optimization, DDMRP, IBP, S&OP, agile, lean. Then there are the software solutions that supposedly make it all happen… and eventually everybody is so keen to improve forecast accuracy with demand sensing or probabilistic forecasting. Everybody is out there to get the best and coolest planning solution.

Why? Why is so much money spent on implementing the greatest software tools, applying the best methodologies and engaging thought leaders and evangelists when - in the end - orders are scheduled in MS Excel (where there is no information about capacity, inventory or demand), carefully crafted strategy (like are we making to stock and how big is our shock absorber) gets blatantly ignored and all the big rules fly out the door when the sales rep claims a super important customer request?

The last six customers I have worked with did not do planning. That is a heavy statement. Especially if I would tell you the names of the six… you’d know them all by name. So what do they do? Let me start with what they do do and then we’ll discuss what they don’t do. Some of them work with a forecast (four of the six).  Of those that do, the forecast comes from the Sales department. Some of these forecasts are in a different system than the system in which production orders are scheduled (two companies of the four forecasting, maintain an interface) This raises the question about what objects are transferred through the interface. Both companies that maintained a forecast, and had two systems, transferred planned orders (supply elements) over into the system that takes care of scheduling. The other two companies that maintained a forecast - but within the same system as scheduling - did not make a difference of a long term, a mid term, a short term horizon or a frozen zone. It was all one long period in which there were planned orders, fixed planned orders or production orders. The two companies that were not maintaining a forecast were going by customer orders only.

What does that say about planning? We have three situations (please note that a forecast can also drive a schedule for MTO products, as in that case capacity for MTO production is reserved on the line):

1. No forecast, customer demand driven
2. Forecast drives schedule, two different systems
3. Forecast drives schedule integrated in one system

Refutation for situation 1.: if you go by customer orders only, then there is no planning. And unless your customers accept the time it takes to procure materials, fabricate components, build sub assemblies and assemble the finished products, they will go someplace else to get the product they need and want.

Refutation for situation 2.: if you maintain a forecast in one system, perform a rough capacity check for the long term. This is necessary so that you can decide whether you have the capacity to fulfill the expected demand in-house or you’ll have to talk to a trusted supplier who’s helping out and provides some extra capacity. If you don’t do that and simply hand over supply proposals (planned orders) to the scheduling system, then I’d call that bullying but certainly not planning. If anything, hand over demand (instead of supply) so that your MRP Run can at least do some planning in the short term. It’s probably too late to do anything good anyway (what is a production scheduler to do if the demand causes a utilization of 400% plus?).

Refutation for situation 3.: The two companies that forecasted and scheduled in the same system had discrepancies between how they wanted to operate and how the system was setup to support those efforts. In other words: they were trying to do the right thing but didn’t get the right advice on how to set up that system that was supposed to ensure an integrated planning process. There were no planning horizons, the planning strategies were not setup correctly, the sales orders didn’t consume the forecast properly, the sales availability check did not work and therefore demand was transferred incorrectly… etc pp.

And here is the sore point. I don’t think it matters much what system one uses or what methodology one applies when the construct (the third floor) is not supported by the basement. All those methods are great when applied to the proper situation. And all these system have all the function and features one needs to plan effectively and efficiently. But deciding on the right methodology and right tools isn't even half the way towards the end goal. You must support the philosophy with sound structures (planning horizons, planning strategies, planning hierarchies). What good is it if you place strategic buffers but you send the wrong elements (supply orders instead of demand) through to the wrong transaction at the wrong time?

It is absolutely justified to invent newer and better systems and methods, but we also - or should we say primarily - need to make sure the foundation is build first and is solid. Too often I hear „this software is crap“ or „we need to replace that old method with a new one“. Remember… just because you can‘t fly an F16 doesn‘t mean it‘s a shitty plane!

Takt-based scheduling? Yes, but just not really…

Takt is a German word. It’s used in the music world. A conductor uses a baton primarily to regulate the tempo of the music. So why would we use takt to schedule production? Well… maybe to regulate the tempo of production? I see managers everywhere, trying to regulate the flow of production lines. And we intuitively know that when things flow we get better results as when things get stuck. And then there is a multitude of literature, white papers and theory that suggests many solutions, all geared towards a noise-less, well moving, uninterrupted production program to fulfill customer demand in the most efficient way. Therefore, we try to get things flowing.

…and we do so when working on the design of the production shop floor and assembly lines. Pull systems (Kanban cards) are used, a takt counter provided, scheduling boards (Heijunka boards) pop up everywhere, sirens go off when there’s a problem (in one plant in Juarez, Mexico they play ‘Für Elise’ by Ludwig van Beethoven instead) and the assembly line is organized in a way to support a balanced workload from station to station.

Do you see yourself in that picture? Yes? So what about your ERP system? Does it allow you to schedule for that setup?
Here are a few answers that I get when asking that question (in no particular order):
- We are a lean shop… we don’t need ERP to schedule production
- No, our ERP cannot support a takt-based schedule
- What do you mean…?
- Yes, we developed a great solution into our SAP system. We have a transaction called Z_SCHEDULE that does a great job reshuffling our production orders
- Yes, we have a very good production scheduler who figured this all out… yes, he works with EXCEL spreadsheets but updates everything into SAP on a regular basis so our cost controllers will get everything they need

As you can see there’s not a lot of system support for a takt-based flow line… at least perceptively. In fact, I personally have seen many, many shop floors (especially assembly lines) that are run by takt, but I have not ever seen any of those setups supported by an ERP system (as I primarily work with customers who run SAP, I’d like to limit this observation to SAP-ERP or APO). There is always a work-around (which never works)… or no support at all… when SAP has the perfect support for that… all with standard transactions! (It would be too much for an article like this to elaborate on how to set up takt-based scheduling in SAP. But I am more than happy to elaborate to specific requests – let me just point out here that SAP ERP provides transactions for line balancing, takt calculations and takt-based sequencing. It does so in its repetitive manufacturing module and from early 2018 on for a discrete setup as well by way of an SAP Add-On Tool)

At this point I just would like to point out the difference between truly scheduling takt and what is done much more often: lead time scheduling. In lead time scheduling, the operations are backward scheduled from the requirements date of the product whereas in takt-based scheduling the operations are distributed – without violations – in the provided takt time

This (takt-based scheduling) has the affect that work is evenly distributed across a production line and therefore allows the product to flow. In lead time scheduling this is not the case because WiP builds up in front of a station that has more work to do (longer operation times) than the station before. 

So don’t use lead time scheduling in an ERP system if you truly try to run by takt time. Your ERP system doesn’t work very well if it supports a different animal than the one you own. A very smart man told me recently “if it quakes like a duck, walks like a duck and looks like a duck… chances are: it’s a (f…) duck!” And then you should treat it like it’s a duck.

A Perspective on Supply Chain Optimization

For a long time there has been a search for the perfect planning system. I have been looking for it too but after many years of trying, I've come to the conclusion that such a thing only exists for very specific situations. What I mean by that is that as we try to generalize, package and roll-out solution to the general market, I have seen nothing but either failed, misrepresented or incomplete solutions.

What I like is flexibility… having options… matching the proper strategy to the respective situation. It is hard to come up with a methodology, theory, package. philosophy or whatever you want to call it, when there is a multitude of industries, production types, inventory requirements and many, many situations. There are products that are expensive, have a long replenishment lead time, are hard to predict, demanded as a commodity, large in size, hard to move and complex to manufacture. Then there are products that go bad in a short period of time, must be refrigerated, are cheap, have consistent demand and consumption, are small in size, need a specific package and are strategic and important to the success of the business… and then there are a million situations in between and left and right of these.

No matter how much some marketers try to convince me that this or that method is superior to everything else… I don't buy it! As an example… deterministic planning (pure MRP) is prone to the bullwhip effect and has very detrimental effects to a supply chain (I've written extensively about the bad behavior of 'plan on demand/forecast driven' myself)… in maybe 97% of all cases. But in some cases it might actually be the best thing you can do. A static safety stock might increase your dead stock, but when the product is a life-saving instrument that might be exactly what you want. My point is… don't just let someone tell you what the solution is… bring up the specific situation and only look for the solution then. Because this is how most - if not all - ERP systems were implemented: make up a template or blueprint that covers most of your situations and then force the solution onto everything that comes in your way. Not a good idea as we all know when we look at how these systems are getting used (or not, when spreadsheet hell takes over the transactional business).

What I am suggesting to the contrary is that instead of buying a "fix-for-all" solution, develop good intuition to understand the dynamics of your supply chain and build a toolbox full of what I call 'Connectors'. Most people will want to sell you an all-encompassing methodology… a theory based on which service levels go up and inventory values go down. I like most of these things, just not as the 'fix for all'. There are many people today that promote buffer planning. Those are awesome solutions that work wonders in many situations because they replenish independently and de-couple themselves from variable demand. But what if the part is of strategic importance and you must know when there is an unexpected rate hike in demand? In a pure buffer you don't see this coming. Time to use an absorber. The absorber swallows little demand variation and alarms you of the big ones… in that it passes it right through - deterministically! MRP (determinism) doesn't always mean bad things… sometimes it’s actually helping you.

I am not promoting any one theory or methodology (I will leave this up to the people selling you new software or projects), I am suggesting that you put together a toolbox of connectors and apply them when the situation calls for it. One thing most thought leaders forget, is how to actually apply the teachings to the real world - in other words: if I tell you that you must use an inventory buffer, a time buffer or a capacity buffer… how do you actually do that in your planning system? A blog post is certainly not the right place to go into a detailed documentation of a system configuration, but I want to put the money where my mouth is and give you at least a few hints so that you can try a few things. I can only speak for SAP though… the following is an incomplete list of tips for SAP-ERP.

For a deterministic connector use MRP Type 'PD' and a static lot size. Every demand signal is transmitted unhindered. This will alarm you of any change - small or big - and also allows the bullwhip effect to do its thing. If you combine the 'PD' with a static safety stock on the left side of the MRP2 screen you get an unmovable block of inventory from which any demand signal is reflected and transmitted. Static safety stock is ignored in the MRP Run's net requirements calculation and taken out of the stock/requirements situation right away. All of MRP plans without static safety stock (there is, however, a way to make some or all of the safety stock available for planning).

To use a buffer in SAP you have a number of options. A buffer, as defined in much of today's literature has minimums, maximums and an ideal zone. You can work with reorder point procedures, min, max settings and the safety stock. My favorite way to define a buffer is with MRP type 'VV' and a Range of Coverage profile on the right side of the MRP2 screen. A buffer connector decouples itself from variable demand and replenishes itself based on historic consumption. The dynamic safety stock (Range of Coverage profile) absorbs the variation from actual consumption and increases with growing demand of the future. However, it only slowly reacts to future rate increases in which case I suggest to use an absorber. The absorber uses MRP Type 'PD' in connection with a dynamic safety stock. That way small variation is absorbed and big changes go right through to give you an exception messages and to generate an extra replenishment proposal.

These are just four tools in the box. You might need a lot more. As I write before… build intuition about what to expect from the dynamics of your specific supply chain and build up your toolbox.

Absorption Based Planning

There is – and actually has been for a long time – a lot of talk about buffers, safety stocks and de-coupling points in supply chain planning. Let me add another term to this: shock absorbers. “Oh my”… you might cry out “Not another buzz term or theory!” I’m with you… too much confusion and buzz around this subject. But please allow me to take a shot on simplification and order in this area.
From experience we know that supply chains are exposed to variability in supply, demand, in process and sometimes we even inflict it ourselves. We also know that when variability is present things do not work out as planned. We might end up with stock-outs, too much inventory, late deliveries, backlogs, exception message galore or general chaos. That is why we should plan with variability in mind.
None of this is new or of any revelatory kind. We all know this. The question is what we can do about it. And there are many schools of thought and also some schools of not-so—much-thought-through thought. My approach is one of segmentation with subsequent policy setting. That is also not new but just recently I had a little bit of an epiphany (far from earth shattering) with what I call absorbers. Allow me to elaborate:
Most planning systems I come across are set up with rigid connections. I call these deterministic. In it network nodes and Bills of Materials are strictly dependent on each other and any changes in demand or supply will cause a “rattling” of the entire structure. There is immense noise and nervousness in such a system and it often produces superfluous inventory, vast amounts of stock-outs and exception messages with no end to it.

Planners are usually very aware of this nervousness and being forced to work “in” the system (as opposed to be allowed to work “on” the system) trying to facilitate the issues with expediting and fire-fighting. When the situation starts to look like an unsurmountable mountain of orders, materials and requests, the static safety stock looks like a plausible solution. That is when things completely fall apart and for some reason no one can explain why inventories grow further and stock-outs happen more frequently (delays, my friends, delays is the problem).
So what can be done? I am not claiming that I know the all encompassing solution to the problem but let me make a couple of suggestions:
First, assess your network and bills of Materials and look for spots where you can de-couple the rigid structure. What I mean by that is that you free up the deterministic planning process of dependent requirements and dependent supply. De-coupling, however, is not limited to only inventory buffers (and that is my little epiphany here), it may also act like a shock absorber.
The problem with an inventory buffer is that you can only use it if your past consumption is somewhat consistent, that part is not too expensive and the replenishment lead time is relatively short. Some of those thought schools might not agree but how do you calculate a reasonable buffer that doesn’t become real expensive when you don’t know anything about the future demand, one part costs $1,000 and it takes 3 months to replenish?
Don’t get me wrong… I love replenishment buffers to de-couple rigid supply chains but sometimes they just don’t work. I have used these buffers extensively in our optimizations but often the planner rightfully asks “what if I get unusual demand? Where is my signal? How do I make sure I don’t miss it?”. My belief is that you must ignore the little signals but still see and react to the big signals. And that can be achieved by way of a shock absorber.
So what is a shock absorber? It is NOT inventory! Let’s think about safety stock in a planning environment (static or dynamic. Counter to most beliefs it is not inventory as long as it is in the future plan and it is acting as a buffer (there is a minimum and a target level of your safety stock). If you have such a buffer, then a replenishment element is only generated when the buffer is exceeded with demand. Any demand changes that are within the buffer between a minimum and a target level are simply absorbed.
Let’s further explore how this can work when your planning operations run on SAP software. The absorber I am talking about may be set up with a Range of Coverage profile (dynamic safety stock). SAP‘s RoC has a minimum and a target range of coverage. If, let’s say, you have a minimum of 1 day and a target of 5 days and your average future daily requirement comes out to 10 pieces, then you absorb incoming variability of 40 pieces. Note that this is not actual inventory you hold in your warehouse. It is a quantity you are holding in a plan. Any changes (in forecast or customer orders) not exceeding 40 pieces are simply absorbed in the profile and do not cause noise. However, if there‘s a BIG change the signal transmits right through to the next level (use MRP type PD together with a RoC).
And this is the desired outcome for materials that can’t be replenished with a consumption based method.
Sounds too trivial and simple? Good! Because that’s what we need in this overly complicated supply chain world (sometimes it seems to me that it is made complicated on - some calculated - purpose).
In summary here is my suggestion:
1. visualize your supply chain dynamics (a value stream map)
2. run a segmentation (ABC, XYC, EFG, UVW)
3. find places where you can decouple with inventory buffers (MRP type VV or V2 with a coverage profile)
4. find places where you need to decouple with absorbers (MRP type PD with a coverage profile)
5. replenish (accordingly), rinse and repeat (periodically)
You will find yourself working „on“ the system now and the system starts working for you (instead of you working for the system).
In the end it does not take a new revolutionary approach, theory, culture or methodology. Common sense is good too. Use it.

SAP und bigbyte Info Days, October 11 & 12 in Detroit

Working ON the system instead of IN the system

As we're optimizing inventories, implement new production scheduling methods or improve our forecasting, we're working in or on a system... a system where individual parts make up a whole and feedback loops and certain dynamics take place. What defines a system? First, they have purpose. An automobile has the purpose to move people. However, its purpose is a property of the system as a whole and not just of a part. An automobile takes people from one place to another. That is its purpose as an automobile as a whole and not just of its wheels.

Also, all parts must be present for a system to carry out its purpose. If you can take pieces away from the system without affecting its functioning then you have a collection of parts, not a system. Take a wrench out of the toolbox (which is not a system but a collection) and you still have not changed the nature of what’s in the box. Likewise add something to a collection and its still a collection. But when you change a system you’ll see a difference (take off those wheels from the automobile and you will see). Thirdly, in a system the arrangement and order matter. The order in which the parts are arranged affects the performance of a system. As an example, in a traffic system there are clear rules defined and the way these rules are set greatly influences the way the system works. And finally, systems attempt to maintain stability through feedback. Through feedback a system can derive information about its position relative to a desired state. The most important feature of feedback is that provides information to the system relative to a desired state. Your body's desired temperature for instance, is regulated by the body's response (sweating, shivering) to a feedback of the actual temperature




When working on or in a system, there are different levels at which we can work on to optimize, improve, create, design or simply fix problems. Below is a list of these levels in order of leverage or effectiveness.

Events are the occurrences we face on a day to day basis. We catch a cold, a fire breaks out or we have a defective part on the assembly line… or there is a missing part that's needed for a production order

Patterns are accumulated memories of events. They can reveal recurring trends like: we’re catching a cold more often when we’re tired… fires break out more frequently in certain neighborhoods… and defects happen more often during shift changes… or missing parts are happening a lot when we use a deterministic replenishment policy without safety buffer

System Structures are the ways in which the parts in a system are organized. These structures actually generate patterns and events that we observe. In our example, fire houses, and therefore fire trucks, are located at points where they can deploy rapidly to specific areas of the city or... the way the shifts are scheduled might not allow an overlap between outgoing and incoming workers and therefore allow for a higher defect rate… or there is a value stream map that identifies de-coupling points, what buffers are located where and what the specific setups are for master records

Mental Models are the beliefs and assumptions we hold about how the world works. We can see these mental models as generators of systemic structures because they provide the blueprints for those structures. When you have defective parts, the shift crews might think they are only responsible for what happens on their shift – what they produce during their shift – not what happens after. This might have led the company to schedule shift changes without overlap. Or, similarly, a planner might think that a part's demand can not be covered with buffer stock but will have to be expedited when the demand occurs. In that case the planner will always use deterministic replenishment policies. It’s the stuff that we learned from the past (use PD - use static safety stock), accumulated experiences, that wants us to hold on to what we think we know about how the world works. Letting go of those beliefs is what makes change sustainable or even possible.

Vision is our picture of what we want from our future. It’s the guiding force that determines the mental models we hold as important as we pursue our goals. Maybe the people on the various shifts on the assembly line hold a vision of competition – of trying to produce better products than the other shift crews. This vision drives the mental model that says each shift is responsible for what they produce. Or the vision stems from a false (and dangerous) ‘lean’ philosophy of “zero inventory”. It would generate the mental model of avoiding buffer stock at all cost and favor deterministic replenishment policies (without considering delays).

It now should become clear that working on a deeper level of a system makes our work, and the associated outcome, far more valuable and effective. Instead of firefighting a stock-out every time it occurs, we may fix the pattern of how we plan that part (change the replenishment policy), go to the systemic structure of our system of materials planning and perform a segmentation so each part gets an appropriate policy (PFEP), or break down the mental model of our perception how the static safety stock works and implement replenishment buffers instead. we might even elevate the optimization efforts to our executives, convincing them that a vision of 'zero inventories' does not only harm the flow but eventually implements many barriers to success and results in total failure.

As you're moving your efforts down the iceberg, you will inadvertently work more on the system rather than in the system. This means that your impact gets bigger too. Who do you think has the most impact on safety and comfort on a flight from New York to Miami? ...the pilot? ...the flight attendant? ...or the engineer? The pilot and flight attendant work in the system and have a limited influence on what's happening. Most all they can do is react to events and fight fires. the engineer, however, works on the system and it is evident how that can make all the difference.

I truly believe that if you want to make sustainable change, you must work on the system. Remember that next time you want to lose weight... or when you want to reduce your inventory levels while at the same time avoiding stock-outs.

Capacity Planning with SAP

Working for more than 20 years with companies from many different industries, I took a stab at writing down my thoughts on how SAP's functionality might help to make more sense out of production scheduling.

Capacity planning, sequencing, leveling and scheduling of orders is a topic that often is neglected and carried out in Excel spreadsheets and third party tools. With this writing I attempted to explain in simple terms some possibilities in the SAP-ERP offering and express my views on the subject and how it is often used (or not) in companies running on SAP.

The book is available on amazon or espressotutorials.com

Why do you sacrifice yourself to save the safety stock?

Here is something I never understood: why do so many people plan without the safety stock? and why is the safety stock taken out of the planning situation (at least in the standard configuration in SAP-ERP) I know... everybody claims to use it when its needed but until then you have introduced a kazillion rescheduling messages, new order proposals and canceled purchase orders.

I know the above comic strip (if you can call it that - I apologize for the amateur-ish illustration) is not one hundred percent correct; it is meant to make a point, the point being that in planning we ignore that portion of the inventory that is safety stock - as if it weren't there. In actuality, the safety stock is used at the very time when you need it, but only exactly then. If an increase in demand comes in exactly at the same time you fulfill the demand, then you would use the safety stock and issue it. However, if an increase in demand comes in at any date before the date it is supposed to be fulfilled, one ignores that portion of the inventory that is safety stock and your MRP generates a new order proposal.

In my illustration above the consumption of the water should happen at the same time the demand stands and therefore Jenny would certainly take a sip, however, if Jenny would have applied the same planning principles as in the Acme company, and she would spend a certain amount of days in the Sahara Desert, she'd run into a few problems. Let's say she plans to be there for 5 days and calculates with a bottle per day. Using a reserve of 1 bottle she'd planned for 6 bottles for the trip. Also assume that she can order more bottles (minimum a six pack) from a kiosk in Aoulef, Algeria. But it would take three days until the water arrives.

Now, on the first day in the desert, the trip gets extended by one day because they missed a dune. Ignoring the safety stock, Jenny would place an order for six bottles and end up with 8 bottles on day 4 with 2 to go.

On the other hand, if the trip gets extended (again by one day) on day 4 (from 5 days to 6 days), she'd again place an order but this time the six pack would arrive too late and is not necessary either.

This illustrates the two problems of introducing unnecessary noise (the second situation) and surplus inventory (the first situation) that we will get when the safety stock does not act like a buffer. In fact, you'll end up with an unmanageable amount of exceptions and a lot of dead stock (unused, surplus inventory).

Deterministic planning and safety stock

Last week I visited three manufacturing companies. One from the medical device industry, the other one producing fresh and frozen foods and the third in the business of musical instruments and electronic components. they are of very different size, one being a huge, global manufacturer, present almost everywhere in the world, the other one still in the billion dollar revenue range. the third is a mid-size corporation that is privately owned.

Even though they seem so different, the one thing they all have in common is that they're planning deterministically. I am not sure, but I seriously doubt that they a) are fully aware that they plan the demand only and b) that they comprehend all the unintended consequences of their actions and behavior in supply and demand planning.

First, let's discuss what it means to plan deterministically. My definition is, that you plan for the demand that you know (this could be an actual demand or a forecast that you desperately try to get right) and react to every change that comes along until fulfillment of the actual customer order. That is a heavily noise-laden planning process, especially if you propagate the changes throughout the Bill of Material or to feeder plants and distribution centers in a manufacturing and distribution network. As we all know, the 'bullwhip effect' does its damage on top of it and increases not only variability but also noise throughout the supply chain.

I strongly advice against practices like this and almost always recommend to switch to buffering practices where the supply chain is de-coupled and through use of the three buffers inventory, capacity and time, the process absorbs variability and takes the noise out of the planning procedures. There is an entire methodology behind the design and implementation of a buffering planning process to replace the deterministic process, but any more detail would exhaust the purpose of this post. (I simply want to raise awareness about what's potentially happening in your environment too)

Now most planners would argue that they use safety stocks to buffer variability. But - at least in the case of the three customers I worked with last week - the safety stock that was used was static and did not help at all. If you are using SAP software to run your supply chain and you are using the field safety stock in the MRP2 screen you are doomed by the static behavior of such a static safety stock which does absolutely NOT behave like a buffer.

Assume, as an example, that you are holding a safety stock of 100 pieces and you have a demand of 200 pieces due in 2 months from now. The MRP run will generate a purchase requisition of 200 pieces to add to the 100 pieces in safety stock, so that just before the due date you have 300 pieces in inventory (after delivery of 200 you would still have the safety stock of 100). After you converted the requisition into a PO and sent it to your supplier, the customer increases the order from 200 to 250 pieces. As safety stock (at least in SAP) is taken out of the net requirements calculation, the MRP run will generate a new requisition for 50 additional pieces. This way you'll end up with an inventory of 350 pieces even though you need only 250. The safety stock would have covered the additional demand and that is what it is actually meant to do: to buffer variability... but it didn't and your safety stock ends up in unused dead stock. this situation gets only worse if you have minimu lot sizes that you need to order.

You might say: "there is the possibility to customized the safety stock so a portion of it is used as a buffer". Correct, I say, but who does that? the three companies from last week didn't... why? because they were not aware what actually is happening.

Take a look in your own organization. I can tell you it will be worth your while if you use a coverage profile with a dynamic safety stock instead (make sure the minimum safety target is always set to 1 day). This is what we call "picking up low hanging fruit"

SAP Add-On Tools Info Days in Florida, February 15th and 16th

Systems Thinking for the supply chain

Thinking in Systems is a concept that has beenaround for many years. Names like Jay Forrester, Donella Meadows, John Sterman and Daniel H. Kim are coming to mind when you're thinking in systems.  If you want to know more about this very interesting approach to problem solving in your every day life or the supply chain in particular, google those names or read their books. You'll find a wealth of information and maybe a new obsession to effectively solve problems... not only in your supply chain.

In fact we are dealing with systems all the time, whether you're aware of it or not. Your family is a system, the toaster in your kitchen, a football team or ... Anything that has interaction going on and can be described by interrelated and interdependent components (which by itself might represent yet its own system) is a system. And a system differentiates itself from a collection by these relationships and interactions. A database of parts and product information is a collection but as soon as you start buying these parts to consume them or put them into inventory you are operating within a system.

If we are now starting to think in systems we look not only at the parts in a collection but at its 'whole' and its relationships and dynamics. Traditionally, most of us take an analytic, reductionist view on our problems. We take things apart to investigate sources and outcomes. In systems thinking you put things together, look at behavior over time and, maybe most importantly, consider delays and their effects (which we mostly disregard in the analytical view).

Delays is what confuses us when we try to do the best we can but don't understand what's going on or why it's going on. As perfectly described by the beer game (which teaches students what happens if you have demand variations in a supply chain), if you ignore delays you will end up with inexplicable outcomes that are counter to your intentions. The beer game's major insight is that when customers start purchasing a little more or a little less than before, the delay that occurs between ordering from the supplier until they deliver the goods will then causes wide swings in inventory holdings. You first end up with too much and then too little and then too much again. What is even worse is that if you have an interconnected system of 'consumer - retailer - distributor - manufacturer' over multiple levels, the demand swings are exponentially propagated throughout the chain and looks like a bullwhip as the swings get bigger and bigger towards the manufacturer who ends up with total chaos.

As you probably know this is the Forrester Effect, or otherwise known as the Bullwhip Effect.

An analytical, reductionist approach to solving this problem makes it very hard to see what went wrong. If you look separately at the retailer, distributor, manufacturer you won't see the dynamics between them. What ends up happening is the blame game when, in fact, it is no ones fault that the distributor sits on large inventories at one time and has back orders at other times. The problem lies in the dynamic of the system structure with its delay between orders and deliveries. But this cannot be understood if you look at just one part of the system and forget its interactions with other parts. In many cases one doesn't even look at the distributor as a whole but only at its parts (sales department, purchasing department, materials planning).

When you start thinking in systems you may use tools like causal loop diagrams, stocks and flows and value chain mapping to visualize structures, dynamics and eventually get to the core of the problem. Systems Thinking also provides you with archetypes - templates of repeating structures and behaviors - that you might use in supply chain management. 'Shifting The Burden" is one such archetype. In this type of a situation the problem symptom is not addressed by the long term solution but with a quick fix. The quick fix solves the problem for now but has negative consequences in the long run.

In our example we have part shortages in front of the assembly line. The problem is solved with 'heroic' expediting efforts described by balancing loop B1.

The shortage goes away - for now. In the long term though, the problem is not solved. A sustainable solution would be to improve the effectiveness of materials planning through the use of standard and proven replenishment policies after portfolio segmentation. Because the burden is shifted to expediting, there is an unintended side effect: our heroes feel good and get a pad on the shoulder every time they 'quick fix' the problem. This does not fix the problem at hand but increases the need to expediting further. Additionally, because delivery delays to the customers occur more frequently, the customers compete with each other to grab demanded product not sufficiently available and induce even more crisis on the production lines.

Thinking in systems allows you to see the dynamics resulting from quick fixes,  from not using the effective fix, delays and subconscious actions committed by players who aren't aware that they cause problems. There is a wide variety of archetypes which were developed over the years. If you're in the business of optimizing supply chain dynamics and producing better results it may make sense to dive a little deeper into the world of Systems Thinking.