Just mentioning master data management (MDM) will cause businesspeople’s eyes to glaze over and most IT folks to run for the hills. Why does MDM create puzzlement and apprehension? The principal reason is that they need an IT buzzword dictionary to interpret the rather lengthy and complicated definitions. Despite the inherent reluctance, a successful MDM program needs businesspeople to understand it, sponsor it and commit to being part of the solution, along with IT to design, build and deploy it. And before any of that happens, you need to have a two-way dialogue about it.
Before you start discussing MDM, you should target your audience. For businesspeople, never start the conversation using the MDM terminology, at least not if you wish to have a discussion rather than a monologue. You need to frame your discussion in business rather than in technical terms. MDM is really a very simple concept to explain if you take this approach.
Your conversations with the business will be framed based on your vertical industry:
MDM is not a product. You will use technologies and products to enable a solution, but no single product is a silver bullet. People and processes are needed on an ongoing basis to define, interpret and manage reference data. Businesspeople have to reach a consensus on how to make the data and its associated filters and metrics consistent and comprehensive for the enterprise. No software in the world is going to resolve a disagreement between businesspeople on who is a customer or patient (if you think that’s a no-brainer, you haven’t worked on reference data), let alone more sophisticated metrics like lifetime profitability.
Technology will be very useful for data integration and data cleansing, but the critical success factors will be business/IT involvement, an enterprise-wide data governance program and an ongoing commitment to maintain the reference data.
One of the key inhibitors to a business’s single version of the truth is the lack of consistency and integration across reference data such as customers, products, suppliers and organizational hierarchies. Sales territories and account structures are the classic example. By the way, the reference data is referred to as dimensions in the business intelligence world and master data (or lists) in the operational systems such as enterprise resource planning (ERP) applications.
In order to determine where to begin addressing the problem, you need to determine where your problem is or where the business pain is most evident. There are three potential areas to address: operational, analytical or enterprise (both). You should focus on managing reference data in your operational systems, such as your ERP application, if data synchronization across systems is inhibiting the business from running the business. Many companies spend a lot of time integrating product lists, for example, between various enterprise applications to keep them consistent. This would be a flag that you should look at a solution that concentrates on systemically improving application integration of reference data.
If, on the other hand, your business is spending a lot of time trying to conform dimensions between your data warehouse and reporting/analytics, then concentrating on managing the reference data here is where you should start.
If your company is having issues in managing reference data in both your operational and analytic systems, then you need an enterprise solution. A word of caution: in this situation, you need to limit your scope if you want to have a fighting chance of success, so start with the area causing the most significant business pain.
Just as with any rehab program, you cannot fix a problem until you accept that you have a problem. And that includes accepting your responsibility for the problem. In future columns, I will discuss how to approach and work toward solutions.