Friday, July 10, 2015

Are you respecting your Planning Horizons?

SAP software provides excellent planning functions and capabilities. But before you can effectively use them one must define the planning horizons... some people, as I have seen often, do not necessarily mind if they're in the long, middle or short term for what transactions and tasks they perform.

As an example, it might happen that a scheduler turns a planned order into a production order several weeks or even months before production of that order starts. Or the forecast is worked by the MRP Run (and subsequently planned orders are generated) way beyond the short or even middle term.

At my current client, we have worked on a definition and rule set for planning, which I would like to share with you, so you may use it as a frame of reference if you find it useful.

Below graphic summarizes the concept and it must be said that there are two major rules valid in any planning system:

Rule of Planning #1: "There is a point in time after which planning activities end". This point in time is not today! It comes before today, exactly at the point where the frozen zone begins. Once you're in the frozen zone you are working with production orders. And production orders are supply elements that we are not planning with anymore. we're expediting on them, reschedule them, re-route operations to different work stations and react to exception messages they received from the MRP Run when actual results differ from the plan. If you find yourself looking for a tool to automatically re-assign and re-schedule within the frozen zone you either don't have a frozen zone or you're under the wrong assumption that the planning system should not only 'plan' but also fix deviations from the plan. These deviations are due to variability. And variability can only be buffered but not be planned. Especially not after it occurs.

Rule of Planning #2: "To plan your resources in the mid and long term level and manage demand - To plan your resources and sequence in the short term level, schedule and manage supply". It doesn't make sense to reshuffle planned orders in the long term. You shouldn't have any in the first place. In the long term you are working in SOP and therefore with a planning hierarchy, monthly demand figures and SOP orders that cause rough capacity requirements (and not detailed capacity requirements). In SOP you move the demand so that capacity violations are resolved. In the mid-term you should work with Long Term Planning (LTP) and its Planning Scenarios. A Planning Scenario contains a demand program which you can simulate (with simulated planned orders) for mid-term capacity planning. Here you should also work with the demand program until you find one that generates simulated planned orders which fit into your available capacity program. That is then the demand program (Planning Scenario) that you activate into the short term. Now you can run MRP on those Planned Independent Requirements and the resulting planned orders can be sequenced, leveled and scheduled in capacity planning. The latter activity was 'managing and scheduling supply' whereas the previous activities were concerned with 'leveling demand'



Those two rules we have persistently respected and followed in our efforts to build a standardized and integrated planning system everyone in the organization is using and looking at for continuous improvements.

The sales planners enter their forecast into product groups within a planning hierarchy. SOP Orders, statistical work centers and rough cut planning profiles are used to analyze the capacity situation for a horizon of 18 months out up to 5 years. Should we encounter a problem, we're moving the entire product group demand into a previous, less capacity constrained period or fill out a request for more capital expenditure to increase capacity and meet increasing customer demand.

When the leveled demand is dis-aggregated from the product group level to the actual product, we then transfer the demand profile into Long Term Planning (LTP) where we simulate various demand programs and generate stimulative supply. Requirements are determined for long lead time items and the procurement process is started if necessary. During Phase 1 of the mid term - 12 months to 18 months out in this example - we let demand changes from the SOP flow in and integrate these into the demand programs. In Phase 2 of the mid term, we perform detailed capacity planning with stimulative planned orders and find the best demand program that fits into our available capacity.

The activation of the demand program (transfer of Planned Independent Requirements into MRP) indicates the move from the mid term to the short term planning horizon. After MRP is run, planned orders are generated which we can sequence, level and schedule within available capacity on the bottleneck work center. 

The last planning activity then is to take all leveled and sequenced planned orders of, say, one week and perform a collective material availability check. Now you have ensured that all materials and the capacity is available for all the orders to be executed and you are ready to move these orders into the frozen zone. This is done by collectively converting the planned orders into production orders for the next week. From then on - within the frozen zone and into backorder scheduling - all planning has stopped. Anything that happens against the plan needs to be adjusted manually. If a work center is down, an alternative work center will have to be found and the sequence in the work order changed manually. 

This last point is especially important as I often get asked if one can automate this function. But in my personal opinion this is an impossible proposition. To actually do so one would have to build all possible cures to an exception into the basic data (production versions, alternative BoMs or routings, etc) and you can not possible do that. It is much better to have someone who is close to the exceptional situation pick an alternative and just change it into the order. 

...after all, that is the whole reason why we';re comparing 'actuals' to the 'schedule' and the 'plan'

4 comments:

  1. Hi Uwe;
    Thanks for an excellent post. You did a great job in differentiating three distinct phases i.e. Planning, Scheudling and Execution. There are so many organisations who mix all these three under the banner of planning and suffer from having to firefight all the time. Could you please also elaborate more on the SAP solution you used in implementing these principles? Most importantly I am looking for your view on the role of APO in this context.

    thanks in advance for your response;
    Vishal

    ReplyDelete
  2. Thanks Vishal. APO did not play a role in this implementation. Of course it can but my client chose to use standard ERP-SOP, Long Term Planning (LTP) and MRP to execute the planning part of the solution. ERP provides all the functionality to realize an integrated planning and execution system. This specific client has extremely high expectations in terms of planning efficiency, standardization and quality. Using SAP-ERP (even the older release 4.6) proved to be an excellent tool.

    ReplyDelete
  3. Thanks Uwe for you prompt reply. That is impressive. I think where we found SAP-ERP lacking in implementing a similar solution was our requirement to manage demands at CVC (characteristics value combination) level and also not-so-friendly user interface. I am not saying that APO interface is fantastic but definitely a bit better than SAP - ERP.

    What pitfalls/challenges/opportunities you see using APO over SAP-ERP for implementing this?

    Regards
    Vishal

    ReplyDelete
    Replies
    1. Hi Vishal. I don't see pitfalls in using APO over ERP... it's much more that people think ERP can't do it. But there is so much in ERP that is not documented well and no one talks about it anymore. If you attend SAPPHIRE and other conferences you will now also get the impression that APO can't do it anymore... from now on you will need IBP and HANA to plan your business (tongue in cheek :-) )

      Delete

Note: Only a member of this blog may post a comment.