What not to do on an analytical MDM project: Five mistakes to avoid

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

Continue Reading This Article

Enjoy this article as well as all of our content, including E-Guides, news, tips and more.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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.

For more on operational and analytical MDM

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.

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.

For more on operational and analytical MDM

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.