Q&A: MDM Proving Its Value at Health Services Company

MDM may not be easy but it's worth the effort.

• By Linda L. Briggs
• 10/06/2010

Master data management is the concept of managing and maintaining a single, complete view of the business’s data. As Rick Biederstadt explains in this interview, it’s not always an easy concept to implement, but it has more than paid off at Health Care Service Corp., where Biederstadt has worked for several years in implementing MDM.

Biederstadt, who is currently divisional VP, enterprise information strategy and management at HCSC, previously discussed his efforts with MDM at HCSC as a guest speaker at a TDWI Webinar on master data management in July, Master Data, Quality and Governance: How to Achieve it and Why You Should Care, with Philip Russom and Jill Dyché.

BI This Week: Can you give us a little background on Health Care Service Corp. so we'll have a sense of the size of your master data management project?

Rick Biederstadt: Health Care Service Corp. is a non-investor-owned mutual insurance company that operates through Blue Cross/Blue Shield divisions in four states: Illinois, Texas, New Mexico, and Oklahoma. We also have a number of subsidiaries in the health and life insurance space. For our discussion about MDM, we are talking about HCSC as the parent company that owns the brand Blue Cross/Blue Shield in the states where we operate. We have about $40 billion in revenue, about 17,000 total employees, and a fairly significant market share in all the states in which we operate.

When we talk about your MDM journey, are we talking about the entire $40 billion company?

We’re predominantly talking about the Blue Cross/Blue Shield side right now, although we’ve worked with several of our subsidiaries to embrace master data management as well.

How long has your MDM project has been underway?

We really started the project after attending a TDWI MDM Insights conference in March 2008. Prior to that, in August 2005, however, we had already realized that we needed to define our information asset strategy at HCSC. Once we had the strategy in place, we then needed some foundational capability, including the ability to manage our master data. At the TDWI conference, we took things further, looking at where MDM is going and how it will apply to us.

An interesting aspect of your recent presentation on MDM is your list of lessons learned. I wanted to discuss some of these lessons with you because they seem to offer some excellent insights for others. The first item on your list is: “MDM is harder than it looks.” Does that directly tie back to your experience with MDM?

Yes it does. MDM is not easy, and unless you have the executive sponsorship and the business partnership that we had, it’s even harder.

You had the executive sponsorship that you needed at HCSC?

Absolutely. We started with two projects that were driven by two business sponsors who were highly engaged in the projects, and we tackled MDM along with the business problem we were addressing. We had a strategy, we had a business problem, and we had business partners. In fact, I think it’s important to note that we’ve gone even further -- we’ve created a data organization that reports at the senior VP level. That’s the same level as the CIO and the business sponsors who primarily run our company.

This next item on your list sounds critical: “Define your MDM vision, definition, criteria, and priorities.” Can you talk about the importance of that?

By that I simply mean that if you have vast data management, it should fit within your information management architecture. It’s not something that’s separate. That’s a key thing we discovered at HCSC over the two-year period during which we’ve been working on MDM.

When we look at our MDM vision and think about master data, we find that we’re coming back to what the vision is and where we’re trying to get. That’s the light at the end of the tunnel. …

I used to be part of IT, but now I’m part of a business unit within the data structure of our organization. There’s an IT component of our company, there’s a business component, and there’s a data element. I’m on the data side. Among the three of us, as we execute our master data, we’re constantly going back to the vision -- what is it, and where are we trying to go. That vision is critically important.

Another thing is the criteria for what is master data -- we’re constantly changing that. As you pick up a new subject area or information domain, we constantly have to go back and say, “What are our criteria? What are the priorities within that master data management suite of information? Which domain is more important?” The vision and definition of where you’re going help in determining your priorities.

On your lessons learned list, you also include, “Don’t assume MDM vendors have all the answers.” Do you mean that vendors often try to make your problem fit their solution?

Well, they definitely have their solutions, of course. As an example, we’re in the healthcare space. Most of the master data management vendors may be in the healthcare space as well, but on the provider side. At HCSC, we’re not the doctor’s office or the hospital – we’re not on the provider side, so when vendors offer an MDM solution, they often say, “Sure, we have healthcare experience and master data experience.” We have to realize that it’s said from a vendor perspective. We have to ask: how does that solution work in my world, with my terminology, with the issues that I have to deal with? A number of vendors may think they have the answers, but they just don’t apply in all cases.

That leads nicely into another item on your list, which is about choosing your partner carefully – really scrutinizing the vendor before you make a product choice.

Yes, that’s critically important as well. You have to understand that we are on a journey – which is another important point on my list. It’s more than just an “I’m-buying-a-product” agreement with the vendor; you’re going to be partners. It’s about mastering data – how will you, as my vendor partner, walk with me in making that happen?

There are many lessons learned within this topic to consider. For example, we created detailed use cases for evaluating each of the products from a business, technical, and data perspective. Each team created detailed decision criteria, usage patterns, priorities, scoring scales, and more. Additionally, we considered how the vendor manages our account and not simply the next sale, as well as product testing strategies, the process of delivering patches to the product and how each patch is tested, what you get “out of the box” with the product versus customization, and the associated ROI of those changes. We also looked at common terminology, data loading strategies and tools, data models, third-party tool integration, standards, executive sponsorship within the product, services organization capabilities, and many more issues.

The vendor cannot simply be on the sidelines once we purchase the product. Skin in the game goes both ways.

The next point on your list refers to how critical it is to have a data governance program. Is it that important?

It really is. AT HCSC, we have a governance team that’s made up of business people, IT people, and data people. Together, we formed a stewardship and a governance committee. Prior to having a governance strategy and team, we often ended up arguing with multiple business teams about definitions. We don’t have to do that anymore. We have a governance team that says, “Data quality is as important to the company as running the company. Important information is as critical as running the company.” Given that, the governance program gives us the ability to say, “We’re going to develop an enterprise solution focused on the enterprise; as a committee, we can work through issues of defining terms between subsidiaries.” Governance is the business driving enterprise information solutions. Information is an enterprise issue.

At HCSC, this portion is interesting because we own four types of Blue Cross/Blue Shield plans. Within the healthcare space, they all have regulatory items that are specific to those states, so it’s as if we were working with four different subsidiaries. Given that, how do you have a master data conversation with four different teams that act like four different companies, have four different agendas, and have four different regulatory issues -- in essence, four different information needs both operationally and analytically?

The governance program helps us to define data, keep an enterprise focus, and work through resolution of the answers to data so that we can code a solution and manage that master data as an enterprise asset.

At what point did you put the data governance team in place during your MDM journey?

Let’s go back to our strategy, which as I said, we started back in August 2005. At that point, we defined key foundation elements that had to be included. [Those included] master data, managing operational data as well as strategic data (important for our data warehousing efforts), an operational data store, and a data movement integration hub to manage operational data. We also had to have foundational things such as a governance program. We implemented and started working through that all of that in August 2005. When master data came up, it simply fit right in that structure.

During the process, did you find data quality issues that you didn’t realize you had?

We did. As you match up the grain of the data, you find that the source system sometimes simply doesn’t match. How does a business transaction in our membership system relate to a subsidiary's transaction membership system, for example? With items coded into those applications, [we consistently find] that we have to get down to the details of the historical data over time -- not just the data that you’re currently looking at -- to discover how those fields actually interact and how the products work.

As an example, as part of this process, we found that one of our products coded something [special] for birthdays prior to 1936. Unless you were dealing with someone born prior to 1936, you wouldn’t know you had a data quality problem until it showed up later on. Of course, we do have people with healthcare insurance born before 1936, but we wouldn’t have known about the problem if we were just looking at 2009 data, say. We really had to look at data over time, and we had to look at data quality issues in terms of grain. Everyone thinks the data they produce has no issues until you look at the data historically from an enterprise view. You wouldn’t know either had you not looked at the data from this master, historical, enterprise perspective.

To wrap things up, your list includes this lesson: “Design your data delivery ecosystem.” Can you elaborate on that point?

MDM is within your information management environment. As I’ve said before, it’s not separate. That means your business intelligence environment and your operational application environment have to be melded into one -- an enterprise information management architecture. Within that, you start hooking the different systems together at the application level. When we did that, we found that [things were different at a “grain” level] – that is, there are multiple levels of grain for a member business event in one system compared to another system, so you make sure you have to hook them together in order to get a common answer.

A business event in one membership system is different at a daily level, for example. … Within that, information architecture is key because if you’re melding together an operational world and a strategic analytical world for master data, how do they fit together? The business architecture helps answer that question. It helps define the complex subject of how the operational data store, master data management solution, data warehouse, and data marts all connect and work together at the operational level. That’s really the subject of another entire discussion.

At HCSC, we’re very cutting-edge, and we’re really stretching the bounds with technology issues and master data management.

Overall, master data management is not an “if” question, but more of a “when” conversation. At HCSC, we have found MDM to be a critical component within our information asset strategy and enterprise information architecture directions. The return on investment is there for managing master data within your enterprise. If your company considers information to be as important to the company as running the company, you will engage in MDM.