When it's done right, an analytical master data management (MDM) project can serve as the backbone of data warehousing...
and business intelligence (BI) initiatives by helping you make sure that the data used for reporting and analysis is clean and consistent. And if an MDM system is architected correctly, it can later be expanded to the operational parts of your business.
But failing to properly design and execute an analytical MDM process can result in BI shortcomings and lead to problems when the time comes to expand a deployment into an all-encompassing enterprise MDM initiative. Based on interviews with industry analysts and IT professionals with MDM experience, these are some common mistakes that can send analytical MDM projects off the rails:
Not agreeing on what analytical MDM is and what your goals for it are. The phrase "analytical MDM" is used in different ways by different people, and there are diverging views of exactly what analytical MDM is. To some, it’s an entirely separate category of MDM processes and technologies. To others, it’s just another MDM use case with separate business objectives from its operational MDM cousin. And many see it primarily as an easy way to get into MDM before tackling the more complex operational side of things.
That's why organizations must decide what analytical MDM means to them, because that will affect all of their subsequent decisions about how to proceed on projects, according to Rob Karel, an analyst at Cambridge, Mass.-based Forrester Research Inc.
"Be careful when assuming that everyone is using 'analytical MDM' the same way," Karel said. Organizations that are unclear on their goals and overall strategy could end up with an analytical MDM program that misses the target, he warned.
Failing to fully map out existing business and integration processes. Organizations interested in pursuing an analytical MDM project need to avoid the temptation to rush in and get started without first building a proper foundation for the deployment, said Al Moreno, IT solutions architect at TopDown Consulting Inc. in San Francisco.
The first step, Moreno recommended, should be taking a close look at business processes and data collection and integration techniques in an effort to identify the potential data governance problems that the master data management process will ultimately address.
"Map out your current strategies that you are using to deliver the data, and map out each of the business processes that you are using to develop or to create the data that you are using for your analysis," Moreno said. "There are a lot of convoluted business processes out there that are being put in place by people because they’re trying to get their jobs done."
Not understanding the limitations of analytical MDM. Analytical MDM can help organizations better understand and analyze transactional and operational data, but it does have limitations, according to Andy Hayler, founder of The Information Difference Ltd., a U.K.-based research and consulting firm. Those limitations, he said, explain why many organizations ultimately choose to expand MDM programs to their transactional and operational systems.
Hayler noted that data warehouses aggregate information about transactions, such as products being sold, and the context of that data, such as where those products were sold and what categories the sold products fall into. If the product data is flawed from the beginning, he said, then the results of analysis and queries run against the data warehouse can also be skewed.
"The trouble with the analytical world is that it doesn't really address data quality back in the operational systems," Hayler said. "If you've got 25% mistakes in the transactional system, in the transactional world you would fix that as part of the process. In the analytical world, you'll just have to live with the results of that."
This key limitation also explains why enterprise-wide data governance is essential to any type of MDM program. "Analytical MDM is much easier [than operational MDM], but it doesn't get you all the way," Hayler said. "And without data governance, MDM really doesn't mean very much."
Not recognizing the value of incorporating transaction data into the analytical MDM process. While it may sound counterintuitive, transactional data can be very valuable to an analytical MDM project, said William McKnight, founder and president of McKnight Consulting Group LLC, a Plano, Texas-based consultancy that focuses on MDM, data warehousing and BI.
MDM systems, particularly analytical ones, don’t store transaction data, McKnight noted; instead, they maintain reference and profile data about entities such as products, customers and suppliers. But feeding transaction data into analytical MDM systems can help make sure that your BI users have access to the most current information, according to McKnight.
"Every time a customer makes a purchase, their overall spend just went up, they might have changed categories, and the number of transactions went up," he said. "When you receive that transactional feed into the MDM system, you can use that information to keep your analytics up to date in real time."
Focusing only on BI requirements if you do plan to go beyond analytical MDM. Not surprisingly, analytical MDM programs are sometimes designed with only BI, data warehousing and related extract, transform and load (ETL) requirements in mind, Karel said. But, he added, doing so can be a big mistake for organizations that hope to evolve their MDM capabilities into a broader system that can support both analytical and operational needs at a later time.
At that point, other data integration technologies needed to support transactional processes within the MDM system may come into play – for example, an enterprise service bus or service-oriented architecture, Karel said. "Don’t just consider the requirements from the BI stakeholders, because then [the MDM architecture] probably won’t scale," he cautioned.