Michele Goetz serves Enterprise Architecture Professionals. See the full Analyst bio.
Visit Forrester.com to learn how we make Enterprise Architecture Professionals successful every day.
Follow Michele on Twitter.
Michele Goetz serves Enterprise Architecture Professionals. See the full Analyst bio.
Visit Forrester.com to learn how we make Enterprise Architecture Professionals successful every day.
Follow Michele on Twitter.
Posted by Michele Goetz on February 8, 2013
I just came back from a Product Information Management (PIM) event this week had had a lot of discussions about how to evaluate vendors and their solutions. I also get a lot of inquiries on vendor selection and while a lot of the questions center around the functionality itself, how to evaluate is also a key point of discussion. What peaked my interest on this subject is that IT and the Business have very different objectives in selecting a solution for MDM, PIM, and data quality. In fact, it can often get contentious when IT and the Business don't agree on the best solution.
General steps to purchase a solution seem pretty consistent: create a short list based on the Forrester Wave and research, conduct an RFI, narrow down to 2-3 vendors for an RFP, make a decision. But, the devil seems to be in the details.
We all talk about understanding strategy first then select the technology. But, vendor selection all too often seems to be the first step and preparation for the evaluation lags behind. When a solution costs approximately $1M and goes up significantly from there with development and implemenation services, it only makes sense that establishing clarity in a to be state is critical. However, evaluations tend to focus on the features and functionality that is already evaluated and reported on in research reports. What seems to make sense is to evaluate a solution in context of your expectations from an IT and business perspective. That appears to be the great divide - what you need and how you evaluate.
So, help me with research that goes deeper into vendor and solution selection for MDM, PIM, and Data quality. Tell me:
Share!
Attend Forrester’s Forum for Enterprise Architecture Professionals EMEA, June 10-11, London UK
Comments
Join the discussion
I've included a link to our discussion board:
http://community.forrester.com/thread/9531
They are not the same
What you need to take into consideration is the following:
- How well is the dictionary made for the market you are intended too? In my experience, especially if the project will involve more than one country, or market, is the ability to provide localization based on geographics, languages, do they support multiple languages, even alphabets? etc. The same rules for de-duplication and record matching may not be the same in one geography versus the other, even within the same language spoken
- How advanced rules are in order to merge records ? Depending on the business rules these tools provide, you can detect the duplicate, merge it, or list down candidates so they are merged in a further process. How advance those capabilities are and comprenhensive to business users is very important to ensure success
- How much experience these vendors have within your market or geography? Can they prove previous sucess stories within your industry, market or geography? This is very important so you can see really how good their know-how is.
- How flexible are these tools? Are they tight to any specific ETL, or DB system? This is important specially if you have technology in place that you just need to complement. I hope this helps,
Recommendations for MDM evaluation
Please see my comment on the discussion board http://community.forrester.com/thread/9531
First of all, thanks for
First of all, thanks for mentioning PIM separate from MDM.
In my experience, three thinks are important during the vendor selection:
- a clear and aligned overview of what information you need to manage to fulfill the needs of the various touch points
- a clear process description and how it works together with the other processes around product introduction
- a scripted demo which forces each vendor to demo key parts within the process with real data.
Goals and Requirements
When goals between the business and IT are in conflict, it's likely they are wandering into each others areas of responsibility.
IT should be concerned with operations, availability, concurrency, program-ability/programatic-access, scale-ability (requirements to be defined by the business in terms of number of users/systems and potential growth over a 5 year window). IT should be concerned with the TCO: the costs associated with standing up and maintaining the platform.
The business should be concerned with the business-level requirements expected of the platform, the scenarios the business needs the platform to support or enable.
The business also needs to provide guidance on the cost savings or revenue opportunities expected by the platform.
From here, the revenue opportunities/costs savings minus the TCO allows for an ROI calculation to be provided.
Post new comment