Showing posts with label Data Steward. Show all posts
Showing posts with label Data Steward. Show all posts

Wednesday, November 27, 2013

What does represent for you Enterprise Information Map? | LinkedIn Group: MDM - Master Data Management

Follow the LinkedIn discussion

My comment 

Your approach perfectly makes sense.

Call it "Enterprise Data Architecture", call it "Enterprise Information Map" - it is indispensable to get ready for the future. In any medium and large organization, (almost) all operational units create, update, use and interpret data for the major part of their daily business duties (even where tangible goods are produced using machines, the latter ones are data-driven.) Consequently, medium and large organizations are first and foremost in "information business" (whereas the underlying data model may vary depending on the industry).

An Enterprise Information Map is therefore not only helping the CIO to develop a road map from a siloed to an integrated application landscape, but should primarily serve as a blueprint for the CEO (with "E" as in "Executive") to pursue the alignment of the operational business units with the "new reality" of being an information business. The CEO should assume leadership in this alignment process, nominate responsible parties and monitor progress and results closely.

In a nutshell, the alignment includes (but is not limited to) business (not IT!) activities such as:
  • Design the Master Data model as the core piece of the Enterprise Information Map
  • Assign ownership of information entities to business units 
  • Identify "central" information entities without "natural" owner (such as master entities Party and Location as well as reference data) to a (new) central unit responsible to conceive mechanisms for management and governance of "central" information entities and to license the above mechanisms for reuse in decentral business units
  • Nominate data stewards in decentral business units that are responsible to reuse central mechanisms and, based on entity ownership, to conceive decentral measures for data governance
  • Reorganize business processes based on the above mechanisms as well as to integrate data governance measures
  • Restructure existing business units to support the reorganized processes
  • Train managers and staff how to support the "new" culture.

The above is only a primer to answer your initial question within the given limitations of this medium. Therefore, please feel free to follow up or contact me directly.

I'd like to emphasize here, though, the importance of the CEO's commitment to make sure that the investment into an Enterprise Information Map pays off and will not only remain a sandbox game.

Sunday, May 26, 2013

How to assign Data Stewards to logical pieces of an org's data | LinkedIn Group: DAMA International

Follow the LinkedIn discussion

My comment

As a first step, an organization needs a high-level logical data model to represent the target enterprise data architecture. Using that model, you can assign each subject area / entity to an organizational target unit that is typically responsible to create/update that entity as their respective owner. (I use the term "target" because the current enterprise data architecture - if even documented - may be siloed and also that the current organizational structure may not be optimized for future purpose.) 

Each owning organizational unit should be represented by one or several Data Stewards. 

Applying the above principle, the subject areas / domains of entities that are assigned to a certain organizational unit can be easily drawn, as the vast majority of entities has (more precisely: in the future should have) only one natural owner which typically is not only the creator of the data but usually also its main consumer. 

However, particular attention is to be paid to the Master Data domains, especially Party. The objects of Party occur in many different roles (customer, supplier, employee etc.) and therefore have either none or many potential "owners" (Sales, Customer Service, Purchase, Human Resources etc.). 

I recommend to create a separate central unit that takes ownership e.g. for all matters related to Party and represents the interest of the organization as a whole and not only of one department (the latter being one of the reasons for a siloed structure in the first place). This central unit has "the license" to define the entities/attributes related to Party, the business rules, the data governance measures etc. Other organizational units ("licensees") embed this "one and only" way of creating/updating objects of Party into their processes and supporting applications. Certainly, the Data Steward(s) representing the licensor need to consult the data stewards representing the licensees to make sure that all the requirements of the latter units are taken into consideration. 

This been said, there is no reason to "boil the ocean", i.e. no need to have a complete coverage of the whole organization, before any fruitful work can be started. 

I agree with a previous comment to focus in priority on areas with problems, i.e. where engaging in Data Stewardship can be justified by the ROI and/or where the COI (cost of inaction) indicates ongoing loss of money or the risk of fines (for industries that need to comply with requirements of regulatory authorities). Data Stewards for prioritized areas can start their work as a project task force and may later evolve into a formal, permanent role.