What is one of the recurrent issues that all supply chains face? Master data! Master data! And… master data!
Of course, there are plenty of other challenges to address when trying to operate a profitable and smooth supply chain, such as transactional data, with inventory being one of the black sheep. But for the time being, in this article, let’s focus on the master data topic.
It is not a mystery in planning that there is no room for error in master data because the internal engine, the so-called MRP (Material Requirement Planning) is a ‘mindless’ engine. I mean it executes whatever is commanded using master data. “Show the moon with your hand to the fool, he’ll glare at your finger!”. It’s the same with MRP. It has no idea of the optimum you wish to achieve when planning, it only glares at passed-on master data and transactional data and that’s it! IBP engines are the same.
On the other hand, in the supply chain planning community, we all know the power planners have over master data, right? Yes! nearly zero! We have no power to change or adapt master data to make them relevant for planning, because they are either owned by execution colleagues in procurement, sales, or production, or they lie at the crossroads of multiple stakeholders and therefore cannot be simply updated. In the end, achieving an acceptable master data setup is a luxury that takes time and effort. Changing a simple field of the product master in a plant may take days to happen.
That does not mean planners should be able to change anything as they need or want it without any control. If so, the situation would likely get worse. I observed this numerous times in SMEs, where the authorization concept is minimal. Everyone maintains master data like they think is right, ending with master data chaos.
Now if we focus specifically on supply chain planning, for those lucky companies running SAP IBP or any APS (Advanced Planning System), the IT operating paradigm is a little different, compared to other companies running only the ERP as a supply chain planning solution. In this case, planning is operated in a separate environment with an interface to the ERP. Changing anything in this peripheral APS system does not affect the operational execution system, only planning results are calculated there, correct?
The Question
If we could leverage master data when they get transferred from ERP, say S/4HANA, into the supply chain planning solution, say SAP IBP, would that not help the planning community to have more control over master data and therefore grind out better planning results?
And if we didn’t return those master data maintained in SAP IBP to S/4HANA, planners would not propagate confusion into the execution teams.
Is this not a bright idea?
The Previous Situation in SAP IBP
IBP allows you to maintain master data in an Excel master data workbook. Therefore, we can change data safely only for planning. So, IBP runners should be happy since the solution was released? Yes and no actually, as the option to maintain master data in Excel is way not robust enough to allow the company to rely on it and to maintain master data locally in the IBP scope.
SAP heard that feedback, likely from its ’box idea platform’, and released a new Fiori app that allows maintaining the master data from the IBP Fiori side, with a little more control. The situation has therefore been cleared! Do you agree?
No, not yet. It is a little better, but far from a reliable and quality-based master data framework. You can override Material Type by “TUTU”, Brand by “YUMYUM” and so on.
In other words, granting users the right to maintain master data through Fiori or Excel is not enough to ensure quality.
You may upgrade the data model definition proposed in the SAP Sample SAPIBP1 to introduce checking rules, which avoids turning Brand into “YUMYUM” for instance. However, the design of IBP is not comparable to the existing robust master data maintenance in S/4HANA with transaction MM02. The difference in S/4HANA is that the transaction is controlled by a dedicated ABAP code to ensure minimum of structure, whereas in IBP there is no coding option.
The Previous Tradeoff
The only option left, so far, is to ensure master data consistency at the IBP entry gate. This means, at the time the master data is uploaded from S/4HANAa any rule to apply shall be placed in the interface definition supported by the CI-DS component. This is also the only place in the IBP scope where you have access to some coding, either in the CI-DS platform or externally in the S/4HANA source system at the time of the extraction within the IBP add-on.
By doing so and provided you spent a huge amount of time on the design of the integration, the master data situation in IBP becomes cleared from traps and therefore does not really require people to maintain them locally, be it in Excel or Fiori. Although this option remains useful to planners for displaying master data content, it is a challenge. During an IBP implementation project, when applying this strategy, the key person in the project is the one dealing with the interface on CI-DS. Usually, integration consultants have limited if not no clue about the functional utilization of this master data, in heuristic or optimizer, nor how the disaggregation runs against business rules. The only two options left to make the project a success is either to find the ’rare pearl’ among integration consultants, however, they are not many 😊, or to write robust functional specifications followed by extensive testing.
The Smart Idea
As a matter of fact, in July 2022, while making the global design of an important IBP project at Camelot, I introduced a rule-based master data management, to happen in IBP.
We created a POC that worked, ready to be signed off and to continue with the development of CI-DS. The reason was that, after more than 20 implementations since 2015, the recurring question of master data quality was again a key customer focus. Indeed!
By going in the direction of ruled-based mater data management, you naturally relieve the integration team from the complexity of master data, taking over this part of the job from the IBP functional perspective. Less need for a Mr./Mrs. Rare Pearl, at least concerning the mapping of master data inherited from S4 into IBP.
Note: The mapping is a required phase as in S4, master data do match exactly with those in IBP. For instance, MRP type and lot sizing procedure in S4 are not aligned with IBP capabilities and therefore need alignment during integration. No surprise, IBP is a tactical tool that does not need the details of S4.
In the IBP project I was referring to the idea of rule-based master data management in IBP was postponed to a later phase. In the meantime, SAP has delivered a standard solution that exactly covers this domain. The solution is called ’Rule-Based Master Data Maintenance’. What a coincidence!
Now with this new feature (also see here), you can apply many rules to ensure all of your master data are consistent in IBP, at least and at last!
The feature is easy to use and operate:
- You adapt the business roles to enable them for this option.
- Business maintains master the data rules for products, location/products, resources….
- You run the rule-based job in IBP, likely right after the job that integrates data from S4, to transform your local data in IBP!
Nothing fancy and graphic on screen but efficient.
Conclusion and Way Forward:
This interesting new feature in IBP definitely brings added value. However, it is still only half of an efficient setup. It improves the planning side with local remapping options.
The recommended way to go is still to tackle master data quality and robustness, globally at the company level, according to MDM principles and best practices.
This extended approach of master data management is one of our core competencies at CAMELOT, with a dedicated team operating with a methodology, advanced practices, and innovative solutions, for the benefit of our customers. In case you learn more, just drop me a line.
If you like this article, “Like” it, “Share” it, “Comment” it, we grow by exchanging opinions!
