You may already know that IBM MDM v10.1 goes out of standard support in April 2018– but here’s your wake-up call. As you plan and consider the timing, resources, and budget required for upgrading, ensure you are getting the maximum value from this upgrade by asking several questions. Some of these questions were covered in our recent webcast, but here’s some additional food for thought:

How is the customer-centric view of data being used today? And, most importantly, in the future?

Almost every industry prioritizes strategic initiatives advancing customer-centricity —  especially healthcare, banking, and telco. Buzzwords like population health, consumer self-service, consumer engagement, and consumer experience clearly indicate that MDM is critical to strategic and operational priorities. Competition, consumer engagement, consumer demands, and analytics are fueling this priority. Consider how well your MDM data already supports this imperative, while being agile in how MDM is constructed.

Which business and technical stakeholders should participate in the upgrade planning?

Make sure your business stakeholders actually have a stake in your MDM technology. Historically (and sadly), MDM was frequently seen as an information technology project. Today, your business stakeholders should be actively engaged in defining not only the data that is used by MDM, but also the work processes surrounding MDM. If your business users are not engaged, an upgrade is a great opportunity to bring them into the fold. Without this engagement MDM risks being viewed as an IT project that may not be useful in a tight economy with budget constraints.

How can you use MDM technology more efficiently?

An upgrade presents a good opportunity for conversations about better managing the workflow of the data used by MDM – and it’s a great way to engage your business stakeholders. IBM MDM v 11 includes business process management (BPM) software to create automated workflows that can increase efficiency, decrease manual interventions, and create an audit trail. This powerful addition to IBM MDM (with no license fee required) enhances the productivity and communication amongst stakeholders when tackling merging or linking decisions, training, and coordination of data integrity.

How does MDM relate to your Data Governance program?

If you have a formal Data Governance program today, or are considering one, make sure MDM is included. Since the genesis of MDM is to master data (through merging or linking) that is used by many applications, systems, processes, and analytics, it just makes sense that MDM is a key component of a Data Governance program.

IMT offers several optimization services to help you maximize the value from your MDM deployment or upgrade. These include

  • Data Quality Review, focused on the MDM data including accuracy, validity, and distribution of source-specific and linked data.
  • MDM Health Check, primarily geared to the hardware and software environment supporting IBM MDM.
  • Data Governance Strategy Planning, focused on how the MDM data supports a strategic and operational Governance Program
  • Active Integration, which integrates the probabilistic algorithm into search, thus higher data quality is captured at its origination

We outlined these considerations and others in a recent webcast that can be found on demand here. Call IMT or email us at info@imt.ca to discuss these services and your future upgrade, as April 2018 is less than 18 months away!

 

 

 

 

 

Oct. 24-27 – Mandalay Bay, Las Vegas, NV: IMT will be back in Las Vegas for IBM World of Watson 2016, the premier event for those who lead in the Insight Economy. Unleash your company’s cognitive potential at IBM World of Watson 2016, where we’ll equip you with the capacity to extract knowledge from data, enhance personal expertise, and outthink the needs of the market at amazing speeds. Become a cognitive business, and see how data, analytics, and Watson can change your world. If you are interested in meeting with IMT during WOW16 please contact Brian Eckhardt at brian@imt.ca.

To register for IBM World of Watson 2016, go to:  www.ibm.com/software/events/wow/

If you’ve ever asked questions about MDM in the past, you might have gotten answers like these: “It’s always been done that way.”  “It is what it is.”  “That’s how they showed me to do it when I went to Boot Camp.”  While the “tried and tested” best practices of MDM have been in place for over 15 years now, there are some evolving customer demands that have us thinking about the normal approaches to configuration and questioning some of the default behavior patterns.

In this post we will discuss three questions that may cause you to rethink how you are doing MDM as well.

  1. What should happen to the non-surviving data when a merge occurs?
  2. Should having anonymous values trigger a score that reflects that data is different?
  3. Do all tasks need to be resolved from Inspector?

What should happen to the non-surviving data when a merge occurs?

In the default behavior of IBM InfoSphere MDM’s Virtual Hub (formerly known as Initiate), when two records are merged one is noted as a Survivor and the other becomes Obsolete.  The Obsolete record becomes completely deactivated – you cannot search for it, it will not be compared, and the record will reject all incoming updates.

Sounds fine, right?  But think about the data that the Obsolete record held before the Merge. In the default behavior, only the data that belonged to the Survivor record is searchable and usable going forward.  We recently complete a project for a Canadian Province where they questioned this approach.  Their point – a very valid one – was this: Shouldn’t the values from the Obsolete record be added to the Survivor’s historical information so that you can search on that data to retrieve the Survivor?

Wow, what a simple question?  This question led to a relatively straight-forward solution.  When two records are merged, the demographic data from the Obsolete record is copied into Survivor with an “Inactive” status.  Voilá!  Now, the data from the Obsolete record has a life beyond merger.  Those demographic values are now searchable and scorable in the context of MDM.

Should having anonymous values trigger a score that reflects that data is different?

Many of you are familiar with the IBM InfoSphere MDM concept of “Anonymous Values” where commonly used “fake” values such as BABY, CONFIDENTIAL, (999) 999-9999, or 01/01/1901 are treated as if they are NULL during analysis.  The theory is that by removing these values from the logical processing, we get a more accurate assessment of matching the records.  When it comes to attributes like Dates, Phones, and Identifiers the anonymous processing works as you would expect. However, analysis on Names does not always behave the way might intend when those anonymous values are stripped out.

While anonymous Name handling has always been promoted as a way to clarify differences, in reality the removal of the anonymous Names from MDM matching leads the Member Comparison process to register an Exact Match on when the other Names are factored in.

Record 1 Name Tokens:

Record 2 Name Tokens: Match Result: Overall Result:

BABYGIRL (Anonymous)

AMANDA No comparison EQUAL
R R

Exact

DAVIDSON DAVIDSON

Exact

 

Instead of listing those values as anonymous during standardization, you can set up scores in the weight tables, where those “Anonymous” names earn a score of Zero when comparing.  That way, when one record has the “Anonymous” name and the second record has the real name, you get a result that indicates that they are “Different” and ends up adjusting the score accordingly.  If both records have the “Anonymous” name, you will see that they are “Equal” but no score will be added.

Record 1 Name Tokens:

Record 2 Name Tokens: Match Result: Overall Result:
BABYGIRL (Anonymous) AMANDA Disagree

Partial

R

R Exact
DAVIDSON DAVIDSON

Exact

 

Remember, though… anonymous values also play a role in searching your Buckets.  So, you should still have these Anonymous names listed in a secondary list that is attached to your Name Buckets.  The end result will be worth the reconfiguration!

Do all tasks need to be resolved in Inspector?

This is a question we get asked a lot… and the answer is surprising to many.  No, you don’t have to work all of your tasks in Inspector.  But let us clarify… while the tasks don’t always have to be worked in the MDM tools, they should still be handled appropriately.

When we really look at the majority of tasks, they fall into two types: Potential Linkage and Potential Duplicate.  Potential Linkages (which are records from different sources with questionable scores) should be worked from the Inspector interface to establish the correct linking between records.  However, when it comes to Potential Duplicates (or records from the same source) resolving the records from Inspector is not always the best way to handle the process.

If you resolve Potential Duplicates, either with a merge or a clarification that records are different, the MDM engine creates a Rule.  Those rules act like a legal precedent, upholding the prior decision each time data changes call into question the validity of the match.  In essence, the MDM engine will have to ask for permission each time it reviews those records in the future.  Lots of rules can cause your probabilistic engine to behave more like a deterministic one, which slows down the engine and leads to unexpected results.

On a related note, if you merge two Potential Duplicates in Inspector, you still need to go back to the Source and do the same thing.  But if you merge from the Source, it automatically merges in MDM.  One step vs. Two… pretty simple.  Merging from the Source will not only perform the merge in MDM it will also remove the Task from the queue.  We have many clients who are using the Task list as a report, then going through and working the Merges (where the clinical data also resides) instead of in Inspector.

Keep questioning!

We want to leave you with a final thought.  Keep questioning… keep asking why something works a specific way, why a seeming “default” setting is there, and why the “out of the box” configuration is doing what it’s doing.  In most cases the answer is simply “because that’s how it’s always been done.

If you want to optimize your MDM, please reach out to IMT at info@imt.ca and we would be happy to help you find the best practices that work for you.

Oct. 25-29 – Mandalay Bay, Las Vegas, NV: IMT will be back in Las Vegas for IBM Insight2015, the premier event for those who lead in the Insight Economy. Please join us as we explore the newest innovations, industry breakthroughs and hottest trends in Master Data Management, Big Data, Analytics and our Entity Resolution Appliance for Law Enforcement. This year we will again be sponsoring a Healthcare Reception with IBM. If you are interested in attending our reception please contact Brian Eckhardt at brian@imt.ca.

To register for IBM Insight2015, go to: www.ibm.com/software/events/insight

To arrange a meeting with IMT’s executive leadership and sales teams at Insight2015, please email: events@imt.ca