|
Read and comment, that's what makes it work.
Master data hubs and rock-n-roll
MDM solutions have a lot in common with your music collection. Are we headed for disaster in both cases?
There's been considerable discussion and concern expressed lately about the emerging technologies in master data management (MDM), of which customer data integration (CDI) is a subset. In a nutshell, the concerns are that MDM is simply abstracting the problem of siloed data one level higher in the data architecture, and that as various "hub" architectures emerge, we could simply create new master data silos. Since hub products are rapidly evolving in customer data, product data, employee data, patient data, policy or contract data, and BOM data among others, it's easy to see how this might be a concern.
There is a difference, however, between the new hub technologies and the proliferation of data in applications distributed throughout the enterprise. The difference is standards.
I was thinking about this while discussing music collections with some of my friends in the CDI space, and I was struck by the similarities to digital music. I remember when my personal music collection consisted of tape, LPs, 45s, 8-tracks, cassettes (some metal, some CrO2, some Dolby™ encoded, some not) and CDs. It was a problem. At the risk of dating myself, the only 8-track player I had was in my car; the only turntable was in my house. The only portable device I had was a Walkman cassette player. Siloed data.
Now, however, I have two copies of my music. One is a losslessly encoded FLAC archival copy, and the other is an MP3. The MP3s play everywhere - on my home stereo, on my computer, in my car, or on my iPod. Right now, I rip everything at a resolution of 192kbps VBR, but that might change. I might opt to switch to MP-Pro, or MP5 or MP6 when they come along, or some other protocol like WMA or AAC or Ogg Vorbis. I don't care. Since I have the original archival copy, at any time I can simply write a little script to call some freeware program to re-rip all my songs in a new format, and I'm done.
To complete the analogy, MP3 is, right now, the standard which enables cross-platform compatibility for all my music. In hub technologies, it is web services. Web services allow data to be interactively called from the hub regardless of the hardware, operating system or application that is requesting the data. The hub maintains the archival copy. It is the "single source of truth" for one particular type of data. If, in the future, web services standards change, you may need to "write a little script" to change the way the data is accessed, but you can certainly do that with considerably less effort than changing a whole series of point-to-point data integrations and transformations. As long as you have the data in a hub, where information is gathered from the various source systems, reconciled and matched and DQ assured, and then synchronized back out to the target systems, your risk of creating new "silos" of data is minimal.
The one area where this might be an emerging concern is in reconciling the various data models. As hubs proliferate, some processes may be required to call data from the various hubs and use them to complete an enterprise-wide, cross-departmental process. In such an environment, context (data semantics) matters, and the data models will have to be reconciled. A single, holistic data model that encompasses all mastered data would be simplest to administer, but it is hard to envision the scope such a data model might be required to address far into the future. If multiple data models must be employed, the challenge becomes reconciling the metadata schemas for those models. That is one reason why data model comprehensiveness, extensibility, scalability and flexibility are important considerations in evaluating hub solutions.
Is creating "hub silos" a real concern today? In 99%+ of cases, no. The major software vendors' data models have evolved through hundreds or even thousands of customer installations and are already more comprehensive than most companies will need for years to come. In addition, most major hub vendors have such an obsessive focus on open standards that data model reconciliation issues are likely to be resolved long before they manifest in an operating environment. Standards not only make such reconciliation a necessary capability for vendors to address, but they also significantly reduce the time required to solve the problem.
So don't be too alarmed by the talk of "hub silos". And remember that you're not going to have much fun at this dance if you're standing by the punchbowl. Can you hear the music?
 ...continue reading...
ROI - Crunching the Numbers
Technology expenditures are viewed with a critical, if not jaundiced, eye these days so creating enterprise-wide alignment around the business benefits to be obtained is a critical part of the process. Nowhere is that need more evident than in enterprise software deployments like CDI. One of the most valuable tools for creating that alignment is the ROI analysis.
Creating Internal Alignment
Getting alignment means addressing three separate issues that any proponent of an enterprise technology investment needs to keep in mind:
- Creating the support network.
CDI is a "community good"; everyone benefits from having clean and consistent customer data even if they do not directly invest in the project. Even departments who are not touched by the mastered customer data benefit from improved reputation in the marketplace, better customer retention, better branding, and a higher stock price. In such an environment, it can be hard to find an individual executive sponsor. If, for example, each of 10 departments would have a realizable benefit through cost savings or new revenue of $1,000,000 over the first year, then funding a project of $2,000,000 would seem to be a slam dunk with a 500% ROI during year one. But no individual department has a large enough benefit to willingly step up and sponsor the project, so you have three options: - Secure a C-level sponsor who can envision the benefits from the enterprise level to drive the initiative (best),
- Create a Coalition of business owners who will benefit from the initiative (second best), or
- Drive the Initiative out of the IT Department (generally not an easy or particularly effective thing to do).
Even when a C-level sponsor for the project is secured, having a support network of business owners throughout the organization who understand and believe in the initiative will make implementation much faster and more effective. In practice, creating the coalition of LOB managers is often a prerequisite to getting C-level attention. CEOs, COOs and CFOs don't have much bandwidth for abstract ideas and proposals, however meritorious. If, however, a significant number of their key management personnel are all talking about and demanding a solution to one particular problem - i.e. a single view of the customer - they will listen and respond.
- Creating alignment around common goals.
CDI projects are like the three blind men and the elephant: what it looks like depends on where you grab hold of it. CDI projects encompass a wide range of potential benefits, and that's a very positive thing. But when key business owners are describing the project in completely different terms to other executives within your enterprise (like, say, the CFO), this can create a impression of an ill-conceived and poorly planned initiative. It is important that the group share a vision for the project, the key deliverables and the necessary phasing of the project over time. It is even worth your time to craft an "elevator pitch" that you can use internally to describe the initiative. Creating the shared vision also creates accountability in and between the group members for delivering on key elements of the project. Thus the credit card division understands that if they don't get their documentation of requirements completed by the end of the month, they will delay critical work for mortgage processing.
- Building the financial case for CDI investment.
With benefits distributed throughout the organization, the financial returns for enterprise software are difficult to quantify. Without hard numbers to plug into the ROI analysis the project is unlikely to go forward. And today's typical CFO is going to be looking for key participants to "sign up" for revenue improvements or cost reductions from the project. Those participants, however, are not going to bet their careers on fuzzy concepts like "better customer data" or "customer lifecycle management". The analysis has to go one or more levels deeper, and LOB owners need to be involved in the process of defining requirements and quantifying the expected benefits. The ROI Model
There are as many ROI models as there are projects. These models do, however, tend to share some common characteristics and have some common requirements. Our goal here is to push the ROI away from "art" and more toward "science" by detailing some of those common elements and the methodology for evaluating them.
From a high level, a typical company has a "hurdle rate" for new investment, particularly for enterprise technology investments. In simplistic cases that hurdle rate is usually dependent upon the company's target operating margin plus some cost overrun allocation. If, for example, a company has a 20% margin and is targeting 25%, any project that has an expected ROI higher than 25% moves them closer to the goal, and higher ROIs move them there more quickly. The time horizon is also a factor - if the goal is 25% margins in 2006 and the proposed project will not yield any benefits until 2007, that's a non-starter.
More common is a budget-based ROI hurdle. The typical company, especially in financial services, has a wide range of potential investments that they are considering, all of which meet or exceed margin-based targets. The company, however, has a limited IT budget and therefore needs to establish an internal benchmark rate that is designed to act as a filter ensuring that only the highest ROI projects move forward.
It is important to understand that CDI needs to be evaluated just as any other prospective IT investment. Despite the fact that CDI is an emerging technology and as such is grossly underutilized in corporations worldwide, our purpose is not to justify the CDI decision but to evaluate it. Failure to adopt this impartial approach risks contaminating the results, and CDI is, as we shall see, a strong enough initiative to stand on its own.
It is a good idea to discuss the ROI analysis process with the CFO or his representative at the earliest opportunity. Often the Finance department has sophisticated multi-factor ROI models already in use and is going to want to plug your numbers into that model for evaluation. You can save a lot of time and effort by understanding the model and the required data points at the beginning of the evaluation rather than trying to retrofit and revisit at the end.
ROI Benefits - Creating the List
The first step in any ROI analysis is documenting the expected benefits. This can be a daunting task, because customer data touches so many operations, divisions, applications, and delivery channels. Moreover, there are various ways to classify and organize the benefits.
One common dividing line is between "Business Benefits" and "IT Benefits". The advantage in this approach is three fold:
- Different parties are clearly responsible - business owners come up with the benefits for their business units, and IT comes up with technology benefits list.
- IT benefits tend to be more strategic - the IT organization has to deliver on longer term capabilities like more rapid transaction processing and more rapid product introduction, which are harder to quantify. Without attribution of dollars in cost savings or revenue, having IT benefits as a separate list escalates those strategic initiatives in the ROI presentation.
- Each list plays better for specific audiences - the COO and CFO are likely to focus on the customer-related benefits and upside revenue potential from CDI initiatives, which tend to be on the business benefits list. The CIO and CTO are more likely to focus on the strategic technology advantages behind a CDI project, and the improved ability to execute against internal deliverables.
The disadvantage to the "Business Benefits" and "IT Benefits" division is that it is somewhat artificial. Most if not all IT reasons for undertaking a project are, in the final analysis, business reasons. If, for example, IT wants to do the project because it will reduce the amount of exceptions that need to be managed, the reason for undertaking this is to keep costs down and improve profits, which is a business reason. If they want to do it because it moves them closer to a true service-oriented architecture, the economic benefits are in reduced future integration expense and more rapid deployment of new products which drives revenue, i.e. business reasons. Nevertheless, this approach is common because it is clear, simple and companies understand it, and the benefits listed above outweigh the disadvantages.
A second approach is the "Benefits by Department" approach, in which benefits for each business unit, (and often, each delivery channel and constituency) are documented. Example classifications might be:
Departments
- Sales
- Marketing
- Service - Call Center
- IT
- HR - Employees
Channels
- Customers - web
- Customers - branch
- Partners
Finally, the sheer number of metrics which are affected by CDI projects can be daunting as well. At Siebel, data on over 9,000 metrics from more than 100 implementations is compiled and analyzed on an ongoing basis. All of these will obviously not apply to all CDI projects, but a thorough analysis is a significant undertaking in any substantial company. Fortunately, the focus for an ROI analysis is not on an exhaustive analysis of all potential ROI sources, but on identification and estimation of the top 10-20 Key Performance Indicators (KPIs) that will impact your business.
It is always best to start with your own internally-generated list of CDI benefits. It is simply too easy to rely on vendor-supplied materials or industry studies or articles, which tend to be too high level. A typical stated benefit from those sources might be:
"Increase customer retention" This is much less useful, and much less convincing, than a targeted and customized benefit statement such as:
"Customer attrition rates in 2005 were 7.8% versus an industry average of 5.5%. Our target for 2006 is one percentage point below the industry average, or 4.5%. This would result in an additional 925,000 customers by year end 2006." Aside from the benefits of creating your own internally generated list of expected CDI benefits, it is important to check that list against other published materials. This can be an eye-opener, particularly when the CDI initiative is driven by a specific departmental or operational requirement (e.g. Gramm-Leach-Bliley Privacy compliance). Likely sources include industry associations, CDI vendors, systems integrators and market analysts.
For example, The CDI Institute (http://www.the-cdi-institute.com/) published a study in July 2005 entitled, "Customer Data Integration as Foundation for Unified Customer Views: Key Industry Scorecards for 2005-06". In this report the key business and IT drivers for current CDI initiatives in various industries are detailed.
In Financial Services, The CDI Institute compiled polling results from 33 institutions to identify the top five business reasons for major financial institutions to undertake a CDI project:
Source: Customer Data Integration as Foundation for Unified Customer Views: Key Industry Scorecards for 2005-06, A CDI Institute MarketPulse(TM) White Paper, July 2005, used by permission.
I have personally validated these results through several "CDI Workshop" engagements with customers, designed to create the vision and ROI analysis for a CDI initiative.
While having an exhaustive list of KPIs for CDI benefits is not an imperative, it is important that all the major requirements from all affected areas of the company are captured.
Time and again we have seen enormous amounts of time and effort wasted by pursuing the wrong goals. Most commonly, this arises when a company is evaluating build vs. buy in their customer data integration solution. Addressing tactical departmental level concerns such as creating a cross-referencing key or integrating a data quality solution leads to initial evaluations that substantially underestimate the effort.
When the issue is escalated to an enterprise level, new issues emerge such as reconciling the various data models in use across the company, or the sophisticated hierarchy and relationship management requirements in the B2B areas of the company. It is not uncommon to see companies start with initial estimates of 1,000 - 2,000 man-days of engineering effort to build a CDI solution, only to see it expand to over 5,000 days once all the major requirements are captured.
Quantifiable vs. Fuzzy KPIs
The central problem in crafting a credible ROI analysis for CDI initiatives is that many of the benefits are difficult to quantify. If a CDI solution enables a company to consolidate customer feedback and service requests, such that they understand customer needs better and are able to more quickly introduce new products that differentiate them in the marketplace, what is that worth? It may be matter of incremental revenue for one company, and a matter of survival for another.
Moreover, many of the benefits are particular to one company, or one department, or one application. Context matters in determining benefit. The benefits from being able to centrally manage exceptions and discrepancies in customer data from one central location (data stewardship) depend directly on the degree to which such exceptions and discrepancies occur. It may be a small matter for one department that uses only one core system for processing, but a mission-critical initiative for another running multiple systems or channels (i.e. administering multiple products, or multiple systems resulting from mergers or acquisitions).
If we examine the universe of potential KPI metrics for CDI, we see data types that range from "precisely quantifiable" to "very hard to determine" and from "objective" where hard data is available either internally or from industry statistics to "subjective" where benchmark data is not readily available. Thus a particular KPI can be precisely quantifiable, and yet be subjective if such calculations have not been done before. Or a KPI can be very hard to determine, and yet be objective if sufficient studies or analysis exist to provide confidence in the anticipated outcomes.
It would be nice to divide these up into quadrants and focus on objective, precisely quantifiable metrics, but in reality these KPIS exist along a continuum which is different for every company. Yet clearly, if data is too subjective or too hard to determine, we cannot classify it as measurable.
If we were to attempt to characterize these KPIs in graphical form, it might look like this:
Figure 2: Hard versus fuzzy KPI data
It is therefore highly useful to look at measurable data first. In many cases, the ROI from KPIs that are measurable is sufficiently high to justify moving forward with the CDI project. In fact, this has been the case in all but two of over two dozen CDI projects I have been involved with. If the expected ROI is high enough from the measurable KPIs, simply complete the ROI analysis with those factors and list the others (unmeasurable and partially measurable metrics) in the explanatory text.
If the anticipated returns from measurable KPIs come up short, then it's time to move on to the "somewhat measurable" category. There will be two sets of likely candidates here -
- those that are closest to belonging in the measurable category, requiring the least effort to estimate and the most reliable estimates, and
- those that are most strategic, providing the larger contributions to anticipated returns and which therefore take priority in analytical efforts.
Finally, in the "unmeasurable" category will be several KPIs for CDI returns that are strategically important, and which should not be left out. Your ROI analysis will typically have a page or more of introductory text in which the project purpose is defined, the various approaches analyzed and the reasons for undertaking it listed. This is the place to include strategic objectives that are very difficult to quantify.
From recent CDI Workshop engagements some of these unmeasurable KPIs that we have encountered have included: - Branding - appearing as "one bank" to customers regardless of channel
- Creating a branded service experience across all channels
- Increased employee satisfaction
- Reduced cost of adding future operational systems to the IT architecture
- Reduced average hold time in call center
These types of benefits are real and often substantial, but they are both hard to determine and subjective with regards to the ultimate impact on the bottom line.
As a final note, once the ROI analysis framework is complete, it is worth revisiting the high level strategic documents for your company. Look at the mission and values statements for both the departments and the company as a whole. Reread the chairman's comments in the latest annual report. Couch your ROI proposal in similar language and position it as driving toward those larger corporate objectives. These are the metrics for which the senior management will be accountable to shareholders, and it is language that will resonate in the corner office. Positioning CDI as a feather in their cap in the fight for excellence is a winning proposition.
...continue reading...
Your Customer's Backside
What is a 360-degree view of the customer, anyway? And do you really want one? After all, admiring the backside of your customer isn't likely to win you any additional brand loyalty. Not of the kind you would want, anyway...
I read a post today by Bill Inmon, who was disturbed by a writer's claims that it was possible to "create a 360 degree view of the customer from structured data sources using demographic data." The gist of Bill's commentary is that demographic data is not enough. And he is correct, for some companies. It all depends on your business objectives in deploying a CDI solution.
CDI is one part of the whole discipline of Master Data Management (MDM). With CDI, we attempt to carve out the functionality specific to customer data in order to reduce the scope of the problem and craft a workable solution. But "customer data" is, in itself, a pretty broad category. It goes far beyond simple demographic data. Service interactions, as Inmon notes in his post, certainly qualify as customer data. Product information can also qualify; products are important only because customers buy them, and companies need to be intensely interested in what their customers are buying, and when, where, why and how they are buying. Transactions or orders are also customer data. A significant percentage of service issues are related to orders, and every order represents a customer touch point that needs to be captured and available for analysis.
But not all companies are in immediate need of all aspects of a CDI solution. CDI projects are almost always undertaken with specific deliverables in mind, and these vary from one company to another. - Company A has good order management processes and analytics for real time business, but has customer data residing in multiple back office operational systems that gets out of sync and creates data quality issues.
- Company B has a data quality solution in place that helps ensure data consistency for the core demographic customer information, but the service calls are managed on a different system and there is no visibility into service history anywhere except on the service desk.
- Company C has a consolidated view of core demographic customer data but due to acquisitions is running multiple operational systems and has not created a reconciled view of service and orders.
Each company has a business problem that is related to customer data integration. But the functionality that needs to be deployed in order to meet the immediate needs of the business is different in each case. We must, I think, credit the business and technology leaders who are driving CDI initiatives at their companies with a modicum of intelligence. We must assume that, at a minimum, they know what needs to happen to their customer data in order to solve the immediate problem. And that, frankly, is all that is required to get started productively with CDI.
Note that I am not saying that every business or technology executive promoting CDI understands all the technology behind it, or even all the root causes of problems like data inconsistency. I'm not even saying that they understand all the potential benefits from a CDI solution, or how to quantify them for ROI analysis.
In CDI, as in most fields, the purpose of technology is to facilitate business.
One brokerage firm executive put it like this:
My problem is that 90% of customer contact is through the branches, 90% of orders come in through the web channel, and 90% of service requests come into the call center, and none of them talk to each other. Bingo! The concise business statement of the problem.
In the real world of limited budgets, cost justifications and deadlines, every CDI implementation is a phased project. Phase I scope is typically determined by a business statement like the one above. If you consider that the largest institutions like Merrill Lynch and Citigroup have thousands of applications touching the middleware layer, it could not be any other way. In the mission critical phase 1 implementation, a very limited subset of applications specific to the immediate business problem (and therefore to the ROI for the project) is targeted for integration.
And it is not only the number of applications that is limited in scope. In the last major bank CDI deployment I worked on, phase 1 involved the wholesale side of the bank, and all the integration was done via batch file transfers. Real time connectivity was not required to achieve the desired business outcomes, and batch integration was faster and simpler, speeding time to market. As the bank moved to incorporate the retail side in phase 2, real time capabilities were introduced and the batch file integrations in wholesale replaced.
So, in a way, Bill is jumping ahead of himself - and ahead of the companies who are working to implement CDI - by insisting that "To establish a 360 degree view of the customer, you will need to incorporate all your customer communications in your CDI efforts." Adding unstructured and semi-structured data (documents, proposals, IMs, emails, etc.) to the CDI data mix is for most companies a long term goal, but for most implementations it isn't in that short list of critical phase 1 requirements.
What is truly important is ensuring that your short term project implementation builds toward a cohesive long term architectural goal for your CDI solution.
Ultimately, a CDI solution is probably going to be required to handle demographic data, transaction data, product data and unstructured data. It is probably going to be deployed in a componentized, service-oriented environment, and will need to be able to communicate in real time, near-real time (synchronous and asynchronous) and batch file tranfer modes in a guaranteed-delivery manner. It almost certainly will need to incorporate a data quality regime, including reconciliation and matching, cleansing and enhancement. And it will be required to be flexible, scalable and extensible in the data model and associated meta data and common object frameworks to accommodate future growth.
This is where the technology expertise comes in, and why CDI is so complicated. I have seen companies err on the side of caution, however, and suffer from paralysis by analysis. It is not necessary to have every aspect of the ultimate CDI solution designed and scoped prior to beginning a phase 1 implementation, and companies need to be careful not to get caught in that trap. On the other side of spectrum, we have done some three-day CDI workshops and come out with an executable Phase 1 scope and requirements. Fortunately for companies considering CDI, this is leading edge technology, not bleeding edge. There are few technical issues that have not already been addressed, few challenges that have not already been met - and mastered - by others.
...continue reading...
The Name Game - Revisited
Colin White has attempted to cut through the nomenclature fog in his latest blog entry entitled, " Master Data Integration or Master Data Management?". He starts out strongly, drawing some critical distinctions and noting that data integration projects include applications, techniques and technologies (Gartner calls it "technology, processes and services" which is actually more accurate in this increasingly service-oriented world): Data integration applications solve business problems using one or more data integration techniques (data consolidation, data federation, data propagation, changed data capture, data transformation). These techniques are implemented using one of more data integration technologies (EII, ETL, EAI, EDR, ECM, etc.). (emphasis added)
That's a good and useful distinction. I wish he had stopped there.
But he didn't.
White goes on to say:
MDM is really a data integration application. And the fog rolls right back in...
Moreover, when you combine this with his previous statement, "People constantly confuse MDM applications with MDM technology and techniques", it makes no sense. Using the tried and true commutative property from mathematics, simple substitution yields this sentence:
""People constantly confuse [data integration application] applications with [data integration application] technology and [data integration application] techniques."
Well, no wonder they get confused!
Let's try a little fog-cutting of our own.
First, MDM isn't really a data integration application. MDM stands for Master Data Management, so MDM is management, which means that it is a discipline. There are two main qualitative differences between master data management and integration.
- Management is vertical; integration is horizontal. Management is a discipline that brings business expertise and domain knowledge to the project, ensuring that the results meet the needs of the business. Integration is a set of tools - generic applications, standards and techniques for getting applications to share information.
- Management is an ongoing process; integration is a discrete event. Once data is integrated, it still needs to be managed. Data quality in particular is an ongoing exercise, as customer data degrades at a rate of about 2% per month. There are new full-time positions in data stewardship. New applications need to be added, application upgrades need to be managed, and the IT configuration maintained. Maintaining the processes around CDI also take work. Someone needs to establish a CDI center of excellence, and compile and use best practices throughout the organization. Most importantly, once customer data is reconciled and the single, comprehensive master record established, someone need to do something with it. This means that sales, service and marketing processes will all change to take advantage of improvements in the customer data. New processes such as Customer Lifecycle Management can be employed. Integration, on the other hand, is a discrete task. Once the systems can communicate with each other, the task is finished. Yes, there will be ongoing maintenance, but that's all it is - maintenance.
White calls Customer Data Integration's naming "unfortunate", but it's really more accurate than MDM. If you are doing a Customer Data Integration project for a customer, you do the planning, testing, implementation, training and education, and once the integration is done you get out. If you are doing a Master Data Management project, you're in for the long haul, and you had better be working for the company doing the project.
CDI is the name adopted by the market analysts (Gartner coined the term) and vendors in the space. And from their perspective, they are right. The application vendors and the systems integrators are there to help set up CDI solutions for customers. Once it is set up, they leave the management of the solution - the ongoing data quality work, the process improvements and the enforcement of the new CDI paradigm - in the hands of the customer (with proper help desk support, upgrades and so on). It is a Customer Data Integration project to them.
Customers, on the other hand, are more interested in what should properly be termed Customer Data Management. This entails not just the successful installation of the solution, but the ongoing daily effort to maintain and improve it. But customers don't use this term. Why not?
For one simple reason - it isn't what they care about. CDI, properly implemented, is a nearly invisible back office function. The only daily interaction a customer should have with the CDI system is through the data stewardship position, manually correcting data errors that are too severe to be corrected by the rules-based DQ system. Instead, customers care about having accurate data show up in their sales automation software, in their CRM system, in their marketing systems, in billing, accounting, the call center, service tracking - in short, all their existing systems!
A final point worth noting: the term "Master Data Management" implies that master data already exists, and now you need to manage it. The term "Customer Data Integration" implies that customer data exists, and now you need to integrate it. Which is a more accurate picture? I can count the number of companies that have completed their MDM and CDI projects on one hand. Almost every company I have talked to is still working to implement mastering solutions.
Much of the misunderstanding about the terms used in the market stems from the difference in perspective between the companies which are experiencing the data consistency problems and the companies who want to sell them tools or services to solve the problem. When Colin White talks about MDM, he isn't talking about Master Data Management, he's talking about Master Data Applications. So naturally, it seems to him, "MDM is really a data integration application".
If I could recast Colin White's statement, it would read something like this.
Master Data Management (MDM) is a discipline in Information Technology (IT) that focuses on the management of reference or master data that is shared by several disparate IT systems and groups. MDM is required to warrant consistent computing between diverse system architectures and business functions.
MDM encompasses specialized applications, techniques and technologies for aggregating the data from source systems, matching, merging, reconciling and standardizing the data, and ensuring that the target applications and systems have access to the master record on a timely basis.
MDM applications that are focused on the inbound data (aggregation) and the outbound master record (distribution) in turn use data integration applications and data integration technologies. Data integration applications solve data integration problems using one or more data integration techniques (data consolidation, data federation, data propagation, changed data capture, data transformation). These techniques are implemented using one or more data integration technologies (EII, ETL, EAI, EDR, ECM, etc.).
And you can, of course, do a similar sort of definition for CDI, but it's actually simpler since CDI claims "integration" as its domain rather than the broader "management" of MDM. Here I've tied together the classic Gartner CDI definition with what is expressed above:
Customer Data Integration (CDI) is the combination of the technology, processes and services needed to create and maintain an accurate, timely and complete view of the customer across multiple channels, business lines and, enterprises, where there are multiple sources of customer data in multiple application systems and databases.
CDI encompasses specialized applications, techniques and technologies for aggregating the data from source systems, matching, merging, reconciling and standardizing the data, and ensuring that the target applications and systems have access to the master record on a timely basis.
CDI applications that are focused on the inbound data (aggregation) and the outbound master record (distribution) in turn use data integration applications and data integration technologies.
Data integration applications solve data integration problems using one or more data integration techniques (data consolidation, data federation, data propagation, changed data capture, data transformation). These techniques are implemented using one or more data integration technologies (EII, ETL, EAI, EDR, ECM, etc.).
Why is this important?
In order to solve a problem, the first step is to define it. I saw a great quote in an article in Information Week on innovation last week, where MIT Professor Michael Hawley says, "Sub par performance rises up in technology when students work without defining a problem. If you don't have a problem, you don't have a solution. Once you take your eye off the ball, you get lost in XML and all that stuff."
Collectively, we're lost in "XML and all that stuff" right now. Every vendor's slide deck looks the same and customers are still struggling with the basic questions behind master data management issues (including CDI). What is it going to cost to implement? What benefits can I expect to derive, and what is that worth? (ROI) What's the long-term cost of ownership of the solution? (TCO) I don't know how bad the data is - how do I find out? What are the logical phases of a project? How do I get started?
We need to continue to work to clarify our language around the topic, to ensure that we're communicating clearly with companies considering MDM or CDI solutions on the issues that matter to them. The companies who will succeed in the MDM and CDI marketplace are those who can establish a dialogue with customers, and keep the focus where it belongs - on the customer's objectives. And that requires a common language.
...continue reading...
Speaking of metrics
The fifth annual Kalido User Group meeting held last week elicited a lot of positive commentary about MDM as an emerging priority. Attendees were polled on a variety of related questions and the results are surprising in their near unanimity on the importance of MDM. In fact, some of the opinions were unanimous! One hundred per cent of respondents see the management of master data ranging from important to absolutely vital for effective enterprise information strategies. A few choice quotes from the article:- almost two-thirds of Kalido customers see tackling master data management (MDM) as a top three priority
- When asked why MDM is needed, the top two answers from respondents were:
- to develop standard business definitions (56 percent) and
- to improve data governance (56 percent)
- Fifty percent of respondents viewed MDM as key to generating faster and more accurate business reporting
- 41% said that gaining a consolidated view of enterprise performance was a major business driver
- 41% of survey respondents found that enabling ownership of master data by the business is also a key driver
- The chief financial officer and the finance department emerged as the primary internal customer for MDM projects, as cited by almost half of the survey respondents. The chief marketing officer and the sales and marketing function emerged as the second most likely internal customer.
- more than three quarters of respondents said they needed to manage more than 25 types of master data, and over 40 percent managed more than 100 types.
Obviously, there is still a burning need for performance metrics, ROI metrics, and hard data around implementation results, but these user conference survey results bolster the argument that the problem is widely recognized and companies are actively searching for solutions.
...continue reading...
Tackling the ROI in MDM
In Master Data Management, Part I: Show Me the Money, Roddy Martin, AMR's VP Research for consumer and life sciences manufacturing, tackles the issue of cost justification for large-scale projects such as MDM and its sister discipline CDI. In the end, as Martin notes, the general feeling is that "it's too difficult to get the business to buy into it".
I have been thinking a lot about the ROI for CDI in recent weeks, primarily driven by my customers' efforts to forecast, model, and quantify the benefits. Two years ago when I started working on CDI, the technology was very early and the space was still being defined. Today, ROI analysis of the benefits is in a similar place. There simply aren't enough enterprise-wide CDI deployments that have been in production for a long enough period of time to gather hard data on the improvements and identify trends and patterns.
Every piece of evidence that we have is therefore, almost by definition, anecdotal. But that also means that every piece of evidence that we have is important, as we build toward a critical mass that allows us to make some justifiable generalizations, establish metrics and set expectations for the realizable benefits of CDI.
Martin's article touches on several of the problems inherent in creating an investment scenario for MDM. Although he doesn't call them out individually, there are four issues highlighted in this first article:
1. MDM is big. It's a big problem, affecting the whole enterprise, touching dozens or hundreds of applications. The solution is therefore likely to be correspondingly big, and correspondingly expensive. The path of least resistance is to ignore it, and hope that it somehow resolves itself or that someone else deals with it.
(On the other hand, I actually had one senior IT manager say to me, "I'm 52 years old. I know we're not going to resolve our master data issues on my watch - I'll be retiring in another 4-5 years. This problem will outlive me. But if we don't get started now, it's only going to get worse and our competition will get better." Proof - or at least, another anecdote - that if senior management can think strategically about these issues then the size of the problem can actually help facilitate action.)
2. MDM and CDI are complex technologies, not easily understood by the business leaders. Or many of the technology leaders, either. Business leaders, in particular, are accustomed to making financial decisions. Invest $1, save $2. Invest $1, earn $2. The wisdom in effective management of scarce resources is in evaluation of the tradeoffs. No company has the resources to undertake every potential initiative, so judgment is required to determine those projects that are most strategic, most likely to succeed, and contribute to a long term vision for the company.
Note that it is not that business leaders don't understand the problem. They see the results of bad customer data every day, reflected in operational costs and customer satisfaction issues. They know it's a problem.
The problem is that the solution is a very technical one. Business leaders are not afraid of spending to solve a problem, but most of the problems corporations have tackled have been addressable by an application. If you can't keep track of your customers, you install an application that tracks customers. Problem solved. CDI certainly requires an application, but it is much more than just an application. As Aaron Zornes of the CDI Institute notes:
During 2005, the average CDI software investment was $1.2 million with the typical large scale CDI project requiring systems integration (SI) fees ranging four to six times the amount spent on the CDI software. Clearly, then, application integration is a critical cost factor in implementing a CDI solution. Faced with a $7-8 million price tag, a business leader is going to want to drill down on why costs are so high. And the answer that comes back is going to be in terms of connectors, adaptors, middleware, BPM, metadata and data models. Again, it isn't that these concepts are beyond the understanding of a business leader, but they are very hard to tie to specific costs or benefits. They don't fit into established decisioning models for IT projects very well.
3. Didn't we pay to fix this already? CRM and ERP have long promised "single view" types of benefits, through the simple aggregation of activity around a customer or an order on to one system. There have been significant integration expenses already incurred in plugging those systems into existing IT environments. There is a strong sense that we should already be there when it comes to a single view of the customer. Certainly the technology exists - has existed for quite awhile. Standards have emerged such as XML for data interchange, OAG for customer data, and BEPL for business rule modeling. Integration vendors have been telling the story for years, and many dollars have been spent in pursuit of pieces of the CDI puzzle.
Unfortunately, pieces of the puzzle is all they generally are. As Martin notes in his article,
...business was so engrossed in gaining functional efficiency and lower costs in its independent silos (for example, manufacturing quality, finance, and sales) that it only saw the departmental and functional side of information value and did not think further: to the whole company. This problem is structurally reinforced by the fact that the business executive leadership team, structured to represent business functional silos, never saw the cross-functional problem until the operational strategy ... identified the need for one version of the truth.
4. Established project evaluation methods are insufficient. After the tech crash of 2001, and exacerbated by 9/11, spending on technology was drastically reined in. A mentality emerged which served companies well at the time, forcing hard dollar cost justification for every expense, establishing expected returns and time horizons. This exercise needs to be performed for CDI projects as well, but it is made more difficult by several factors:- There is a large aspect of "community good" about a CDI project. Every department and business unit benefits from having consistent and accurate customer data. But the project is generally so large that it is difficult to cost justify at the individual project or even business unit level. This means that a significant amount of internal alignment behind the project has to take place. This, in turn, requires strong senior management (typically CEO) sponsorship for the initiative.
- In a traditional purchase evaluation, the benefits to be derived can either be cost savings from new efficiencies, or revenue upside. If the benefit is revenue-based, a business leader has to "sign up for the revenue". In an enterprise-wide project like CDI, this methodology would require almost every business unit to sign up for some incremental revenue increase as a result of CDI success.
- The benefits from CDI are mostly "soft" benefits, such as improved customer satisfaction, greater share of wallet, perception of the company as "customer-centric" and better target marketing. Expense reduction alone is not usually sufficient to drive a CDI project. Certainly CDI benefits play a critical role in harder metrics like revenue per customer, average sale, and customer churn rates, but these linkages are not generally tight and are hard to quantify.
Roddy Martin takes a first cut at the issues around ROI calculations in this article, but the end result is, like most of the data we have, anecdotal. I an anxious to see where he takes it in his follow up article(s).
I don't think that companies have to wait and see if CDI is a viable technology. Clearly it is, as dozens of companies are doing it successfully today.
I don't think that the ROI model needs to be quite as "tight" as a typical application-based project plan would require, and companies who are committed to improving their ability to serve their customers will come to terms with this. In every CDI implementation I have been involved in, there has been an ROI model, but they have each been different - sometimes dramatically different - in the economic drivers for initiating the project. This is as it should be. Every company has a unique combination of technical environment and pre-existing infrastructure, channels for communicating with customers and processing orders, cost structures and revenue opportunities. I doubt one model can encompass every retail banking environment, much less every financial institution - and certainly not every industry.
So the success of CDI as an initiative on the drawing board of CTOs worldwide is likely to succeed in the executive offices and boardrooms of major corporations not on the basis of pure, hard, ROI cost-benefit data. It is going to succeed - or fail - on the ability of key CDI project sponsors to convey the vision, secure the executive participation, and create the sense of urgency to drive the project off the drawing board and into production.
Certainly more hard data will help. Even anecdotal evidence is significant when the volume grows to a point where trends can be identified. There are already a handful of useful metrics that have emerged from the collective CDI experience so far, and the favorable evidence is mounting.
...continue reading...
Gartner summary
The SearchCRM article, Oracle-Siebel deal shakes up CDI world, recaps a recent Gartner report on the convergence of the Customer Data Integration product suites from Oracle and Siebel. The Gartner report characterizes the combined Oracle-Siebel entity as having "an embarrassment of riches", but cautions customers contemplating a CDI purchase to look for clarification on the future product direction. Obviously, I can't comment on post-merger product plans, but there are serious problems with taking a wait-and-see approach.
First, there is an explicit cost to waiting. If you look at the reasons why financial institutions put in a CDI solution, many of them are related to costs. In November 2004, The CDI Institute did a MarketPulse(TM) survey and identified eight key reasons:
- fraud reduction
- database consolidation after M&A
- reduce costs of manual data management
- customer retention
- compliance and C-level visibility into real-time operations
- customer satisfaction
- competitive advantage
- central management of privacy policies
Of these 8 reasons, the first 4 all have direct costs associated with continuing business-as-usual. Before deciding to defer a CDI decision, these costs need to be measured and understood versus the anticipated cost savings from having accurate, consistent customer data. Of the remaining 4, each has indirect costs that are attributable to bad customer reference data. These are less easy to quantify, manifesting as risk rather than expense. Customers who are less satisfied are more likely to go to a competitor. Managers who do not have accurate data make less optimal decisions. Inadequate privacy management may result in regulatory sanctions if exposed. Your mileage may vary.
Second, what is the risk you are trying to mitigate by deferring the decision? One of the principal goals of CDI is to abstract the customer data away from the source applications and create a centralized management discipline around this strategic asset. Even if the CDI implementation involved an application which suddenly, somehow, became obsolete, the application itself is a small part of the CDI discipline.
The work which must be done to implement CDI involves a significant amount of initial data quality effort, scrubbing and reconciling the data. This work will never be lost or invalidated, and must be performed in any CDI scenario. It involves work around data management, reconciling the metadata and common objects which will serve the data back to the target applications. It involves work in the EAI layer, creating the ETL interfaces, connectors and adaptors to gather and distribute the data. This core engineering work is necessary for CDI, regardless of the application selected.
Perhaps most importantly, the organizational framework around governance and project management for CDI needs to be put into place. This includes documentation of business processes, establishment of data management practices, a "center of excellence" around reference customer data, best practices for management of customer data, and establishment of data quality and data stewardship functions at the enterprise level. This is partly organizational, and partly cultural. In any event, it is 100% transformational and requires a consistent dedicated effort, sponsored by executive management and championed by business unit leaders throughout the company.
None of these changes are small, or easy, and if you are interested in CDI success in 2006 the effort needs to start now.
CDI enjoys a significant advantage over many traditional applications in that (1) it is new and therefore captures and fully utilizes many modern technological enhancements, from an open, componentized architecture, to exposure of functionality through a services framework that helps ensure interoperability, and (2) it is based on integration technologies. Application connectors? Got 'em. TIBCO, SeeBeyond, webSphere? Got 'em. J2EE, .NET, Corba? Got 'em. The need for a modern CDI solution to provide a flexible integration framework connecting multiple source systems and data stores together in a robust and flexible manner inherently means that it is easy to manage as a solution. That means easy to upgrade, swap out, switch components, and truly manage as part of an SOA. The actual risk of a CDI solution somehow being rendered "obsolete" is miniscule.
Third, there is a significant implied cost to waiting, in the form of foregone potential revenue. Just for fun, I took the stock price charts of six banks that I know very well. Three of them have implemented CDI in some form at least one year ago, and three of them are evaluating CDI but have not implemented it yet.
Stocks of the companies who have implemented CDI showed an annual return of +9.71% over the past 33 months without considering dividends or taxes. Stocks without an implemented CDI solution showed an annual -5.57% return over the same period.
I'll be the first to caveat this quick study with a note that it is merely anecdotal, not scientific, but I did not pre-select the banks on the basis of stock price performance. I simply chose banks on the basis of what I know about their customer data practices. I blended the stock prices of each group of 3 banks to mask their individual identities, and reindexed each set of daily prices to an equal starting point to give you some idea of relative performance.
Interestingly, all three of the banks which have implemented CDI are experiencing core deposit growth that exceeds the growth in population in their primary SMSA. The three banks that have not implemented CDI appear to be losing market share. (In all three non-CDI bank cases, there was some growth, but it was not keeping pace with the growth in their markets. One non-CDI bank showed solid core deposit growth, but when I dug into why, it appears to be exclusively from acquisitions.) Analyst upgrades among the CDI banks are also consistently greater than among the non-CDI banks.
This quick performance analysis confirms what I have been hearing from banks for the past year or so. Smart bankers understand that the battle right now is for share of wallet, and the signposts on the road to victory are marked with metrics like "average number of products per customer", "channel utilization" and "customer churn". What you don't measure, you cannot improve. For many financial institutions this last reason - revenue upside - dwarfs the preceding two in terms of importance. Bankers understand that while operating efficiency is key to survival in the world of declining margins, you can't cost-cut your way to success.
These are points that Gartner missed in their analysis. It's easy to see why. Arguments that are valid for academics - i.e. research analysts - have real world consequences for companies struggling with issues like customer retention. An academic can say, "the future is murky, so we need to wait and see what develops before we commit to a recommendation or make a forecast". In the real world, waiting has consequences. Fortunately, the three considerations discussed above all argue against a "wait and see" policy. The battle for your customers is going on right now, and you need the right weapons to fight for those customers. Delaying a CDI decision right now could be one of the costliest mistakes you could make.
...continue reading...
|
|
|
0 Comments:
Post a Comment
<< Home