Ten Best Practices for Master Data Management and Customer Data Integration

digg this | del.icio.us | Reddit | Stumble It!

Update: You may also be interested in our new series, which begins with MDM Best Practice #1 – Start with the Need, Pain or Problem (Not “The Solution”).

Here are ten best practices for MDM and CDI that I’ve picked up, based on years of working as a technology consultant and managing a strategic alliance between one of the leading information providers and a large software company.

1. Active, involved executive sponsorship: this is true for many different types of enterprise technology projects, but even more so for MDM and CDI.  Most organizations are very comfortable with their “islands of data” and with technology being implemented in silos.  For someone in the organization to come along and suggest changing that status quo, and to start managing critical information centrally, treating it as a true corporate asset, is going to mean some serious cultural change.  In most enterprises, that type of change can only be driven from the top down.  This doesn’t mean your CEO has to personally be involved in every aspect of your MDM or CDI initiative.  But when the rubber meets the road, you need the “corner office” in your corner.

2. The business should own the data governance process and the MDM or CDI project: As tempting as it can be to start and finish with the technology, that road doesn’t lead to success.  I’ve seen a number of companies where the MDM or CDI initiative was driven by their IT function, but where the business either didn’t understand or didn’t buy into the program.  These projects ended up being perceived by the business as a “solution in search of a problem”.  As hard as it is to do, you need to start building enthusiasm, interest and demand for a new set of capabilities in managing and utilizing data within the business.  Otherwise, business people won’t be committed to the project and funding will be hard to obtain.  The nature of MDM and CDI (as ongoing processes rather than “once and done” projects) will mean that even if the initial project is approved, funded and completed, the business will not pick it up and run with it in Years 2, 3 and beyond.

3. Strong project management and organizational change management: This is true for other types of enterprise technology projects too, but given the amount of political angst that MDM and CDI initiatives typically cause, you need to make sure your project can’t be derailed by opponents pointing to sloppy project management or by avoidable change management issues.  If the project is “buttoned up” from a Project Management 101 perspective, and you’re using good techniques for communications, training, end user forums, etc., then it will be much harder for the champions of the status quo to throw stones at your project, and you’ll make it easier for any logical follow-on projects to succeed, because you’ll have built a strong foundation of delivering value on time and on budget, and ensuring user acceptance, adoption and achieving your expected ROI.

4. Use a holistic approach – people, process, technology and information: This may be the most important best practice.  You’ve got to start with the people, the politics, the culture, and then to make sure you spend at least as much time on the business processes involved in data governance and data stewardship.  These really deserve a separate article of their own.  But you’ll succeed if you invest the time in creating a fairly small Data Stewardship Team (or whatever you call it); recruiting the right senior executive(s) to sponsor the initiative; creating or redesigning your processes for adding new master data records, modifying existing records, cleansing/standardizing/matching, resolving anomalies, reporting data quality metrics, reporting exactly where and how the MDM initiative has met helped the enterprise achieve its strategic objectives.  The technology aspect is not a given, but you should start with “people” and “process”and let those guide your technology decisions.

5. Build your processes to be ongoing and repeatable, supporting continuous improvement: As mentioned above, data governance is a long term proposition.  I still run into a lot of people who think that a given project will “go live” and be done.  But experience has shown that as long as you’re in business, your enterprise will be creating, modifying, and using master data.  Many types of master data, especially things like customers, suppliers and products, are very dynamic.  So if everyone in the company relies on them, but no one is specifically accountable for maintaining and certifying their level of quality, it shouldn’t be a surprise that, over time, like everything else, they become more and more chaotic and unusable.  So plan from the beginning for a “way of life”, not a project.

6. Management needs to recognize the importance of a dedicated team of data stewards: Just as books belong in a library and a library needs librarians, master data belongs in a dedicated repository of some type, and that repository needs to be managed by data stewards.  I continually run into organizations where there’s no dedicated data stewardship function.  Some business areas do better than others, but no one eats, breathes, lives and dies with the accuracy, completeness, timeliness and consistency of the critical information that the business runs on.  Don’t start an MDM or CDI project without convincing management of the need for a small team of data stewards who are 100% dedicated to managing the enterprise’s master data.  Otherwise, the “lights are on, but nobody’s home”.  Master data repositories don’t manage themselves.

7. Understand your MDM hub’s data model and how it integrates with your internal source systems and external content providers: I’ve seen quite a few project teams doing CDI or MDM implementations who never bothered to spend time researching the data model provided in their off-the-shelf hub, and who didn’t plan for enough time in inventorying and mapping their internal source systems.  So when data model problems cropped up relatively late in the project, whether it was a disconnect between the hub and an important source system, or a misalignment between data modeled in the hub and an external information provider, it was very disruptive.  These problems can be avoided by really understanding how the hub is designed, and then mapping that back to your source systems and your external information sources.

8. Resist the urge to customize: Now that commercial off-the-shelf hub platforms have matured a bit, it should be easier to resist the temptation to get under the hood and customize them.  I worked with some early adopters of various hub products, and at that time, there were some genuine product gaps that forced companies to step in and modify the platform considerably.  I’m not saying that the products are perfect or that there are no gaps, but sometimes pushing the vendor to make improvements and to incorporate them into upcoming releases is a better strategy than customization.  And when you do customize, do so very carefully.  Make sure your changes are “upgrade-friendly” and documented.  Most vendors are still revving their products as often as twice a year, so you definitely don’t want to get into a situation where you are “rev locked” to an older version.

9. Stay current with vendor-provided patches: Given the frequency of point releases, patches and major upgrades, you should probably plan for at least one major upgrade during the initial implementation, and be sure to build “upgrade competency” in the team that will maintain the hub platform after the initial project goes live.  Nothing is worse than to contact the software vendor for support, and to be told “that problem is fixed in the last release”, but to not be able to move to that release for months or sometimes years.  Vendors are fixing problems reported by other customers every day; make sure you’re in a position to take advantage of those fixes, and then have the discipline to do it. And make sure to follow the upgrade instructions carefully – those README files are there for a reason!

10. Test, test, test and then test again: This is like the old saying about what’s important in real estate – “location, location, location”.  Your MDM hub environment is going to be different, by definition, than every other environment in the world.  Your company has a unique quantity and variety of source systems – the applications for CRM, sales force automation, ERP, customer service, you name it – and of course, some of those systems are going to be completely inhouse-developed and won’t exist anywhere else.  So while most software vendors are doing much better in the area of testing and quality assurance, in this particular technology domain, the burden of testing remains squarely on the implementing company and the project team.  Don’t assume that because something’s in general release, that it’s going to work perfectly at your site.

These aren’t intended to be an exhaustive list of best practices, but they should get you thinking and hopefully, save you a little time or help you avoid some of the more common mistakes companies make.

Master Data Management, in all of its various forms, is an exciting area of technology and offers companies a real competitive advantage in terms of how you can use corporate information to make better decisions, to avoid regulatory snafus, and to provide better customer service.