TeamWork recognized as one of the “Best Workplaces Switzerland” 2022!
TeamWork is recognised by Great Place to Work® as one...
I recently wrote an article about SAP Integrated Business Planning solution which opens a new era in Advanced planning system so called nowadays IBP (Integrated Business Solution). No doubt SAP IBP is! However, such a new product means a lot of programming, a lot of changes, and not all is available at the beginning.
Thru this new article I wish pointing out how Business Rules are possible in SAP Integrated Business Planning, how they are modeled, as well as comparing how this was done in APO. I have also placed a few thoughts about business rule modeling.
This is likely the first question you wonder.
In SAP IBP, these rules allow you to run the solution, as soon you buy it. They cover many concerns, focusing on calculation and data management so that you get concrete system answer in regards to Supply Chain Management of course. Some of them are hard coded in programs. Do programs cover your expectation? here this is get it or trash it. SAP IBP does not allow you to change any program, unless you ask SAP to do it for you. No more BADI and user-exit, neither bespoke programs, you are in the SAP CLOUD. T
he other kind of rules is configured via parameters. This is done in SAP IBP by either using the RDS (Rapid Deployment Solutions) or by yourself in configuration. This is an important SAP evolution. During the APO era you would not have any RDS, except at the very end (2014), whereas with SAP Integrated Business Planning RDS are straight available to any customer already now. SAP has probably gone thinking it was useful to provide base Supply Chain rules in RDS to shrink project timelines.
Any event, these coded or configured rules cover most of the required Supply Chain Best Practices. Here below are a few examples of these business rules
Seems surprising however this is a critical point. Being dynamic or in batch mode (e.g night job calculation) may leverage upon the Supply Chain processes.
In such a mode, the rule is performed every time SAP Integrated Business Planning access the data, every time it is read or written into the database. Either a user is reading data from the SAP Integrated Business Planning Excel ADDIN with a planning view, or a background job has requested the data. In both case, depending the read data, SAP IBP can perform a dynamic calculation while reading from SAP IBP database. Data are always synchronized. E.G. you use, as a planner, the projected stock Keyfigure. This will be calculated on the fly, when Excel request the data. This is not Excel calculating this, but SAP IBP database. The same projected stock may be requested by a background job, a real-time alert, or an analytics being displayed in the SAP IBP WEB surface (Supply Chain Control Tower). All of these events trigger the dynamic calculation of the projected stock. In the end it is always in sync.
Under this mode, data are only calculated when requested. This is for instance the case of the Heuristic in SUPPLY on Monday night, followed with a Deployment run on Wednesday evening, according to a weekly DRP process. These jobs are usually explicitly identified as milestone in given process.
At the beginning, SAP made a lot of argumentations with HANA being capable to run everything in real-time, thank to performance 1000 faster that former systems. By so doing the Supply Chain process would be transformed. So why still thinking on demand. Why not all dynamic and real-time. From my standpoints, technology is good and may lever on our process to improve them, however such real-time feature is to be compared to nervousness, which exhaust Supply Chain stakeholders, pushing them to Excel standalone. SAP Integrated Business Planning HANA is faster; possibly better than SAP competitors; let’s use this on purpose only.
On demand jobs are defined under the odd name of “Planning Operators” likewise with APO a lot was heuristic. These planning operators let you define how the jobs shall be visible and ran within your planning area (IBP database). E.G being able to run statistical forecast from IBP ADDIN Excel is done with the creation of a planning operator “Statistical” into your planning area.
So for we have seen coded versus configured, dynamic versus on demand. Now let consider the available methods in regards to what business rule
1. For the very advanced requirements there is no other way than running standard planning operators from SAP. Seems logical to get advanced calculation from such SAP Integrated Business Planning solution via programs isn’t it? They represent the true added value of the product.
This is the case for statistical algorithms, Optimizer, Heuristic, Safety stock multi-echelon. By essence they are executed on Demand, via planning operators
Planning operators are not modifiable.
2. For any other requirements, using a customizable path, I have established a scale, to better understand what method to use with regards to complexity.
Beforehand, lets revisit the APO framework. Any business rule was to be modeled in macro, at least in DP and SNP. Even for a simplistic addition you would have to design and run a macro. Macro language was a simple one, reachable by consultants and business analyst. This probably explains why APO was fairly appreciated, providing a high level of flexibility. However, the weak point of macro was the fact they were attached to planning books and DataView. In other words, you had to replicate the same macro in many places, which was not efficient from the maintenance perspective.
With IBP this has been dramatically transformed to a revolutionary model. Now data transformations rules are supported by formulas, not anymore macro. These formulas are attached to the Key Figures, so that any read or write activity in the HANA database triggers a calculation run of each requested Keyfigure. Looks pretty good, however formulas are not “jack of all trades”. They cannot do everything like macro. Let’s see that.
This is a common case where a result calls for operands in the same period. For instance, Stock value which reverts to same period stock quantity multiplied by the product cost.
StockValue(n) = StockQty(n) * ProductCost(n)
In such case, formulas are really simple and easy to maintain. They are organized by planning level, which is really a great thing. You may imagine combining several planning level together like calculating a demand level of a product-location, starting with a detailed demand plan being done at product-location-customer-distribution channel level.
See below a Stock value example where the request level defined dynamically by the user according to his selection in Excel, will aggregate the sum of each individual product*cost. So the same formula will help calculating the stock value of a product, of a family, of a sub-family over a country etc..
Let’s be simple. Let’s consider a projected stock calculation. Here the formula calls for several periods and applies a simple addition and subtraction. This is really a simple think in Excel isn’t it? Well in IBP it is not so easy.
Stock(n) = Stock(n-1) + TotalReceipt(n) – TotalDemand(n)
In such case you need to point a different period (here n-1) by means of attribute transformation. Wat’s that? A clever way to avoid programming language and still create such formula. Clever however not easy. The attribute transformation process, an SAP IBP feature, requires addition a planning level and Keyfigures, which in the end makes the readability complex. Let’s be clear this is only affecting consultants, users won’t know about it. So after 18 years of simplicity in Macro of APO DP and SNP, we have to adapt ourselves in SAP IBP. I recommend reading a recent linkedin post on this exact subject of attribute transformation. It is a useful cookbook about it.
Now let’s consider further complexity like a stock cover, a target stock, a safety stock etc. Here the expected formula do need a programmed logic with loops, with standard programmatic and conditional operators. E.G in APO for the stock cover calculation you would use the formula COVER() which was coded by SAP in ABAP and delivered in standard APO macro-Builder.
Cover(n) = Function( Demand(n to m), Stock(n), Calendar (n to m) )
In SAP IBP the coded approach is supported with the specific LSCRIPT language. It is not documented and not accessible anymore since SAP Integrated Business Planning 6.2. Here below is an example of such program. So if you cannot cover your requirement with formula and attribute transformation, you have to revert to SAP asking them to code your need into a given Lscript procedure, to be attached to the corresponding Keyfigure. This is a billable scenario not for free. In project mode that constrains money and timelines aspect. Nothing impossible though.
Up to now nothing as such. You cannot create anymore macro in SAP IBP. This is not in the SAP Integrated Business Planning roadmap either. This is a regression although it does not mean you cannot do anything. Formulas and planning operators support most of the necessities around SAP IBP
In APO all customers used to use macro in DP and SNP, which was really convenient.
Now for advanced requirement, or for formulas to be triggered on demand, which is in Supply Chain a central requirement, you need to work around in SAP IBP, designing odd Keyfigures, asking for Lscript. Forecast are not real-time, neither heuristic, neither the calculation of an MPS capacity limits etc…
No real harms, it works! It is only complex.
SAP Integrated Business Planning represents nowadays an excellent proposition, equipped with the best of breed database, a superb reporting tools, a user intuitive interface directly in Excel, all this with a rapid performant engine, available in the cloud. No doubt any benchmark will position SAP IBP in the top range.
So considering all of the available solution and what is coming along each release (4 per year), SAP IBP is really an excellent offer.