Many friends of mine asked me recently: "What exactly is S&OP?" or "What does S&OP HANA do? What is it for?". Hence now, while waiting at the airport for my returning flight, I decided to write down few notes to explain the two concepts in a way that people from areas other than logistic and operations can get an idea of what S&OP is and S&OP on HANA do.
Sales and Operations planning is a well known topic in the area of supply chain for which the readers will find plenty of literature, so here I am merely reporting the few key elements that are interesting for this selected conversation. In a nutshell, companies have the problem of the reconciliation between the Sales and Marketing activities (pipeline and order generation) and the Supply execution. In other words, for keeping a given customer service level and make sure that the ordered product will be available and delivered by the desired date, one typically always has the challenge to make sure that there will be enough product stock and that the lead times for the transportation will ensure the proper delivery to destination in time. Hence, one aspect of the Sales and Operations Planning process is indeed to bridge between Sales and Operations in a collaborative manner in order to avoid shortages or excess inventory.
Another aspect of the S&OP is to be able to plan well in advance for unexpected events like hurricanes, strikes etc or leading indicators like employment rate or wages increases in a given territory. For these "What-if" scenarios planners look at possible excess or shortage of production capacity and work in advance suitable plans for handling the going trend or handling a critical contingency.
Surprisingly, even these days very large companies do not use for S&OP dedicated software solutions that cover all their needs and often most of the analysis and simulation tasks are performed in Excel spreadsheets out of aggregated data from Advanced Planning Systems, Inventory Management systems, ERP etc. There are many reasons for that. Certainly one is that Excel is providing a shorter initial learning curve and at the same time is providing all the flexibility planning teams need. Unfortunately this leads to the proliferation of multiple, unit-specific templates with no central data repository and with the typical problem of synchronizing all the views into one or at least to provide the same data visibility to all the business units involved. In other words, typical current solutions do not scale well.
From a technical perspective the technical problem is not really so much different than what is being done in a demand planning tool. At the end of the day, one needs to model mainly time series (the evolution of a given quantity in time) and the ability to aggregate and disaggregate these quantities over time and over their "keys". These "keys" may be typically: product, location, customer etc etc. The point is that these objects have to be flexibly configured to build a model. Every company is indeed running the planning business in a very specific way and this is one of the factors that distinguish companies from each other. Planning is not precise, it is an "art" and companies use different simplified models depending on their ability and priorities.
A good tool needs to provide flexibility in the planning process modeling, as well as a good representation of the supply model that can indeed show at a good level of approximation potential under-utilization, excess projected inventory and shortage on certain product families. On top of the Supply chain modeling that typically deals only with quantities, Planners must evaluate options looking at the top and bottom line and justify their decisions --among others-- on profitability maximization or customer prioritization.
One of the biggest challenge is the volume of the data involved. Of course rough cut planning is always the choice, but the ability of looking at granular levels (i.e. Product-location in monthly or weekly time buckets) can provide significant value to the approximation used by the planners.
Just recently I was looking at a case of a subsidiary of a major global steel maker: it is not uncommon to have cases with ~70 thousand location products, 25 thousand products and from 100 to 300 locations for future planning horizons of three years in months (and two-three years in the past for inventory positions comparisons). A case like this is just a starting point, I have seen cases where the required storage is already one order of magnitude higher than this one. If the key figures are on the range of 60 to 150, now the size of the data may become very large also for BW systems. The point is that the larger the data size, the slower any calculation will be.
S&OP on HANA may be seen as a very powerful repository of time-dependent and time-independent information. The new SAP technology allows for large storage and extremely fast computations as it exploits the fast access of data in memory without having to read it from external databases (once an still now based on Hard drives). On S&OP on HANA it is possible to define very complex demand and supply models with very large key figures data sets (it is very common even at this early stage of this technology adoption to see cases with 100 up to 200 key figures per implementation). So again imagine the example mentioned before:
product-location*[ key figures ] *time buckets
73000*200*60 = 876 Mio values (for 5 years expressed in months)
73000*200*260 = 3.7 Billion values (for 5 years expressed in weeks)
The amount of data is massive. In a post like this I cannot explain all the benefits of the column-based data organization in HANA, but let's just mention how useful it would be to eliminate out of a big data matrix like this all the zero values (that certainly may be there): in solutions like APO, the application itself was handling this problem and save the information only for the non-zero values. In HANA, the database layer allows already this data compression (and of course not only of the zeros), and this makes the amount of data to be kept in memory much smaller in footprint. As smaller data footprint is equivalent in HANA to faster calculations, one can start to understand why this technology suits very well this problem. Why would not Demand Planning be suitable for this as well? Mainly it is because of the size of data that this problem needs to handle simultaneously. DP tools were built in the late nineties (SAP APO 1.0 is from 1998) and are based on BW repository and on an architecture based on Databases (DBMS) using disks. The problem of planning and scheduling production already lead SAP to develop database in memory technology back then (Livecache), but these tools are limited by the problem size they can handle.
The power and the promise of S&OP on HANA is to remove these boundaries and allow finally a well organized central planning data repository, fast aggregations and allocations distributions yet proving the comfortable user interface of Excel. Yes, SAP is not forcing anyone anymore to its proprietary User Interface. Excel is now available to planners for S&OP on HANA users and the templates provided by SAP are quite neat. The "fun" of the SAP user interface is left to us (the consultants) for the system configuration :-) .