Skip to Content

IT application is undergoing the new evolution phase of adopting Service Oriented Architecture (SoA) on the premise of business process consolidation, making best use of web / shared services. A pre-requisite to successful SoA is consolidation of Master Data Management processes.

When we say ‘treat your master data as a corporate asset‘, we got to build concrete data management process, requiring lot of interaction and participation from all business sectors of the organization. The biggest challenge here is you won’t find a single owner of the data object across organization, as existing data management is usually de-centralized and has been build as a side process to support core business transaction cycle.

Additionally the organic and inorganic growth of the organizations always makes it difficult to sustain a master data process, using existing ERP tools and technology.

Unlike ERP implementation, where consultants / implementation partners only own the responsibility of defining the business process (data ownership is always with the business), MDM project require MDM architect to get closer to client master data records & their attribute values; analyze it and look for the best possible option of data handling process which suits a particular organization business. Thus the MDM consultant needs to work closely with the data records, in addition to carrying out process consulting.

When I have to implement business process for logistics or finance cycle, I rely on best business practices that have worked in the past (globally) and recommend most suitable one. In case of MDM, apart from basic norms of defining a governance process, one need to design a unique process, that suits specific organization.

Care need to be taken that, the new master data process has the vision & flexibility to accommodate likely future changes in the business (adoptability to absorb new business and induction of new business validations).

While in ERP project life cycle, we make a distinction between implementation consultants as functional (business analyst) and technical (coding and custom development), MDM consultant is a techno-functional role, requiring functional domain expertise; technical understanding of data modeling; capability to use of interface components for inbound / outbound schema definition, for each specific receiving system.

Clear demarcation between issues that pertain to master data and those that are transactional data issues is required to focus on solutions that can be achieved using MDM tool, A special thought need to be given to issues where transactional data is corrupted because of master data.

While most of the phases of standard ERP implementation methodologies are analogous to MDM execution, separate methodology need to be devised for MDM, giving emphasis on identification of technical objects; scenario building; repository needs; taxonomy & workflow analysis; security requirements; user management; design of integration layer; data analysis & migration schemas with respect to identified inbound / outbound systems.

Lastly, I would like to emphasis on the fact that mere consolidation of data records into MDM doesn’t help achieve the MDM solution. It requires a deep understanding of overall use of each master object, to arrive at the decision of what data attributes need to be defined at each level, what interface strategy is to be adopted for each master data client and extend to which harmonize the data in these receiving systems.

Thus, MDM is more organization specific initiative, while ERP implementation follows pre-defined global / industry specific process standards.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply