Data is not just information. It is the backbone of your organization. Properly managed data can maximize ROI and meet organizations for business objectives. Searching for a piece of information is not easy across many different heterogeneous systems. Organizations are realizing these difficulties and moving toward managing their master data such as customer, products, supplier and vendors to answer many questions quickly and make business decisions to meet the corporate business goals. To succeed in the master data management (MDM) journey, selecting the right MDM tools is a very important task and critical to its success.
Organizations need to have the right MDM tool that fulfills both their technical and business requirements to succeed. The MDM tool should support service-oriented architecture (SOA) and can able to bring data from various systems to a centralized MDM repository in near real time. As part of your MDM tool selection, you need to consider your organizations growth and strategic vision. When organizations select MDM tools, the following areas needs to be consider seriously:
- Integration - Able to integrate enterprise systems.
- Global data synchronization Data consistency between geographically fragmented systems.
- Interoperability - Capable of working with recent merger and acquisition data.
- Business objective - Meeting organization business objectives and goals.
- Single view of customer - Capable of merging fragmented customer information to centralized location.
- Workflow - Built-in functionality such as transformation and matching to build process flow.
- Ease of use - User-friendly front-end interface for nontechnical business users.
- Technology - Development time, tool maintenance cost, time to investigate errors.
People involvement: Both technical and business teams must participate in tool selection activities and decision-making processes. MDM is an enterprise-wide initiative, not a departmental decision. IT alone cannot make the tool selection decision; neither can the business team. Enterprise level involvement is very important to make selection decisions and pick the right tools. IT development teams, business users, enterprise generation architects, data owners, application architects, business teams, sponsors, project managers and data analysts need to participate in this process from the beginning. Many organizations hire consultants or consulting firms to recommend the MDM tool. When the consultant or the consulting firm makes decision on MDM tool selection, they have to review their decisions with all the above-mentioned teams to get feedback and incorporate them into the decision-making processes.
Whether to hire an external resource or utilize internal expertise to select MDM tool is not important. Organizations need to focus on defining selection process, business requirements and technical requirements. Selection criteria need to focus on functional, nonfunctional and Integration requirements. Following are the steps to select the right tool for a MDM project:
- Perform current capability assessments of, technology inventory, including hardware and software currently used across the enterprise such as enterprise service bus (ESB) and SOA software. It is part of the process to find out whether the MDM tool is able to communicate with other enterprise systems. If any reporting and monitoring system needs to subscribe to the MDM services, this tool needs to support integration capability to these systems.
- Merger and acquisition plans and system integration requirements.
- Complete current assessment findings and MDM requirement review.
- Develop fit/gap analysis report between the current state and MDM requirements.
- Research internal and external resources to get a better understanding about the tool.
- Develop a selection criteria matrix and scorecard template based on requirements. Both "must have" and "nice to have" criteria should be clearly defined, and the vendor must meet all the must-have requirements.
- Choose the top five vendors that support both functional and nonfunctional requirements.
- Send out requests for proposal (RFP) with high-level questionnaires that meet your business and MDM requirements.
- Review vendors responses with everyone in the team and make sure they fit into your requirements. Also, talk to each vendor in detail about their responses to your questionnaires. Make sure vendor understood your question clearly and that you understand their.
- The previous step may eliminate one or two vendors that are not meeting the high-level requirements more than sixty percent.
- Request demo sessions from vendors. Most of the time it is difficult to make the vendor demonstrate their tool to fulfill your requirements. The evaluation team needs to communicate to the vendor exactly what functionalities need to be demonstrated, whether the tool needs to connect to your database for test data, etc. If you fail to define your requirements to the vendor, most of them come up with their own standard demo structure (e.g., reading data from a small flat file). Due to time and resource constraints, most of the vendors do a standard demo at many client sites unless you communicate tool requirements clearly to them ahead of time. When you are interested in performance, scalability and system response time, you have to provide your own development systems to connect with a large volume of records.
- Develop sets of questions based on the requirements and selection criteria and review them with the team ahead of time. All the key participants, architects, business users, ITS team members, managers and decision-makers must attend the demo session. It is very important that all key contributors are present in the demo session and prepared to ask questions that affect the selection ranking. For each questions, vendor response needs to be recorded and ranked. The best practice is to distribute list of questions to the members and socialize with team prior to the demo session. Try to ask the same set of questions of each vendor and rank them using those questions. It is convenient for both vendor and client to ask for a proof of concept (POC) after the demo session. Many venders will agree to this. Again, make sure that the POC is tailored to meet your requirements, which should already be communicated to the vendor.
- Finalize vendor responses and review them with your team. Document the responses with your team feedback and confirm with each vendor to make sure that you and the vendors are in the same level of understanding. If not, set up another phone call or remote demo session on the topics that needs clarification, and document vendor responses.
- Processes described so far will narrow it down to three vendors that met your must have requirements. Set up a phone call with each vendor, deeply discuss all selection criteria and rank them accordingly. This session should focus on finalizing and selecting two vendors based on who meets your must-have requirements at least 80 to 90 percent.
- Select two vendors and request an evaluation or trial copy of the software then work with your development team to practice with the tools. Let your technical team test the technical capability; let your architect evaluate integration capabilities and limitations; let your business user evaluate ease of use; and review the results. It may take a week to accomplish this task but it is worth it for your investment. During the tool evaluation, every must-have requirement should be tested, documented and reviewed with all team members and key personnel.
- Document the pros ands cons of each tool and summarize your ranking decision. At this stage of the selection process, you must have completed the ranking metrics, strengths and weaknesses of each tool. Based on your organizational MDM requirements, strategic vision, implementation and architectural limitations, you should list at a minimum five to seven strengths and weaknesses from each tool. These strengths and weaknesses should be observed by every participant and agreed upon. Mostly, these strengths should be the must-have requirements and capabilities. The final presentation should be reviewed by internal team members, sponsors and managers to get their feedback and select the number one vendor based on the ranking score. Figure 1 summarizes the tool selection process.
If a tool has not been selected for any reason after the vendor demo, then a POC will be necessary. A proof of concept compares two tools head to head in a scale-downed environment mirroring the future project environment. Often vendors will spend one or two days on site building the POC scenarios, and then present it the following day. For the POC, the project team needs to create a small-scale environment similar to the future production environment including hardware, software and technical architecture. Two or three must-have business scenarios selected for the POC. At least one scenario should include a requirement unique to the project that truly tests the capabilities of each tool. Other scenarios should include analysis that would be performed most frequently. POC tool evaluation matrices will be needed to evaluate the tools during the POC. Most vendors include the criteria they demonstrated during the demo session. Also, any detailed criteria pertaining to the business scenarios selected for the POC should be included.
Selecting an MDM tool is not a simple task. MDM implementation is a journey. You have to have the right set of tools to make your MDM journey successful. The key resource, whether he or she is an individual consultant or a consulting firm, must have extensive MDM implementation knowledge, including both technical and business areas. Many organizations let the nontechnical person make the tool-selection decision. You are selecting a software tool that supports your business requirements. Both technical and business teams should play key roles (e.g., architecture, integration capabilities, SOA capabilities, data lineage, global data synchronization, single version of the truth, data standardization). When you talk to the vendor, clearly mention what SOA capabilities you are looking for and what business requirements that tool needs to satisfy. The technical resources have to make sure that what vendors stated is demonstrated and every one is satisfied with the results and performance. The business team needs to confirm and approve that the tools demo and POC meets the business requirements. Here are the areas that you need to concentrate on when you talk to vendors.
- Any additional adapters required to connect to your system of records.
- Number of concurrent database connections this tool must establish to connect to the databases.
- Ability to support different types of input and output file formats that the tool can read and produce output to further processing.
- Real-time data acquisition capabilities and SOA support.
- Designed to store master data in a centralized hub and support to publisher and subscriber model.
- Ease of integration with presentation layers, data sources and other enterprise systems.
- Capable of providing rapid query, analysis and reporting functionalities required for successful business initiatives.
- Providing 360-degree view of the enterprise.
- Support for customer identification, matching, correlation, hierarchies and relationships.
- Supporting corporate MDM value propositions in areas such as data redundancy cost, revenue, such as customer retention, and churn management, such as decision-quality improvement.
- Support to improve time-to-market capability.
- Ability to adopt corporate culture and governance processes.
- Data distribution capabilities, such as near-real time data extraction and delivery.
Selecting MDM tools requires MDM implementation experience as well as technology integration experience. It is also important to understand the current state of the systems in your organization. It is not only the data architecture or IT team effort. It is a combination of technology, business and strategy team involvement. Your master data is the backbone of your business. MDM initiatives and implementations are typically two-to-three-year-long projects and depends upon the organization size and requirements. For MDM to function at its best, teams and departments must be taught how data is to be formatted, stored and accessed using your MDM tool. This must also be done at the tool evolution period.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access