Justifying Master Data Management - A Call for Business Processes and Hard ROI
Cleveland, Ohio – November 2007, By Jeffrey Bailey, Director
IT matters. IT doesn't matter. Who's right? Actually IT does matter as long as c-level executives, business leaders, and IT work together in a disciplined way to execute an IT playbook that is aligned to the business plan. Part of that discipline includes articulating solution benefits in concrete and measurable terms and having the guts to follow through with the plan.
If you know anything about Master Data Management (MDM), you know it is a complex endeavour that provides significant benefits if done right. Wikipedia offers a thorough classical description as well as links to related definitions of Customer Data Integration, Product Information Management, Data Governance, and Service Oriented Architecture. If you don't have access to the internet right now or for all you non-MDM gurus out here, MDM can be defined as the set of technologies, processes, and governance that; 1) enables information consolidation into a master repository from disparate systems and business lines, 2) includes the cleansing and enrichment of data, 3) ensures integration and distribution of data as a single point of truth for a consistent enterprise view, and 4) leverages master data to service consuming applications, enterprise business processes, and decision support systems [Source: Oracle].
For all you C-level business folks reading this, you get it don't you? Are you ready to invest? I bet not! That's because the description above depicts little to no tangible business benefit. But then, isn't that something we should expect? Perhaps IT matters just a little in this case.
Pundits dish out facts about the rate of information change (200+ business names change every hour, over 2,700 people move every hour, 20% product duplication rate in one year) and the consequential opportunity costs to businesses (data quality cost firms billions of dollars a year, data management and data synchronization reduce IT costs) . "gosh we have to do something". IT must matter.
The problem is most companies have difficulty pinning these points down into actionable and justifiable programs. Likewise, our solutions as enterprise architects, consultants, and product managers have not included hard benefits to the business side of the house, thus many CIOs and business sponsors are hesitant to invest because the final outcome is not clear. To date, benefits have been of a general nature, stuff that intuitively makes sense, and very few early adopters have gone back to measure their results. For some large complex companies this is good enough. For example, a large manufacturer and distributor of medical equipment in the mid-west sites benefits such as: integrated sales, enterprise credit approval, and procurement spend analysis. Another, a large telecommunications company, identified the following benefits: improved accuracy & efficiency of AR, bad debt reduction, decreased credit risk, reduced ticket time-to-resolve, improved compensation accuracy, and improved KTC (know the customer). You get the picture. IT matters just enough.
I too succumbed to this way of thinking until I recently visited a CIO of a large truck and engine manufacturer. Having some firsthand information about their business goals and IT challenges I immediately began evangelizing MDM. after about 2 minutes his eyes began to gloss over and I thought to myself, "Jeff, you missed the boat on this one". How embarrassing. I realized then that those of us working in the MDM space need to take a fresh approach by turning that technical solution into a business process focused solution that includes hard benefits. Otherwise MDM won't matter. Allow me to present two approaches to solve this problem.
An MDM program may 1) address a specific problem or set of problems or 2) may be implemented as a foundation and technical enabler to support a broader corporate initiative. In either case, a company that benefits from an MDM program is typically going to be fairly large (over $1 billion) with multiple lines of business, multiple market channels, and various silos of data and disparate business applications. These things are barriers to achieving standardized and integrated core enterprise processes. In the two scenarios discussed below, it is assumed that the enterprise has the capabilities, willingness, and discipline to execute a MDM program.
A Specific Program to Address a Specific Problem
Much of our responsibility as senior IT advisors includes the understanding of a business, its processes, its core competencies, and then applying technology to solve a problem. MDM is actually a set of technologies assembled in such a way that a new solution set is available to us. As we apply MDM technologies, methods, and best practices we need to avoid solution statements that fall short of measurable benefits (like some of the benefits mentioned above). We need to go further. For example:
- If by mastering customers we say that we will decrease marketing expenses, then we need to say by how much. The VP of Marketing needs to sign up for these savings. The CFO needs to put the savings into next year's budget.
- If by mastering products we say that we will improve channel accuracy, then we need to state in what terms. How will we sell more and by how much? How will we reduce cost and by how much? And how will processes change?
I've spoken with many clients about MDM improvement programs that include reduced credit risk, improved hierarchy/account management, and so on, but we have lost site of the process behind these goals. As practitioners we need to clearly map out how business processes will change once MDM is applied. When business processes change and new ones are created often organizations are caught flatfooted. Utilizing process blueprint software for example could have helped in the following example:
- If by mastering customers and outstanding credit we will decrease credit risk, then we need to not only state by how much and calculate a hard ROI, but we have to be smart enough to realize that individual lines of business will resist because they will be constrained from making a loan once the enterprise view of credit risk is exposed. New processes must be put in place to prevent this behavior. New reward systems should also be considered.
Foundation or Technical Enabler to Support a Broader Corporate Initiative
This type of program is normally a bit more challenging to execute because of its complexity and scope. With all the merger and acquisition activity taking place however, many enterprises have little choice but to move down this path.
Before any large company (fortune 2000 for example) is successful at this they must actually sit down and determine what their operating model is and what set of technologies are utilized to support their operating model. Ross, Weill, and Robertson talk about Enterprise Architecture Strategy in their book entitled the same. The book reinforces some of my thinking here. The authors discuss enterprise architecture (I like to say enterprise "business" architecture) and define it as, the "organizing logic for core business processes & IT infrastructure reflecting the standardization & integration of a company's operating model".1 They go on to discuss that enterprise architecture is a business issue and that good companies create a stable core by digitizing their core processes. Furthermore they emphasize two primary concepts that fit into what we are discussing around MDM: 1) the importance of business process integration and 2) business process standardization. Our authors state that this core creates a foundation for higher agility (sounds like SOA, MDM, eAI, BPM) higher profits, faster times to market, lower IT costs, and so on. While I won't disagree, I would argue that we need to go further and define the process changes and calculate the hard benefits as many firms cannot afford to create a digitized core without aligning it to a business case.
A few jobs back I joined a $5 billion company that grew through acquisition (two per month). We woke up one day with 67 GLs, 40 odd business systems, and realized that we had to start acting like a real company. Teamed with our PMO, CFO and COO, we laid out our operating model and applied the enterprise architecture that would best fit that model and allow us to accomplish our goals. We defined a course of application standardization along with multiple "federal" programs that corporate could perform collectively better than the individual business units thereby lowering our overall cost to manage. These programs were comprised of Source to Pay (purchase order reduction, logistics improvement, intercompany streamlining, expense management) and Record to Report (budget & planning, advanced reporting). Each of these programs had specific benefits and/or cost reductions defined and each business unit president and CFO had to sign off on the plan and reflect these outcomes in their budget. Our estimated benefits netted a savings of $10 - $15 million and were defined in specific dollar amounts by business unit and program.
Why am I telling you this? Well let's get back to my original point about process and hard ROI. While it was hard, we nailed these things down. Sure it was painful but we did it the right way.
You noticed that during the description of this program I did not mention the financial hub we put in place to facilitate all of the automated financial transactions, or the integration backbone to transport data, or the workflow automation. I could go on. There was no technology sell. it was all about business process and hard ROI. The technology only enabled us to be successful of which MDM was just one of many technologies in the war chest. So IT did matter, only not as much as the business folks that executed the plan. Ok, so we made the books Who Moved My Cheese and Good to Great required reading - everyone got on the bus!
Wrap up
Someone a while back mentioned to me that they were doing MDM 20 years ago. While I agreed with this person in principal (sure they had a customer information file at his bank) I'll bet that today's technologies (e.g., data cleansing, data enhancement, process orchestration, and integration), our advancement in processes and methods, and our understanding of data governance far exceeds what we were doing 20 years ago. Likewise, I would hope all of us practitioners don't stand idle when it comes to stepping up our performance. It is up to us to ensure each MDM program is focused on specific process improvements and hard ROI.
References:
1Jeanne W. Ross, Peter Weill, David C. Robertson, Enterprise Architecture As Strategy (Harvard
Business School Press, 2006, pp. viii).
Jeffrey Bailey is a Director at Attevo.
About Attevo
Attevo is a global business and information technology consulting firm. We enable entities around the world to become more productive and sustainable by thinking strategically and facilitating the use of technology to optimize business process and implement enterprise solutions. Attevo clients include major commercial and government organizations around the world, local government municipalities, and emerging and mid-market companies. Attevo has offices in Cleveland, Ohio, London, England and Edinburgh, Scotland. For more information visit, www.attevo.com.
For further information please contact:
media@attevo.com
+1 216.928.2800 (USA)
+44 (0) 203 051 9322 (UK)
