Data Governance and Data Stewardship are the MDM Guardian Angel who protects MDM initiative to go the extra mile and stand as the guardian for MDM installations to have the continuous run in the Organization.MDM systems require accountable, technically proficient business users to create and continually monitor the rules and processes created by the data governance board through changes in the business. The stewards should act in an objective manner, agnostic to any one system or business area. The term "steward" is apt, as it conveys responsibility without any claim to ownership. Data stewards are the governors making the tough decisions to keep master data entities effective. Based on the size and structure of the organization, the number of data stewards will vary. Typically one data steward for each type of business area is best. In a larger or more distributed organization, more data stewards may be required to manage the data needs at each major location. Data stewards should be experts on the data. In some cases, the steward may be a business user who intimately understands data, and in others cases someone in IT may make the best steward.
Data stewards should be designated early in the implementation of MDM for the subject area. The data steward should collaborate with an impartial business user who can manage the collection of system requirements as well as assets that already exist. Early involvement allows the steward to more completely understand each group's needs and identify any potential risks or shortfalls. These stewards are also the first line of arbitration when data inconsistencies arise.
Objections Management
When working with the current data managers within an organization, you may hear several common objections when MDM projects are initiated. With any of these objections, it is best to recognize the significant change that an MDM process presents to these stakeholders. MDM projects represent a major loss of control for stakeholders. Although the final result may result in less work for these intermediate data stewards, there is usually a general apprehension with any new processes. After all, most of these contributors took the initial initiative to take over the process when the original processes failed to keep their master data synchronized. It is very likely that other projects have been attempted to alleviate these data issues in the past. Statistically, many of these projects did not deliver on their promise, and often led to more work for these intermediate data stewards. Common objections are:
You don’t understand my data
This process will not be responsive enough
This will just add work
We can’t learn a new system
You don’t understand my data
This is a common complaint of an MDM implementation. During the process of modeling the master entities, it is common to find a number of data discrepancies that need to be eliminated from the model. Many functional systems handle smaller changes in scope by modifying the master data within the system. One example is an order processing system that does not effectively handle different roles of a customer. To handle these shortcomings in the product, a company may create multiple customer records to handle these different roles of the customer. The company has used data to manage a coding limitation. This is one of the major reasons these systems will never be good applications to manage the master data. These intermediate data stewards know intimately all of these nuances within their system. In the past they have seen projects attempt to whitewash over significant differences that provide important functionality to the organization. Whether it is multiple records for the same customer to provide invoice breakouts or alternate product specifications to handle an older model of the manufacturing machine, they are quite concerned that this MDM project will eliminate these special records. If they have looked at the cleansed records, then they may be even more concerned, as these modifications will not be found in the general records of the MDM system. It is imperative to the success of the project that the integration processes be prepared to deal with these issues. All of these differences need to be detailed and mapped, but the master records must be free from any functional system modifications.
This process will not be responsive enough
As you can see from the data steward discussion earlier, some measure of control of the master entities will be taken out of the hands of the intermediate data stewards. Most of these representatives are used to working in at least a partial data management vacuum. They may have taken into account a few systems that were dependent on their master records, but very few controls were in place and they were the final arbiter of the issues. The controls that are added to bring the entire organization into compliance will certainly create some additional overhead. Although this is a valid concern, the amount of reconciliation effort that will be eliminated should offset any additional overhead that the data steward’s processes add.
This will just add work
This is a common complaint against any new process implemented in an organization. This objection is best offset by providing a clear understanding of the benefits of the final implementation. Although certain members of the team may have additional duties, it should be communicated to the stakeholders that integrated master data provides more value and less monthly reconciliation.
We can’t learn a new system
This one is phrased in a number of different ways. It is most often heard from the users of very longstanding systems such as mainframe applications. The intermediate data stewards and their teams have made a career out of green screen data entry. Many of these individuals have been very successful staying away from the Windows world. Many view any new technologies as an impediment to their jobs. While it is likely that their efficiency in adding new data will probably suffer as they use the newer systems, most of these old systems are the largest sources of data discrepancies within an organization. Many of these systems were designed before the current IT organization was in place. Documentation is commonly dated or nonexistent. Success of the MDM implementation depends on convincing the data owners that the advantages of gaining control over master data justify the pain of learning a new way of doing things.
Many of the most intractable issues in implementing a master data management system involve getting buy-in from the stakeholders who currently own the master data. Getting them to see MDM as a boon and not a threat is key to MDM success.
Loving P&C
DC*
No comments:
Post a Comment