Do most organizations start with one style of MDM and then expand into another area? And related, is there a good way for listeners to decide where their organization should start first?
This is an excellent question. Most organizations don’t start, at least not if they’re successful, start at the enterprise, trying to do everything for everybody. What you really need to do is start with small steps if your problem is with the operational aspects of master data management.
Then what you want to do, so your operation is focused, then what you want to do is really look at the enterprise resource planning system that you have, all the enterprise apps, how many instances of them that you have, how many different definitions of products, etc that you have across them. And you want to look at the ERP vendors solutions, see if they can help you manage that data. For example, SAP and Oracle both have master data management solutions that you can apply in those particular situations.
|
View a 2-minute demonstration of InetSoft's easy, agile, and robust BI software. |
If you’re analytically focused, then you can probably have a lot more to do with your data warehouses and data marts and BI systems; business intelligence systems out there. And you need to look at the data warehouse as your anchor for that reference data for the master data management. Now most people, when they’re doing the data warehouse, can form dimensions.
That’s data modelling lingo for master data already, but they probably haven’t done as good a job as what the business needs so they’re going to have to critically look at the data warehouse marts and data integration processes and try to build a solution based on that.
Finally, if they’re in the enterprise area, which like I said it’s tough to start off with that space, and probably what they should do is decide on where the biggest issues are. On the operational side or on the data warehouse side, and probably most often they’re going to start on the operational side because that’s the base, that’s where all the data is generated. So my advice to them would be just start off on the operational side.
Once you decided where you want to start, practically speaking, how do you get started with each of these styles? Are there differences of how you get started with an operational versus an analytical MDM project?
The differences mainly are the actual processes and products that you use but whether you’re going operational or analytical, in both cases what you really want to do is assess your situation. Do an inventory of the systems that are involved, and more importantly, the data that’s involved.
So if you have an issue with customer data, you’re going to really want to know where all the different customer data originates and where it’s used, whether in campaigns or in your call center. You really need to have a good solid inventory of that, and then what the data quality issues are, because the only reason you’re trying to implement an MDM solution is because the data is inconsistent. If it was consistent then you wouldn’t have the problem to begin with.
So you’re going to really do a good assessment of the data quality issues, and then once you know the systems, the data and the quality issues, you want to really do a good gap analysis and assessment as to where the biggest problems are and which ones will provide the biggest return on investment if you solve them. But then that leads to, either on the operational or on the analytical side, to looking at what processes you need to implement, what people you need to get involved, and, more importantly to a lot of folks who listen to this, what technology or products you want to bring to bear on this situation.
And finally, are there any cautions or worst practices to be aware of as they’re getting started with any of these styles of MDM?
Absolutely, and unfortunately I think that the situation as far as what people can do, what technologies are available, the knowledge that people can learn from previous implementations is there to move forward very well, but what I keep seeing in way too many customers is two sort of worst practices.
The first recommendation is to not oversell. Don’t set expectations too high. Now part of that gets reinforced from vendors or analysts that talk about how things will be improved significantly just by implementing a product or just by doing something differently. This is a long process that takes a conservative effort by both the business and IT to solve. Otherwise you wouldn’t have problems with customer data or product data if it was that easy. So it’s a combination of system integration and products and a commitment by business and IT.
So the first step to do is to get it on the business radar and sell it as a project that’s going to take some time to implement, and they need to keep handling it on an ongoing basis.
|
Read what InetSoft customers and partners have said about their selection of Style Scope for their solution for dashboard reporting. |
The second recommendation which is sort of a corollary to that is that there isn’t any product that’s a silver bullet to this situation. If it was, that company would be a billion dollar company overnight. The reality is there are a lot of good products that can help but most companies who have built up these multiple customer lists, product lists, lists of different patients, diagnostic codes. Whatever industry you’re in, they’ve been building up for years and maybe decades, and it’s not going to go away over night.
The good news is they can work on it, and people can be quite successful at it, but don’t overbuild expectations and don’t consider that the products are a silver bullet. Those are the worst practices I’d have people avoid.
Thank you everyone for listening, and have a great day.