SAP for Supply Chain Planning (SAP APO and SCM)

Written by David Brewerton Wednesday, 24 August 2011 00:00 PrintE-mail

I decided to write this article after reading "What is the Real Cost of SAP-APO" in the SAP APO Supply Chain Planning Blog which is worth reading. If you're considering how to bring Supply Chain Planning into your SAP world and looking at APO (now part of SCM) then you might find this interesting...

SAP Terminology

A few terms to help the uninitiated:-

  • SAP - World class, highly integrated business system processes and software used by many of the world's largest and medium sized businesses.
  • APO - 'Advanced Planner and Optimiser', SAP's primary module aimed at supply chain planning, now morphed into SCM 'Supply Chain Management'.
  • PP & PP-PI - SAP's modules that deal with the business processes around manufacturing and supply operations. PP is essentially a production job model responding to customer orders, whereas PP-PI is aimed at continuous production models - most factory scenarios.

My Background

Since 2003, I have spent most of my time understanding and implementing SAP APO supply chain planning systems in many business scenarios within the FMCG market, as part of the Nestlé GLOBE programme. Prior to that I worked on joint work between Nestlé SA and SAP AG to establish a business process template based on SAP for food manufacturing business scenarios. Still further back, I implemented SAP for manufacturing operations and Oracle before that.

What is SAP APO or SCM

SAP in a system sense, appears to be a highly integrated set of modules. Mostly these modules sit within what is called R/3 or ECC...the core part of SAP. Core SAP holds the reins on integrated data throughout the SAP world so data about a plan to make something is all within core SAP and is linked in to master data defining materials and resources.

The SAP functionality to build supply chain plans is also within core SAP but in reality for most purposes it was considered near unusable in any practical sense. The practical side of automated planning requires a great deal of computing power and, for that reason, APO was conceived.

APO is now packaged within SAP SCM. APO is in three parts:-

  • DP - Demand Planning (forecasting) - can be linked to Customer Relationship Management to pull data about campaigns etc from there.
  • SNP - Supply Network Planning - it views the organisation as a network of locations (factories and distribution centres primarily) which all have individual stock projections and stock keeping criteria. Calculations in SNP drive dependent requirements down to supplying locations (production and receiving stores).
  • PPDS - Production Planning and Detailed Scheduling - the production plans are calculated here to meet the dependent requirements from locations within the supply network, passed down from SNP. PPDS is linked in with Material Requirement Planning, which is part of core SAP, to schedule inbound material components required by the production plan.

Master Data and Integration between Core SAP and APO / SCM

Despite APO now being on its sixth sojourn, it is still a long lost cousin in SAP integration terms. APO has many master data tables that mirror core SAP but generally with different names and with more attributes that are specific to planning. APO also has various planning versions which support what-if planning, each planning version can have its own version of master data.

The overall picture is one of a lot of master data complexity to support the functionality. However the complexity is really needed to support these calculations when you understand that SAP is highly configurable and has to deal with many different scenarios. Of course your company might be only interested in 20% of this opportunity and the other 80% is essentially noise! This isn't a APO fact, this is a SAP one and to be fair one that is general for all configurable enterprise systems and not just SAP.

Where APO and data does become complicated in a peculiarly SAP way is that it has something called the Core-Interface that passes master data and transactional data between core SAP and APO. As transactions and master data changes pass through this interface, trying to keep the two systems in synchronisation, they can frequently get stuck when activities happen out of sequence! This places heavy demands on the users (of various departments) to do their activities following a script with a specific sequence.

When activities happen out of sequence, transactions for the material or product in question get held in a queue needing manual intervention. Someone will then have to diagnose the problem and unpick it! Working with APO requires specific technical support in this area. For a large company this role will be a full time job and for an international company, there could be a team of people doing this!

Production Plan Calculations

Production planning uses a number of graphical interfaces, the two main ones being:-

  • Production Planning Table - spreadsheet type interface with plan quantities in cells which represent a bucket of time (month, day, shift, etc)
  • Detailed Schedulers Planning Board - Gantt type planning board with time as an axis and orders appearing as slugs in time.

Planning and scheduling calculations can be done manually by typing numbers into cells or dragging and dropping orders into new positions. It can also be done by background calculations. There are two broad approaches - Heuristics or the Optimiser.

Heuristics

I remember as an under graduate being told heuristic methods were those arrived at through experience..."suck it and see" approaches. SAP uses the term to mean customisable calculations based on an underlying algorithm to do a specific job eg. create new planned orders. Customising in this context would be getting the algorithm to create orders based on specific parameters. In simple planning terms, heuristics are a bit like MRP calculations and for most people much easier to understand and predict.

Optimiser

There are lots of ways to "skin a cat" as the story goes and similarly there are usually many different ways of creating a production plan, all of which may well be valid! The chosen plan will be chosen because it prioritises one aspect above others or maybe there is a hierarchy of important aspects to achieve in the plan, eg. just in time, maintain shelf-life, etc.

The SNP Optimiser uses the relative costs of factors that it can rank to produce a MPS plan. You set the Optimiser off and give it a period of time to do its calculations. It will calculate the plan many times over and when you stop the clock, it checks to see which of its plans was achieved at lowest cost (ie. highest achievement of rankings).

What's it like using APO?

Unless you have very flexible and short supply routes, the SNP Optimiser is very difficult to use because every time you run it it will come up with a different answer. Most continuous process businesses can't cope with changing their inbound supply plans to this degree and so the Optimiser if used at all, might have to be restricted to those materials that have components that can be sourced very quickly.

The heuristics provide a means of working with APO that most scenarios can cope with. Some levels of planning become an automatic reaction to plans in other areas and so these can be set to automatically plan each time something changes that relates to them.

From a planners perspective, APO is a heavy tool to crack a nut but they are likely to be relating a lot to spreadsheets and failing to see the positive side of APO in being integrated with their other business systems. You raise an order in APO and it gets worked on in core SAP, APO being updated in real time with what's going on for stocks etc.

I recall visiting a planner three years after I'd implemented APO; lets call him Jim. Prior to SAP, he had a very flexible graphical planning board and all their questions were based around how can SAP be made to be like the tool they had. They had no integration between that tool however and their MRP and stock control systems and that could often cause them stock-out surprises! So it would be fair to say that Jim wasn't overly keen on moving to SAP and APO. Three years on, he was managing considerably more production capacity and singing APO's praises. He was well aware of its problems, including the poor integration between APO and R/3 but it was bringing him more benefits than he had previously and as a factory they had learnt how to manage their processes more effectively, which in turn brought fewer integration problems.

Resourcing to support APO

I had the privilege of working with APO's founder PP-DS developer and now SAP Director, Guy Lauwers, on a prototype project between Nestlé and SAP SA in 1999-2000. APO PP-DS has changed little in concept since its days known as PFS. Since then, with over ten years of APO, SAP have studiously avoided tackling its integration issues. It is a great shame as it is the single biggest drain on resources to support APO and continues to undermine its credibility.

I hope my description of SAP APO and what it entails has opened your eyes rather than put you off. If you're using SAP as an enterprise-wide system, SAP APO is very usable. It takes quite a long time for planner to pick up because there are a lot of buttons and widgets that create noise for learning and half of their understanding is in how their process now interconnects in real-time with other processes within the organisation.

So expect to have to spend time and money on supporting APO and when constructing project plans remember that APO can only plan when all the APO master has been built on top of the underlying core SAP master data. Don't expect rabbits out of planners hats if you haven't allocated sufficient project time for this activity!

Author: David Brewerton ♦ 5th April 2010

For further advice

We provide help and strategic advice for businesses considering using APO as part of their SAP landscape.

Contact David at Squirrelhouse Consulting to briefly discuss your needs with no obligation and provide consultancy at our standard rates.