Boost your productivity with SAP Build : create code-free applications in the blink of an eye!
Discover SAP Build, SAP's revolutionary application development tool. Simplify and...
Official SAP answer is “There are no tools to migrate from SAP APO to SAP IBP”. This concern is way far from being a technical issue? The question is very valid and raises a number of related concerns to address. Such project, called migration path to IBP, mainly consist in re-implementation.
Investing in APO has definitely been a matter of big € investment, years of development, of change management, of process alignment and definition. Therefore, company running APO need to undertake such a migration path, preventing APO capital not to simply disappear, building up on existing context, toward IBP, although some of the initial investment will be lost, replaced by the new proposition.
The related topics that instantaneously pop may be :
SAP IBP being a buzz word, there are many articles describing the interest of this SAP solution, which can be summarized as : SAP IBP is a must to consider in selecting Advanced Planning Tools. A very good point consists in renting a starter edition IBP tenant for a very little cost, helping in assessment phase. See SAP Integrated Business Planning. Obviously renting is not enough, you need then to learn. Better asking professional to help.
APO licenses are not convertible in IBP equivalence. This is considered as a new product. Licensing metrics in IBP are different from APO and cannot be taken as a good input for evaluation. IBP pricing is worldwide, based on company turnover related to your project scope. It has been recently revisited to position IBP as a valid option for all companies, starting 200-300 M€ turnover, and of course above. IBP being only available in SAAS in the SAPCLOUD. That means you will switch the economical model from capex to running charges, through a yearly subscription. Minimum 3 years. Better asking your SAP account manager what would be such subscription in your case.
Although IBP covers practically APO domains and even more, implementing IBP will should be considering as a project. be a consistent and important project, not a technical migration. In other words, your organization should take advantage of the SAP IBP implementation to reconsider processes, roles and functions. Nothing exceptional by the way, Supply Chain as evolved so much since APO beginning in 1998. Nowadays Supply Chain requires still the fundaments covered by APO, but much more on performances, simulations, reporting, as well as how your company addresses its own market. Indubitably APO to IBP migration path includes a change management program, even if SAP IBP user interfaces are much easier to handle.
Is it wise migrating from SAP APO to SAP IBP? Yes indeed!
APO was a solution held on premise whereas IBP is in the SAPCLOUD. That means with IBP, at least that your internal IT BASIS people will have to play different tasks and roles. At the same time that also mean by running IBP you do not decide anymore when to apply support packs and upgrades, SAP makes it for you. Thank to these releases, your system is always up to date and you can take advantage of the new Functionnalites. Since 2016, the pace is a quarterly release, current being 2002, next to be 2005. At TeamWork we propose our customer a dedicated program to keep up the pace for them and relieve them from watching each and every evolution. SAP makes it well be providing the roadmap, many webinar to present evolutions.
Nothing new in calculating the MRP explosion, it is only going faster and more complex, with changing demand, volatile supplies, compulsive decisions etc… Supply Chain faces the VUCA principle and need to adapt so as to keep on focusing on the only company goals that are growth and margin based.
So existing classic processes like promoted by APICS are even more valid, whereas new thinking is also surging like DDMRP. In both cases, processes need to be more demand driven, with tensed flow of information and rapid material flow. These are the base pillars of DDMRP concept, whereas on the classical side, there are things to be done in that directions. IBP as a solution allows you both ways, with a DDMRP module that respects the 5 steps or the operating model, and the other modules that will definitely help you stretching the other standard processes to more options, performances and visibility. Once again, all of this makes a migration path from APO to IBP something different to a technical upgrade.
Is it interesting migrating from SAP APO to SAP IBP? Yes by far!
With introducing Cloud for IBP, SAP had to prevent customer’s system integrity, as they all run in virtual instances in the SAP IT Farms. In other words, SAP had to close any possible security breaches by forbidding the options of custom developments in IBP. No more User Exit and BADI in IBP despite behind the scene, IBP is still an ABAP Stack solution.
Considering APO implementations are deeply customized with numerous specific programs, functions and BADIs, that is a special topic to consider. On the other hand many of those bespoke bits were quite ergonomic oriented, APO not being a model of user friendliness friend.
With IBP new proposition, in FIORI and Excel, many of these bespoke elements may just be dropped.
For those related to business rule calculations, they will have to be converted either in IBP formulas (see previous articles).
APO was made of 2 neighboring worlds. One made of timeseries (DP, SNP), interfaced with ECC through interfacing principles, and the other being focused on orders (SNP, PPDS, GATP) which was connected in realtime with ECC. In timeseries side customer used to configure their data structures as Planning Areas, sort of information cubes that include business dimensions (material, customer, locations…) and data as key figures. On the order based side, APO was quite defined by SAP with given calculation engines and predefined displays.
In IBP there are still 2 worlds, timeseries (TS) and Order based (OBP), both being connected to ECC/S4/APO with interface principles. TS connects with CPI-DS component, whereas OBP connects through SDI component.
IBP configuration is similar to APO-DP, with planning areas, key figures and attributes (instead of characteristics). Similar but much more evolved in data structures to allow things which were impossible in APO without ABAP.
APO macros have now turn to be formulas and operators in IBP. Operators in IBP include dedicated calculations according to each domains. Heursitic, Optimizer, Propagation, Forecast, are some of those available operators.
With SAP cloud solutions, IBP, S4, HYBRIS, Success Factors…, companies must engage IT strategy transformations, being on the HR side as well as security, legal, system availability, feature evolution. Along our last 5 year experience with IBP with observed several times our customers were facing the Cloud things for the first time with IBP, as it represents an important element of their IT landscape made of ERP, CRM, BW, APS… First concern is being about the data security flying in the web. Handling it in an On Premise landscape is way different to a Cloud based one. Same applies to system availability, outage windows, support and maintenance etc.. No doubt the new IBP proposition is really well organized and controlled by SAP in that regards. Since we started the IBP journey, we never saw any major failure, processing of misfunctioning by SAP is always extremely quick.
Migration to the cloud is not instantaneous, involving connections between On Premise and Cloud, also Cloud to Cloud with regards to performances, volumes, encryption…
So migration path from APO to IBP relate to many domains, not only to performances and features.
Is it connecting worlds migrating from SAP APO to SAP IBP ? Yes 3 times yes!
APO to IBP migration path is nothing like a turnkey solution or a mobile app. Likewise APO, implementing one of the 6 IBP modules is about 6-9 months based on RDS (Pre-configured & Rapid Deployment Solution) options and even more when starting from scratch. SAP pushes more and more partners like TeamWork to provide their customer with the RDS capabilities, to comply with market trend toward built-n solutions.
At TeamWork we do propose such RDS for Demand, S&OP, Supply and DDMRP.
To keep company focused on the migration path, we usually propose starting with S&OP that is not part of APO, so as to raise interest, motivation, along an efficient Supply Chain roadmap. Based on flexible integration to other component, it is quite straight forward to connect IBP-S&OP with APO-DP and SNP. The next steps in the migration path are logically Demand and Supply.
To conclude this introductory article, wish you going further analyzing your own migration path, feel free connecting with us. This is definitely worth doing!