In my last post, I discussed how important it is to be able to effectively model your master data. In this, the second in a series on the topic of master data, I want to discuss how you need to master it. By “master it,” I am referring to the workflow-driven process steps people go through to achieve clean, consistent, accurate and harmonized master data, and having the relevant technical capabilities to make this process work smoothly and efficiently. And by “people,” I mean everyone involved.
There are a number of key capabilities required of your MDM application to effectively drive the mastering process of master data management. Here I will highlight three key ones:
First, the people involved in the process of mastering the data– data stewards, approvers, authorizers and MDM consumers — all need a means to interact with the data that aligns with their role. Even better would be an interface that is additionally driven by the context of the data. If a step in the process of making accurate master data requires a form to be completed, ideally that form is created automatically by the data and its elements, the step in the workflow, and what role the user plays and their permissions. This capability would eliminate customized interface development costs for every step in the process, and would allow you to have a more flexible process to accommodate changing stewardship actions, which may be necessary as you expand your master data domain management scope. More importantly, such a capability makes the process easier for the people involved, thereby increasing the efficiency and overall success of your MDM program.
One key area we see more and more customers requiring this for is authoring new master data from the MDM application itself. In many cases customers find it makes more sense to create new records in the MDM environment where all the necessary elements can be tightly controlled, and then deploy the master record to the systems that need it. This can include both operational systems as well as analytical systems when you are authoring things like market segments or other views that aren’t typically created in a transaction system.
Second, you need the agility and flexibility to keep pace with changing business requirements. If you have reorganized, or you are adding new data sources, or you acquired a company, or your business process changes because the business needs a new way of viewing your data, your MDM environment ought to be able to quickly and easily model the change, and also implement the data governance processes needed to master it, whether it means new governance steps or new forms. I’ve blogged before on business modeling, and the same concepts need to drive the structure of your MDM repository.
Third, you need to be able to manage change “in flight” while not disrupting current business processes. When there is a change request for a change to published master data, you should be able to simultaneously investigate and process that change without impacting what’s used in existing business processes. Instead of making data unavailable, there should be a separation between the data that is “work in progress” so it can be determined to be valid or not. When it is validated, only then is it published and available to users and business processes.
Here’s an example of how this should work:
- Suppose a CPG product manager changes the business model to add a new product grouping within a brand. This might be done because of a promotion or because they want to track similar products within a brand.
- Your MDM tool identifies all affected product master data and either automates the change or flags them for review – which step happens next will be driven by the relevant workflow step.
- The product data steward, or one of a group of several data stewards on a team, would then review and make changes from a user interface automatically generated based on the data and task at hand.
- The brand manager may be the person who needs to approve the change, which would then be “published” to the master data repository for use in brand and category analysis.
- The next time the CPG product manager views the data via the MDM consumer interface, the master data will be updated to show the new relationship in the data.
As you can see, one of the keys to enable this activity is being able to provide an interface that fits the task at hand as I mentioned in the first point above, and also drive the process through an embedded workflow capability with alerts and approval steps along the way. This would be a very cumbersome process indeed if IT had to anticipate this workflow and design custom screens for each step and each different user along the way. Imagine further how complex, as well as inconsistent, this would be if you were using multiple different MDM tools to handle different MDM domains.
We all know that master data management needs to be both people-driven and process-driven to be effective. But that doesn’t mean it needs to be manual. By developing an environment and selecting a tool that makes the process of master data management easier for all involved, you can significantly improve the success of your MDM program.