I was wondering what ideas you have to address a master data management (MDM) scenario such as this one:
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
There are a handful of systems containing customer and product information that which is buried in the transaction systems. There also are a few systems to track sales and products, and others for financials and billing; in total, more than a couple dozen systems scattered about across a few geographies. And the company has been around for a while, so there’s a lot of data.
How can this be consolidated or managed in a way that addresses system and data sprawl issues as well as the need for accurate information and consolidated reporting? A data warehouse? An operational data store (ODS)? Maybe a combination of the two? I’m also wondering what this would look like -- e.g., would these legacy systems feed a new database such as a data warehouse but still keep their own copies of the data, or would it all just be linked together informally?
Any ideas and discussion are much appreciated, Jill -- thank you!
Hey! This isn’t a question; it’s a Statement of Work, for chrissakes! Have you seen that Mad Men episode where Conrad Hilton wants Draper’s opinion on an ad campaign from a competing firm and Draper says, “Hey, I got a living to make here, buddy! Hire me!” Then he lights a cigarette and they stare each other down for a good long minute.
But OK, since you’re a TechTarget fan, I’ll play along this one time.
So, a lot of data “scattered about,” huh? “Buried in transaction systems?” Never seen that before. (Sorry, but you put me in a surly mood.)
Do this: One, figure out what business problem(s) you need to solve. Two, figure out what business questions need to be answered. Three, map the data that you need to answer those questions. And four, design a conceptual data model to illustrate the data and its interrelationships. At that point, you’ll know which data to source from which systems. Then you can identify new business problems that can be supported by either the modeled data or new sets of candidate data that also should go through the modeling process.
All the data that’s scattered about will overwhelm you and render you inert. Don’t focus on it; focus on what your business needs. That will take you a long way in developing your MDM roadmap. And that’s all you’re getting out of me, buddy.
Dig Deeper on MDM best practices
Related Q&A from Jill Dyché
Learn about the most common master data management (MDM) project pitfalls that companies run into. Get a list of the major problems that can hold ...continue reading
There’s a lot of talk about master data management but not so much about CDI and PIM. Find out what happened to those MDM-related technologies.continue reading
Do you need to gather business requirements for an MDM project? Find out and learn how functional requirements are the key difference between the MDM...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.