Q&A
Customer Focus is Key to Master Data Management Project
Canadian Tire Bank makes the business case for MDM project by touting data integration benefits.
First Canadian Tire Bank makes the business case for MDM project, then focuses on customer data integration to achieve success
- By Linda L. Briggs
- March 31, 2009
Canadian Tire Financial Services, a wholly-owned subsidiary of one of Canada's largest retailers, Canadian Tire Corp., undertook a project that focused on customer centricity to integrate data in their financial services division.
In this interview, we talk with Ed Unrau, credit risk manager at Canadian Tire Bank, about how he successfully presented a business case for the project -- working from the business side -- and how the project progressed as Canadian Tire focused on customer data integration in their phased MDM implementation.
TDWI: What does the term MDM mean at Canadian Tire?
Ed Unrau: Our parent company, Canadian Tire Corp., is Canada’s top retailer, and they are developing an MDM strategy around product and vendor information. At Canadian Tire Financial Services [where I am], I don’t hear the term MDM used much. I really only starting hearing “MDM’ after we were well into the project.
It’s interesting that you’re on the business side, not in IT.
Yes. I got involved because of challenges we were having -- challenges that we realized could be solved by customer data integration.
When did this project start, and how far along are you now?
It started about two years ago. We’re approaching nine months since the first implementation. We’d known [for a while] that having a more complete view of the customer was a good thing, but we couldn’t quite put the business case together. I think IT had proposed the project earlier and gotten turned down. I got involved when my boss said, “We need to do this, see what you can do to provide the business case.”
Can you talk about how you successfully created a business case for this project?
I talked to a lot of people at CTFS and vendors, but in the end the business case wasn’t huge. If we stayed just within the Credit Risk division, we could break even over three years. That wasn’t overwhelming compared to other [potential] business cases for other projects, to say the least.
It was also clear that if we could build this on an infrastructure that was scalable, that the rest of the company could eventually use, it would have much bigger benefits. That’s how we got approval with such a modest return on investment. It became clear that [the marketing department] could eventually use it, that we could get operational savings out of it, that [the compliance department] was interested in it, and so forth. No single area could justify a project like this on its own.
So spreading out the business case to show how other divisions could use the infrastructure eventually helped justify the ROI. Are you far enough along that you can predict where you’re going with the return on investment?
Yes, we will exceed the ROI of the business case. We can also see more opportunities -- opportunities that we never saw at the early stages. As more and more people see the data and begin to see the full picture, they get more and more ideas of what we can do. That’s what’s happening here anyway, and on all fronts -- operational, customer service, risk, compliance, and marketing.
What are some of the challenges that led you to implement the MDM initiative at Canadian Tire, even though that’s not what you called it, of course. You mentioned earlier that you knew you needed to do better customer integration. Was that the driver?
That was definitely the driver. We are expanding the number of financial services products we offer, and introducing more new services and products, [but we weren’t] taking advantage of the valuable information we had gathered on existing customers when offering new services. When customers [held] multiple products, we were treating them inconsistently. It wasn’t happening often, but it was a problem we wanted to contain before it grew, and being more customer-centric would help us grow faster.
Can you give me an example of how you might collect data to understand a customer, but then come up with a new product and not use that data?
For example, if someone applies for a new credit card but they already have two credit cards with us and one is delinquent, or they’ve already exceeded the maximum credit limit, … [then we need to know that before issuing another card].
Beyond that we have fairly sophisticated models that consider purchasing patterns and other factors when trying to predict the customers’ needs and our risks, as well as assessing their value. You need [that data] to be available when you make any decisions impacting the customer. For us, it can apply to customer service or marketing, but I work in credit risk so we took a risk0-management perspective.
You implemented the project in phases, with a heavy emphasis on ROI. How quickly (or slowly) did you see results?
As I said, our business case was quite modest -- basically to break even over three years -- but part of the objective was to achieve those benefits with an infrastructure that could be expanded to the rest of the organization.
We started seeing benefits immediately. For example, we started making some risk decisions differently because of additional information we had available. At this point, it appears quite certain that we could exceed the ROI, and we have had confirmed that our platform is scalable.
However, expanding the benefits creates more complex issues, some of them non-technical in nature, [such as] who owns the customer. One of the most difficult seems to be how we can continue to be organized at a product level while increasing the customer-level influence.
What were some of the biggest challenges you faced in using master data management and information integration?
The first challenge was developing the business case and technical approach. There were many divisions involved initially and many alternative solutions.
You mentioned scope management earlier. How much of a challenge was that and how did you address it?
Scope management was perhaps the second biggest challenge. Our objectives were focused and [the project was] under the control of a single business Associate VP, my boss, plus we had a good working relationship between business, IT and IBM, our vendor and system integrator. Fortunately our data quality was quite good -- good enough to get started without a major clean-up.
Scope was a challenge because once we had the project approved and we began trying to get more details on how to achieve the business case, everybody offered all kinds of ideas. … I was often the one [who] had to say, “No, out of scope.” We just wanted IT to deliver that initial business case, but do it with a system that could be scalable. [At times,] I began to sense the high potential for this to spin out of control.
Was it fairly easy to determine whether someone’s requirements or requests were in or out of scope?
Yes. They used to joke that I carried my sheet of calculations around with me, and I would refer to it and say, “That doesn’t contribute to the $3 million in benefit, so therefore it’ll have to wait. Either that or you need to tell me how we can achieve that without affecting the costs.”
Your case is especially interesting because you’re so clearly from the business side of the company, not IT. Any advice that you might offer to others in a similar situation?
I can’t imagine going too far wrong by starting small based on specific benefits or specific actions you want to be better, while still looking to the future. “Plan tactically while thinking strategically” certainly applies. I think that’s what we did. We were very tactical in our implementation but we also had a strategic, long-term outlook. It’s hard to imagine that being bad advice.
Ensuring you understand how you expect to achieve benefit combined with a good partnership or working relationship between your IT and the business can help manage scope. I think one of the biggest risks with projects like these is trying to boil the ocean.
Ensuring that you understand the benefits can also help you be aware of situations where you might invest in mastering data quality, but won’t see benefits because the ability to use the data is not there. That is, improving customer service won’t happen if the operational system to use the customer data isn’t there. Making better decisions won’t happen if the analytical environment and tools aren’t there. It sounds simple but I think it can be missed.