0

Logitech MDM Case Study: Live Questions, Answers and Attendee Poll Results (Part II of II)

Last week, I posted this blog:  Logitech MDM Case Study: Seven Lessons for Mastering Product and Customer Data (Part I of II) which shares highlights from recent webinar. Logitech’s Severin Stoll, Senior Business Engagement Manager of Global IT Solutions spoke with David Decloux, MDM technical lead in EMEA about Logitech’s Global MDM implementation, in which they are mastering product, customer and consumer data.

Logitech’s Severin Stoll and Informatica's David Decloux answer questions from webinar attendees about building an MDM business case, implementation time, data governance, and real-time MDM.

In this blog, I’ll share some of the highlights of the Q&A I led and results from two polls.

  • Jakki: Are you planning on implementing real-time MDM in the future?
  • Severin:When we started, we wanted to have MDM as near real-time as possible. But you shouldn’t start reporting out of your MDM a lot of data maintenance happens in this system. So what we have done, in terms of architecture, is created so-called published master data. Every hour we take a copy of our existing MDM system, meaning all of the actions which are completed, and we publish the master data. From there, we stream the master data across all of the different systems. I think the question you really need to ask yourself before you decide about real-time is, “What’s better: correct data or real-time data?” We are in a fast-moving industry, but does it change anything if the sales of a specific keyboard or mouse are correctly reported right now or in an hour? Can your organization actually consume the data and act on this data as fast as you can deliver it?
  • Jakki: Can you explain a little more about the business case for your MDM program?
  • Severin: For us, the business case for MDM, the way we sold it internally, was the need for much more reliable data. We wanted to understand much more about our customers.  We wanted a 360-degree customer view. If we have great performance in a particular store, we want to understand what they do differently. And, we’re starting to see results. In addition, we have more company-wide integration, more consumers of MDM data.
  •  Jakki:  How many people in the business departments are involved in managing the MDM process?
  • Severin: We follow a decentralized data governance model. We have data stewards appointed by department. The product managers of various product categories such as mice or keyboards are also responsible for the master data about those products. Customer data is more challenging because knowledge about customer attributes is spread across groups such as marketing, sales finance. So you need a customer data team to maintain all of the attributes. If your MDM program is successful, you will have groups voluntarily choose to use your central repository of customer data. They will want to play a role to maintain trusted customer data. They will feel responsible for it. They believe it’s critical for the organization, for the enterprise. So to a large extent, it’s all about trust.
  • David: I’d like to add to that. We find that managing customer data or product data is not always a full time job. It may be just an additional responsibility for some of the key people who are responsible for particular applications and business processes that are already managing their own product data or customer data. They understand the benefits gained by sharing common definitions, sharing data across systems. The team that manages customers data or product data across the enterprise, often gets great exposure in the company. 
  • Jakki: Can you talk about your decision to use a decentralized versus a centralized model for data governance?
  • Severin: When we started out we thought we should operate with a centralized model for data governance. However, at the time, the financial crisis didn’t allow us to create a huge centralized organization. So we started using a decentralized model and engaging with people in key functions. What’s good about the decentralized model is the people feel responsible for the data. They feel attached to it because that’s what makes their business work. So I think a decentralized model has this advantage. Obviously, one of the key challenges of the decentralized model is you need to make sure the people in those functions have a certain amount of time reserved to ensure the MDM data is always up-to-date and clean.
  • David: They key word here is “enterprise”. The question is not, “What’s the value of product data or customer data for a particular line of business or group?” The question is, “What is the value of this master data for the enterprise?” You need a team of people who support an enterprise strategy, who accept moving the ownership of master data above the applications or lines of business to the enterprise. As long as they are thinking about master data at the enterprise level, it’s doesn’t really matter whether those people are from a particular line of business in a decentralized model or part of an independent centralized team.
  • Jakki:  How long did it take to launch your MDM program?
  • Severin: There are two sides to an MDM implementation: one side is the technical or architectural implementation and the other one is clearly establishing your data governance processes. It took us nine months to implement MDM technically. We started with product data because we are a manufacturing company. We know our products best. It’s internal data so we faced fewer challenges. We gained a lot of experience with that implementation. Mastering customer data also took nine months. We ran that in parallel. The data governance took another six months before the business understood that the MDM technology is great, the master data comes in, I need to start maintaining it.
  • Jakki: Is it a good idea to phase an MDM implementation by domain?
  • David: I don’t think it’s about the domain. The way you phase the MDM program needs to be tied to the business challenge that you need to solve. You need to be able to quickly show value from your MDM program and share this value with other parts of the business. So, the business requirements should drive what you do first. You may start with one domain in phase one. Or you may start with a particular geography or set of source systems or a small set of rules addressing most of the quality problem, and then expanding to address all of the quality problems. I have two recommendations for those who are evaluating MDM solutions. First, ensure the MDM you choose is flexible enough to create the data model you need based on your business requirements, whether it’s for one domain, two, three or more. Second, make sure you phase your implementation so you can quickly show results. Fast and flexible MDM are the keys to success.
  • Jakki: Severin and David, thanks for sharing your insights and perspectives. I hope this information helps our attendees as they plan to better manage their own master data.

Poll results:

  • Poll #1: Are you planning one data domain or many and does it include customer?
    • 26% of attendees will master more than one data domain, including customer data
    • 5% of attendees will master one domain, customer
    • 3% of attendees will master more than one domain, customer not included
  • Poll #2: Do you already have an enterprise-wide data governance strategy in place?
    • 19% of attendees have no data governance strategy
    • 13% of attendees are in the planning stages of their governance strategy
    • 11% have a decentralized strategy or it’s limited to one or two groups
    • 7% have an enterprise wide data governance strategy

Want more?

FacebookTwitterLinkedInEmailPrintShare
This entry was posted in Customers, Data Governance, Manufacturing, Master Data Management, Retail and tagged , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>