At Ultra, we generally advocate for transforming ERP and other organizational data into Star Schema Data Marts, and using those data marts as the input to Business Intelligence (BI) software suites. There are other valid approaches such as using the live ERP data (or a copy of it) as input to the BI tool (lower cost), or developing an Enterprise Data Warehouse (higher cost) to source the BI tool. We have found over the years that well-designed Data Marts do a very good job of meeting the needs of our manufacturing clients at a more reasonable cost than the EDW approach, and supporting organizational Change better than the direct connection of the BI tool to the ERP data. And Change is Coming!
In the last several months, our Business Intelligence Group has had a number of requests from our clients to map additional ERP systems into their Data Marts. In most cases, our client acquired a competitor running a different ERP system. This usually means that the acquired entity will be moving to our client’s “standard” ERP in the very near future.
But this transition often takes months to accomplish, and our clients generally rely heavily on up-to-date information from their BI systems, and don’t want to wait until the transition is complete to have the new entity’s data incorporated into their BI dashboards and reports. By mapping the new ERP data into the Data Mart, this can be achieved very quickly, and with few or no changes to the BI reports.
Here are a few real-world examples of this type of Change. A Data Mart that Ultra developed in 2004 for a mid-tier manufacturer was initially based on 4 ERP systems (they were in acquisition mode). Since then, they have acquired 2 more companies (and 2 more ERP systems). They recently selected a new ERP as their standard, so we are working on the 7th ERP system mapping. This is a new record among Ultra’s clients! This may be an extreme example of Change, but acquisitions are increasingly common in the current business cycle. Another type of Change that is perhaps more common with our clients is a “simple” ERP replacement. This can happen at any time in an organization’s BI lifecycle. We often implement Data Marts at the beginning of the lifecycle with mappings from legacy ERP systems that are planned for replacement, and then map in the new ERP while it is being implemented.
In another case, our client’s home-grown operational system continued to serve them well, but they swapped to a new financial package, so only the Accounts Receivable, Accounts Payable, and General Ledger components of the Data Mart needed to be re-mapped. In each of these examples, our client’s basic business model did not change, so the dimensional framework of the Data Marts continued to fit the business well, and mapping the new ERP into the existing Data Mart was a natural fit. This should always be the case if the Data Mart is properly designed to fit the business instead of any particular ERP.
The take-away from this is that sooner or later, significant Change is coming to most BI systems. In the above examples, new ERP systems imposed a Change on the BI environment. The Business itself also provides a steady stream of Changes; new lines of business, changes in the competitive landscape, supplemental systems or other external data to be merged, new (or deeper) KPIs, the inevitable “I want that for my department too” requests. The list is seemingly endless.
For some businesses, going with the ERP vendor’s “out-of-the-box” BI solution is a viable choice for a quick BI “win,” but depending on the solution’s architecture, it may be difficult to incorporate significant Change (like a supplemental system or an additional ERP). As mentioned at the top of this post, another quick win can be achieved by buying a BI software suite, and pointing it at the ERPs native data. But BI systems constructed in this manner usually fall over when trying to integrate an additional ERP, or when switching to a new ERP altogether.
Having a solid BI strategy and extensible BI system components in place helps organizations embrace Change quickly and cost-effectively, without forgetting the past (transactions in the “old” ERP), and without disrupting the stream of business insight they gain from their BI system.
In upcoming posts, we will look at other “real-world” examples of Change, and the characteristics of BI systems that make the changes easy or difficult to implement. And, we will examine some of the decisions that must be made throughout the BI lifecycle, and their effects on the ability of the BI system to support Change.