“Without data, you’re just a person with an opinion” I learned this quote from Edwards Deming during the quality phase of my professional development. But I’ve also learned it applies to a broad range of activities, and absolutely applies to IBP.
In this fourth and last blog in this series, we’ll discuss data. Hold on to your hats, this is exciting!
Well, maybe not, but it is critical. Without accurate data as input, the results of an integrated business planning process are misleading as best and damaging at worst. It’s critical to get it right, and to fully understand the provenance of the data provided just as we discussed earlier the importance of transparency in the model’s calculations.
An IBP process will consume two basic types of data: Master and Transactional (Key Figures), with a subcategory of content that could be static master data or varying Key Figure data
Master Data is generally the simplest of these, and likely the most easily available. Typically including materials, locations, suppliers, resources, and other static elements, this data gives your IBP model it’s structure. This category of data is generally easily sourced from your existing ERP system or systems, and need be updated only periodically. In a perfect world, nothing more is required than an initial load and periodic refresh.
But of course, the world is not perfect. Several issues can preclude this simple an approach:
- You’re pulling data from multiple systems, and data is not harmonized. A classic example is material numbers differing for the same basic material across systems
- Your IBP process needs attribute data not present in the underlying ERP. One of the strengths of IBP is it’s ability to perform dynamic aggregation via any attribute associated with a master data element (for example, product family, or customer type). But often, the IBP team will want more attributes than are available, or accurate, in the underlying systems. The IBP tool can easily accommodate this, but a process will need to be in place to accurately add the new data
- Planning in the mid to long term involves master data not available in any ERP system. Again, a common issue. When you’re looking several years out you’ll often be planning for products, customers, and even plants that don’t yet exist in ERP. A process needs to be in place to manage creation of this “placeholder” data and ultimately replace with production data when available
- While master data is available in the ERP system, it is too granular to use in IBP. The classic example of this is resource modeling. While some projects are launched in environments where ERP work center and routing data is accurate, and the intent is to use IBP to do a detailed capacity plan, many more seek to use a rough cut capacity management process, testing only that throughput can be delivered given limited capacity for a few key resources. This is an appropriate approach, but the underling ERP system(s) may not have data expressed in this way. As above, plans need to be in place to create and maintain the appropriate relationships.
It’s beyond our scope here to detail potential solutions, I discuss some in my book, and your SI will have thoughts as well. Just be aware of the challenges.
Key Figure data access ranges from simple (pulling actuals from ERP, for example) to a complex (extracting opportunity data and probability from a CRM system, for example). Like Master Data, planning also involves understanding that some critical data will not be available in your ERP system or may need to be manipulated to align to the IBP model. The one constant is that any key figure data to be imported must have association to the unique key associated with the relevant master data. For example, actual sales will need customer, product, and potentially location association. There are other considerations, too:
- Data in the ERP system may need to be aggregated before transfer. As we’d noted in an earlier blog, Key Figures are a time series construct. Unless individual orders are mapped into IBP as master data to provide order level context, the transactional data in ERP (which will almost always be order based) needs to be aggregated to a time series before being transferred to IBP.
- Data in the ERP system may need to be adapted to ensure an accurate transfer. A good example here is resource capacity. IBP models capacity as a time series showing available capacity per period. In most cases, the time bucket is weekly and an average availability per week (perhaps with a second Key Figure capturing Shifts to allow variable planning) works just fine. But when the ERP system’s Calendar shows a two week shutdown, for example, the data integration process needs to capture this and zero out the Capacity Key Figure in the relevant periods.
- There may (will) be data that is not available in any system. Again, not a problem, plans will just need to be in place to capture and verify accuracy.
These issues are not new science. I discuss some in my book, and your Systems Integrator will have experience in data integration.
We noted a third category that is a hybrid data type. SAP calls this “Attribute as Key Figure”, and it enables a numeric value defined as an attribute of a master data element to behave for calculation purposes as a Key Figure. This is best used for static values, like sourcing ratios, capacity consumption, bill of material quantities, and so one. But as a powerful adaptation, an attribute as a key figure can also optionally be extended as a time series, so values can change over time. This capability is a great convenience for the modeler, but when mapping data from the underlying system this representation needs to be taken into account. Will you choose to use a single static value, and update when it changes, or do you choose to use a time series so that future effectivity can be modeled. This will be a case by case decision.
Three things to remember when assessing data integration:
- Of all the data integration use cases in the world, IBP is one of them. It’s not rocket science, and your internal IT team and your systems integrator will figure it out. As the management team, though, you need to be aware of the issue to provide guidance consistent with the objectives of the IBP process.
- Planning and creating production data integration processes will likely be the single biggest component of your project, and will take longer than you expect. Remember the 80/20 rule and perhaps don’t try to fully automate everything.
- Please also be aware the integration processes will change over time. During the initial phases of development and test, and even for the first go live, it may be pragmatic to use less automated integration.
This completes this blog series. For those of you just joining is, the earlier blogs are here:
https://blogs.sap.com/author/thomas.wright/
Thanks for reading, and may your project realize the best of success
