Safety Stock Planning SCP planning logic will first plan for all orders, in sequence of priority.

And then it will take up safety stock planning for all buffers using the rule that downstream buffers are given higher priority compared to upstream buffers. If multiple buffers are at the same stage of the supply chain, the priority is equal among those buffers; hence SCP will choose the buffers in no specific order among these buffers. When a specific downstream buffer is picked up for safety stock planning, it may happen that along its upstream supply path there are other buffers having safety stock requirements. In such a case, the upstream buffer's safety stock is not replenished while solving for the downstream buffer's safety stock. However SCP recognizes the fact that the upstream buffer indeed has some unfulfilled safety stock requirement, and does an optimization to build production as early as possible. This may not entirely satisfy the safety stock requirement at the upstream buffer, but it adds a level of optimization so that when the upstream buffer is actually taken up for safety stock planning, the quality of the plan is better. The planning algorithm for safety stock or demand at any buffer essentially involves recursive logic. The demand / SS at the downstream buffer translates to an "ask" at the immediate upstream buffer. The ask is offset by lead time. The "ask" at the 1-level upstream buffer translates into an "ask" at its own upstream buffer, and recursively proceeds until Inventory / Raw material supply is available. At each level where an "ask" is performed, SCP also accounts for capacity constraints, alternate routings, and performs appropriate build ahead, offload etc. Whenever an "ask" is done, SCP tries to move the material on the date when the full requested quantity is available. The algorithm for SS At any buffer FG, let the ask quantity be X SCP tries to get X units on plan current; if not possible, it tries to see when the entire X units can be available - let's say that is t1 Any inventory upstream is moved to FG to reach on t1, and not earlier than that. As part of the recursive ask upstream, if the algo reaches a buffer A, there are 2 situations possible i) Buffer A does not have its own safety stock requirement In this case, the movement of material from buffer-upstream-of-A to A will happen on the date when the entire material can be moved (t2)

Even if there is inventory sitting at buffer-upstream-of-A on plan current, that will be moved only on t2. ii) Buffer A has its own safety stock requirement In this case, SCP sees an opportunity to atleast partially satisfy the safety stock requirement of A itself, by moving material from buffer-upstream-of-A to A as early as possible (t0, which may be >= plan current, but potentially <= t2), even though the "ask" date for the material was t2. As a result, there could be partial or full satisfaction of A's own safety stock in the period t0 to t2. Test Case 7 Explanation: The original inventory file for this test case consisted of inventory at 9 buffers. This was making the analysis and understanding extremely complex. The BOH inventory picture was simplified to have inventory only at 4 buffers. The run used for this analysis was executed on 11th Jan 2011. BOH Inventory (Greyed out records were removed in the simplified run):
Item 4H HPSI 100MM-SPSM 4H HPSI 100MM-SP 4H HPSI 100MM-POL 4H HPSI 100MM-WW 4H HPSI 100MM-WB 4H HPSI 100MM-CG 4HN SEED 108MM-SPSMSD 4HN SEED 108MM-WWSD 4HN SEED 108MM-CGSD Site MDUR MDUR MDUR MDUR MDUR MDUR MDUR MDUR MDUR BatchReceiptDate 11/1/2010 11/1/2010 11/1/2010 11/1/2010 11/1/2010 11/1/2010 11/1/2010 11/1/2010 11/1/2010 Qty 25 50 100 75 25 10 10 15 2

The inventory plan report for the simplified run is attached:

Inventory_plan_sim p lified_inventory_01_11_2011.xls

Let us assume the supply chain is as given above. There are no capacity constraints and the plan.current is on 11 Jan 2011 Operations are not shown in the above diagram. Lead time (cycle time between buffers) and Beginning on hand (BOH) are as shown in diagram Also minimum Safety stock target (SS) is specified on the buffers and There is only one demand for 5000 units on 19 May The planning algorithm works as follows First it will try and meet the demand. In doing so it would consume the available inventory first and asks for rest of the quantity from upstream. For eg, it would take 25 from the available inventory on 19 May at SPSM, there by reducing its profile to zero and request rest of the quantity (5000 25 = 4975 units) upstream. The buffer profile after planning this demand is as shown in the above diagram Next it will try to meet the SS going from downstream to upstream. All buffers at the lower most level are first selected and it takes one buffer at a time from the selected list.

In the example here, the buffer is SPSM, which has a desired profile of 1000 units. The existing and desired profile is shown in the below diagram

The algorithm first computes the difference between the desired profile and available profile (Here it is 1000 25 = 975). Starting from plan_current, it will decide the point where this value is positive and make a request on that date. In this case this happens to be plan_current itself and the request is for 975 units. It asks for the rest of the amount (25 units) on 19 May to meet the desired profile. It picks up 975 units and propagates upstream and the finds the time when this quantity is available in FULL. The full quantity of 975 is available in FULL only on 03 March (because of upstream leadtime constraints). We will see in a moment how that actually happens in the upstream. When this SS propagates upstream, the profile on SP buffer is as given in below diagram

On 3 March it needs 975 and there is a lead time of 7 days. Hence it sees that 50 is already available in the profile and splits it up into 925 on 23 Feb and 50 on 12 May. The 25 units of request from downstream also comes on 12 May only. Note that it propagates one request at the time, goes all the way upstream gets this quantity and in the process updates the buffer profile. So here it first picks up 925 and goes upstream. 25 and 50 units on 12 May is just also shown in the above diagram.

When these requests are propagated to the upstream buffer POL, it sees that the desired profile at plan_current is higher than the actual profile and hence asks for all these quantities (925 , 50 and 25) on plan_current itself. Let us now track the 925 units The earliest time from plan.current when 925 can be made available in FULL is on 19 Feb (based on upstream lead time constraints). However 50 and 25 can be made available in 3 days (lead time constraint from upstream) and reaches on 14 Jan. The profile when the ask returns at the POL buffer is as given below

Let us take one request of 925 going upstream to WW buffer

The ask is on 16 Feb for (925 75 = 850 units) and another 75 units on 05 May. Note that it is able to get the full quantity of 850 and 75 on 16 Feb and 05 May respectively Now let us take the second request of 50 units coming from downstream. It sees that 50 units is available in it profile and gives it immediately. We call this as inventory reallocation, where 50 units is provided on 11 Jan (plan_current) and

subsequent ask is made for 50units on 16 Feb. Similarly, for the next request of 25 units. So the profile of this WW buffer at the end of the request coming from downstream buffer SPSM is as given in the below diagram

Summary: SS propagation happens from downstream buffer to upstream on the JIT date. However, when SS is specified on a buffer, it starts from the plan_current and sees the first point at which the desired profile is higher than actual profile and makes the request on that day. The default behavior is to get the requested quantity in FULL. However, in a volume run the number of asks would be higher and many times for small quantities. This will lead to satisfaction of these small asks on plan_current. That would explain why a portion of the BOH inventory is moved immediately on plan_current but some is used later in time. Also note that it does inventory reallocation. When the profile has inventory, it allocates inventory for this request and then asks for rest of the quantity at the later date.