Daniel Teachey, DataFlux 

According to recent analyst research, many companies see master data management (MDM) as a cure for integration or data management mistakes. The issue with approaching MDM in that way is the risk of missing the forest for all the trees. While many individuals naively consider MDM to be a technology issue, others consider the way that MDM processes and policies can address, and ultimately “fix”, both data and integration challenges.

The way we perceive our approach to MDM is that it is not about technology, and in fact, is not really about the data either. Yet this concept is often difficult for people to grasp, especially folks in IT. But the bottom line is clear: MDM is about using key data to improve the business, and if the program is not approached in that way, it increases the risk of failure.

If you step back from your MDM program and examine why it’s important and how it can enrich your business, you’ll see that every aspect of a successful MDM initiative revolves around the concept of business improvement. For example, you can’t strengthen customer relationships if you don’t know who your customers are. It’s unwise to create and produce innovative products without a way to efficiently get the products in the hands of your customers. The examples go on and on. Data is at the heart of business. And good data is the engine that drives successful businesses.

We have identified three areas of business problems that good data can help combat: risk mitigation, cost control and revenue optimization. Using data to see the big picture – whether it’s due diligence in an acquisition or assuring regulatory compliance reporting – can greatly reduce risk exposure. Data can also be used to control costs. Properly managed data can help companies unearth the tiny areas where money is leaking out of the organization – ways that could never be tracked manually. And, with a diligent data quality approach, you can deliver significant revenue gains for your business.

Still not convinced MDM is a business issue? Consider the fact that businesses have thousands of business processes to execute each day. A recent Forrester Research study estimated only 5 to 15 percent of those processes are automated, which means the overwhelming majority of companies rely on human involvement to execute these processes. MDM-as-technology apologists would argue this only shows the white space that exists in getting more data automatically processed. Our approach is that MDM creates an environment where companies can automate those business processes, get consistent execution on them and optimize them based on factual data that comes from the organization. It’s more than just automating data; it’s doing something useful with it that drives business and increases profits.

Look at how data can be stored in an organization – in independent silos. Let’s say marketing is using a database to generate leads for sales. Finance has another database with customer history and corporate P&L. Sales and manufacturing have yet another database to manage order history and product inventory. A successful campaign by the marketing team is deemed a success because the featured product’s sales are up. However, the financial reality is that those sales came at the expense of another product’s sales, so it wasn’t really a success. Meanwhile, manufacturing didn’t know about the campaign, so it didn’t adjust inventory levels. The company must now deal with an inventory surplus, customer dissatisfaction because orders aren’t being shipped and a financial hit to the bottom line. All because data isn’t being shared.

It’s true that part of a successful MDM initiative involves cleaning up and sorting through this data that has traditionally been kept in silos. However, it isn’t meant to cause finger-pointing within an organization. After all, it was just the way things were done. And while cleaning up databases and correcting the problems of the past is part of effective MDM, it shouldn’t be the main driver of the program.

The bottom line is this: If the goal of your MDM program is just to have immaculate data, you’re missing the point. The data must be driving a business goal. Otherwise, the return on your MDM investment will never materialize, because your business process won’t improve. In today’s competitive environments, with the customer, employee and regulatory demands – it is essential to run your business as efficiently as possible. The key to better business is better data, managing and funding your data infrastructure like you would your other corporate assets. This is only achievable if you build data management and data governance processes based on business requirements.

Check out these white papers:

Populating a Data Quality Scorecard with Relevant Metrics

Too often, data governance teams rely on existing measurements as the metrics used to populate a data quality scorecard. But without a defined understanding of the relationship between specific measurement scores and the business’s success criteria, it is difficult to determine how to react to emergent data quality issues - and determine whether their fixing these problems has any measurable business value. This white paper by David Loshin explores ways to qualify data control and measures to support the governance program.

Building a Data Quality Scorecard for Operational Data Governance

Operational data governance is the manifestation of the processes and protocols necessary to ensure that an acceptable level of confidence in the data effectively satisfies the organization’s business needs. In this white paper, David Loshin from Knowledge Integrity examines how a data governance program defines the roles, responsibilities, and accountabilities associated with managing data quality, and how a data quality scorecard provides an effective management tool for monitoring organizational performance with respect to data quality control.

by Ravi Shankar , Siperian, Inc. 

Critical master data management (MDM) functionality can be easily overlooked when request for proposals (RFP) are narrowly focused on a single business data type—such as customer (Customer Data Integration) or product (Product Information Management) — or on near-term requirements within a single business function.  Consequently, IT teams and systems integrators alike run the risk of selecting and investing in technologies that may be difficult to extend to other data types or difficult to scale across the organization.  Worse, such solutions will likely require costly and extensive custom coding in order to add additional business data entities or data sources, or to extend the system to other lines of business or geographies.  In order to avoid these costly pitfalls, bolster the return on investment, and reduce the over-all project risk, it is important that your RFP include key business data requirements across several critical business functions including sales, marketing, customer support and compliance.

To avoid the common mistakes made by MDM software evaluation teams and ensure long term success, you should make sure that key components are built into your master data management RFP.  By including these ten critical MDM requirements in your RFP, you will be well on your way to laying the foundation for a complete and flexible MDM solution that addresses your current requirements, and is also able to evolve to address unforeseen future data integration requirements across the organization.

Ten Costly RFP Mistakes to Avoid  

Mistake #1:  Failing to ensure multiple business data entities can be managed within a single MDM platform

When you select and deploy an MDM platform make sure it is capable of managing multiple business data entities such as customers, products, and organizations all within the same software platform.  By doing so, system maintenance is simplified and more cost effective which results in lower total cost of ownership.  A less favorable alternative is to deploy and manage separate master data solutions that each manages a different business data entity.  However, this approach would result in additional system maintenance and integration efforts and a higher total cost of ownership.  Another advantage of an MDM platform which can handle multiple data types is that implementation can begin with a single business data entity like customer, and can later be extended to accommodate other master data types—resulting in rapid return on investment.  

Mistake #2:  Ignoring data governance needs at the project- or enterprise-level

Data governance is unique to each and every organization since it is based on the company’s business processes, culture, and IT environment.  However, companies typically select an MDM platform without much thought to their enterprise data governance needs.  It is critical that the underlying MDM platform is able to support the data governance policies and processes defined by your organization.  In contrast, your data governance design could be compromised and forced to adapt to the limitations of some MDM software platforms with fixed or rigid data models and functionality.  Controls and auditing capabilities are also important data governance components.  In order to properly support this functionality, your RFP should require the MDM platform to integrate with your security and reporting tools to provide fine-grained access to data and reliable data quality metrics.

Mistake #3:  Failing to ensure the MDM platform can work with your standard workflow tool

Workflow is an important component of both MDM and data governance, as it can be used to approve the creation of a master data entity definition and to determine, in real-time, which conflicting data entities survive.  Workflow can also be used to automatically alert the data steward of any data quality issues.  So in preparing a master data management RFP, it is important to raise the question of how the MDM platform will integrate with the standard workflow tool that you have selected.  Several MDM vendors bundle their own workflow tool and may not offer integration with your standard workflow tool.

Mistake #4:  Failing to ensure the solution supports complex relationships and hierarchies

With a single entity master data hub, such as customer, hierarchies and relationships are relatively straightforward.  For example, organizational relationships are depicted as legal hierarchies of parent and child organizations, while consumer relationships are those belonging to a common household.  On the other hand, hierarchies among multiple data entities can be highly complex.  Examples include: retail locations in the Eastern region stocking only certain products; complex counterparty legal hierarchies determining credit risk exposure; or an account holder’s spouse being a high net-worth individual.  Make sure your MDM request for proposal requires the solution to be capable of modeling complex business-to-business (B2B) and business-to-consumer (B2C) hierarchies, along with the definitions of those master data entities within the same MDM platform.

Mistake #5:  Relying on fixed Service Oriented Architecture (SOA) services

Reliable data is a prerequisite to supporting SOA applications— applications that automate business processes by coordinating enterprise SOA services.  Since MDM is the foundation technology that provides reliable data, any changes made to the MDM environment will ultimately result in changes to the dependent SOA services, and consequently to the SOA applications.  IT professionals need to ensure the MDM platform can automatically generate changes to the SOA services whenever its data model is updated with new attributes, entities, or sources.  This key requirement will protect the higher-level SOA applications from any changes made to the underlying MDM system.  In comparison, MDM solutions with fixed SOA services that are built on a fixed data model will require custom coding in order to accommodate any underlying changes to the data model.

Mistake #6:  Cleansing data outside of the MDM platform

Data cleansing includes name corrections, address standardizations, and data transformations.  Typically the number of source applications that provide reference data to departmental level Customer Data Integration (CDI) or Product Information Management (PIM) solutions is relatively small.  In these cases, the data can be efficiently cleansed at the source using commonly available data quality tools.  In contrast, the number of sources for an enterprise MDM deployment spans multiple departments and typically comprises tens or hundreds of systems.  In this scenario, cleansing the data at the source systems is not viable.  Rather, data cleansing needs to be centralized within the MDM system.  If your company has already standardized on a cleansing tool, then it is important to ensure the MDM solution provides out-of-the-box integration with the cleansing tool in order to leverage your existing investments.

Mistake #7:  Thinking probabilistic matching is adequate

There are several types of matching techniques commonly in use—deterministic, probabilistic, heuristic, phonetic, linguistic, empirical, etc.  The fact is no single technique is capable of compensating for all of the possible classes of data errors and variations in the master data.  In order to achieve the most reliable and consolidated view of master data, the MDM platform should support a combination of these matching techniques with each able to address a particular class of data matching.  A single technique, such as probabilistic, will not likely be able to find all valid match candidates, or worse may generate false matches.

Mistake #8:  Underestimating the importance of creating a golden record

For MDM to be successful within an organization, it is not enough to simply link identical data with a registry style because this will not resolve inconsistencies among the data.  Rather, master data from different sources need to be reconciled and centrally stored within a master data hub.  Given the potential number of sources across the organization and the volume of master data, it is important that the MDM system is able to automatically create a golden record for any master data type such as customer, product, asset, etc.  In addition, the MDM system should provide a robust unmerge functionality in order to rollback any manual errors or exceptions—a typical activity in large organization where several data stewards are involved with managing master data.

Mistake #9:  Overlooking the need for history and lineage to support regulatory compliance

Today, business users not only demand reliable data, but they also require validation that the data is in fact reliable.  This is a challenging and daunting undertaking considering that master data is continually changing with updates from source systems taking place in real-time as business is being transacted, and while master data is merged with other similar data within the master data hub.  The history of all changes to master data and the lineage of how the data has changed needs to be captured as metadata.  In fact, metadata forms the foundation for auditing and is a critical part of data governance and regulatory compliance reporting initiatives.  As a result, and because metadata is such an essential component of MDM, it is important that your RFP defines the need for history and lineage.

Mistake #10:  Implementing MDM for only a single mode of operation: analytical or operational

An enterprise MDM platform needs to synchronize master data with both operational and analytical applications in order to adequately support real-time business processes and compliance reporting across multiple departments.  In contrast, CDI and PIM solutions are most often implemented at the departmental level with the objective of solving a single defined IT initiative such as a customer relationship management migration or a data warehouse rollout.  These deployments will typically only synchronize data back to either operational or analytical applications but not both.  Without the ability to synchronize master data with both operational and analytical applications, your ability to extend the MDM platform across the organization will be limited.

MDM Success Begins with Selecting an Integrated and Flexible MDM Platform

Once your organization starts to make its departmental master data management projects operational, you will find that your larger enterprise requirements will expand to include other business data types and other lines of business or geographies.  Therefore, it is important to first seek out and evaluate an MDM solution that adequately addresses these ten essential MDM capabilities.  It is also important to assess the MDM platform’s ability to support these ten core capabilities out-of-the-box, as they should be integrated components of a complete enterprise-wide MDM platform.  In this way, you will be able to mitigate technology risk and improve your return on investment since additional integration and customization will not be necessary in order to make the system operational.  Another benefit gained by having these ten MDM components integrated within the same MDM platform is that software deployment is much faster and easier to migrate over time.  Finally, it is wise to check customer references to evaluate their enterprise-wide deployment and to ensure that the vendor’s MDM solution is both proven and includes all ten enterprise MDM platform capabilities.

By including these critical MDM requirements in your RFP you will achieve greater success with your MDM initiative along with a more rapid deployment and faster time to value.  Not to mention, a well thought out RFP will allow you to quickly reap the returns from selecting an integrated and flexible MDM platform that is able to address both your current and future business requirements.

About the Author

Ravi Shankar is Director of Product Marketing at Siperian, Inc., an innovative provider of the most flexible master data management platform.  For more information, contact the author at rshankar@siperian.com or visit www.siperian.com.

Join Gwen Thomas, Founder and President of The Data Governance Institute, and and Cliff Longman, CTO of Kalido, for an insightful live Web seminar to review the growing issue of “bad data” within organizations, hosted by Computerworld.

Topics will include: Introducing Master Data Management – understanding why CDI-MDM must be a part of business and IT strategies for an organization; Key factors for a successful adoption and implementation; Data integration and data quality: Infrastructure for CDI – DMD; Maximizing ROI in MDM; and Evaluating the MDM strategies for 2009 – 2010.

Speaker:  Larry English, Information Impact International.

In this roundtable we’ll look at the concept of MDM, and how an enterprise can leverage best practices in MDM to improve data management going forward. Instead of a marketing presentation, we’ll hear from key analysts and key vendors in this space who understand which and what MDM approaches and technology are working, and which are not. Moreover, our experts will provide you with a step-by-step approach to MDM, including how to understand your own requirements, identifying your own issues, and applying the appropriate technology.

Deb Cobb

Trillium Software

Product Marketing

Both Gartner and Forrester Research say that fewer companies are planning large IT initiatives in 2009 due to the “climate of uncertainty” – corporate-speak that acknowledges early that revenues will be down since everyone has less money to spend.

But a tumultuous business climate can reveal interesting trends. For example, the global economic downturn has incented many organizations to consider how the caliber of the data that populates MDM solutions impacts the soundness of their high-cost investment.  Better data quality equals better information available for user consumption. Current market dynamics validate that data profiling has emerged as a key activity in MDM readiness, and for that matter, the readiness of any data integration initiative, such as CRM and CDI.  Profiling is not only essential for the usual technical reasons, but it is also required for the people associated with the MDM project. There are several reasons for this.

First, it’s always important to understand what you have so you can evaluate the feasibility of attaining your goal.  In data integration projects, there are numerous source data systems containing data that needs to be “assessed for use” so stakeholders can understand how well the data will support project goals. Assessing the condition of data in these source systems is a critical first step to knowing what data is available, its structure, its level of accuracy and completeness, and its consistency, because all these factors impact the scoping phase of the project. For example, if you decide to include product data in your master data view, you need to know what product data is captured in your source systems. Because profiling reveals known data issues, it helps users understand exactly what the high-level problems are and what the data looks like by revealing anomalies, input errors, duplicate values, and the level of record completeness. Profiling provides insight into the level of work required to get the data consistent and migrate it to the target MDM and lets the project manager assign appropriate resources to remediate data issues and improve data quality.

Profiling can confirm suspected data issues, such as when an application is not aligned to a business process or the use of different standards across different systems. These issues can have a huge impact on project milestones.

Automated profiling is even more powerful in that it evaluates the data in ways that user-generated queries may not have anticipated. Automated, out-of-the-box profiling can reveal unexpected data issues that users never considered. These are usually the more in-depth quality issues that dramatically increase risk, such as problems related to using data in ways it was never used before. For example, meter readers using handhelds at a large Midwestern utility indicated danger by typing “Large Dog in Yard” (LDIY) into the address field of their meter-reading application. This acronym posed a safety feature and was understood by new meter readers. When data was migrated from the meter reading application to the customer contact system, however, LDIY was the fodder of several discussions before its meaning was deciphered.

The point here is that data is not only a strategic asset, it’s a shared, enterprise asset – shared across systems and applications. Organizations need to understand current data condition to determine if it will support defined master data goals and to assess its impact on the downstream applications that will consume it.

For many companies, an MDM solution will deliver the definitive, 360 degree, master view of data. In this regard, the objective of any MDM effort is to deliver trusted enterprise data. For that to happen, companies need to delve deep into existing process to ascertain what people, systems, and applications access and/or consume the data. This is where data governance comes in. Data governance is a business strategy based on a best-fit process to optimize data value over its useful life. Data governance practices vary across companies based on their level of maturity, business priorities, MDM goals and internal competencies.  But all data governance strategies should involve a best-fit combination of process, policies, and standards that improves and maintains accurate data over time. Companies considering MDM need to define a data governance approach that protects their investment. 

Data assessment is an integral part of data governance. Companies need to understand how business process effects data condition at specific points along the data quality life cycle. Effective data governance strategies carefully manage the delicate interaction of various roles and responsibilities and deliver a roadmap that details how employees will collaborate, identify and remediate data quality issues, and maintain data consistency over time.  Because MDM project teams have multiple roles, each requiring different skill sets, it may be helpful to understand how these roles interact with data during a typical MDM project.

Prior to project kick-off, Business Stewards are charged with assessing data condition, information required for project scoping, planning, and risk assessment. They use this insight to determine if data will support project business requirements and make decisions about task duration given the now known data issues. This information also helps them allocate resources and budget to ensure project success. 

Because business users understand how data is created, its use, data nuance impacts on business requirements, and data presentation requirements, business community input is critical in all MDM initiatives. Business insight and feedback add significant value early in the project to advise about project design, needs, and priorities.

During project design phases, Business Stewards perform more detailed data assessment that includes source investigation.  This knowledge influences detailed design and process recommendations, because users focus on data value accuracy, validity, and consistency.

IT Stewards perform technical profiling during design project phases that focus on data structure, schemas, relationships, and transformation requirements. Technologists tend to focus on data flow, models, and formats.

Data Stewards and Governance Teams play a role in MDM and the day-to-day activities that measure and monitor the data over time once the MDM solution is in production. They consider what the data quality standards should be and identify impacts on downstream systems.  Their concerns span wanting to know if the data is degrading over time and develop  appropriate metrics to measure overall data “health.” 

Although Executive Management never wants to be involved in daily details, they often are interested in MDM results and performance metrics so they can evaluate how to align company resources with identified issues.  They want to know which issues are priorities and which may require process changes in a different part of the business.

Profiling not only supports all the aforementioned roles and responsibilities, but it promotes the sharing of data quality information between business and IT functions in support of data governance. For business users and business data stewards who understand the business use of data, profiling provides contextual data quality information, such as whether relationships within the data hold true and whether business defined data rules are supported by the data. Not only does this provide greater depth than profiling alone, but for data governance and MDM initiatives, it provides critical insight into how well the data can support current and planned business initiatives.

Clearly, every functional area outlined above benefits from using a unified platform that automates many profiling tasks, delivers a consistent data view, promotes collaboration around data quality, enables communication to remediate identified data issues, enforces corporate policies and standards, and monitors data quality trends and condition over time.  This is the role of technology in the grand scheme of profiling and data governance—the ability to “bring it all together” seamlessly and transparently.

In a world where acronyms seemingly spring from thin air, MDM (master data management) has evolved from being just another acronym into a necessary business solution for industries such as healthcare, financial services, hospitality, public safety, retail and technology. MDM addresses problems that increasingly plague businesses as they struggle to manage ever-growing silos of customer data – problems such as data integrity, customer service issues and missed revenue opportunities.

To many businesses, data can be both a blessing and a curse. Data provides an opportunity to better understand customers and improve service and revenue opportunities, yet data is costly to integrate and difficult to manage. Nearly every business has customer data scattered across multiple databases – for members, call centers, online access, financial tracking and more. Each database often stores data in its own distinct format, which can be different from the format of the same data located in other databases.

These problems are compounded through mergers and acquisitions, as well as when new customers are added or divested. Additionally, as online accessibility has increased, so too has the ability for existing customers to create new profiles that may duplicate existing records. Companies know that there is overlapping and incomplete data, but most have been largely unable to find a solution to this problem at a cost they can afford. The result is lost revenue, missed cross-sell and up-sell opportunities, inadequate customer service and inaccurate business analytics. An incomplete customer view becomes increasingly problematic as customers grow to expect more from the companies with which they do business.

A Look Back

In the late ‘90s, complex customer relationship management (CRM) systems were developed to extract and consolidate customer data from company databases and centralize it. While well-intentioned, CRM created its own array of problems. These systems required very complex infrastructures and architectures, and featured technology that was unable to keep up with the pace of constantly shifting business processes, changing competitive pressure, and ongoing acquisitions, divestments and upgrades that continually altered customer data. The resulting CRM outcomes rarely delivered on their promised ROI.

Some of the reasons for CRM shortcomings were based on its own inflexibility in determining how customer relationships could be managed. The CRM often could not present a single view of a customer because the system determined how that information was managed – not the business.

MDM addresses this by combining a complete, accurate real-time view of customer data with flexibility not inherent in CRM systems. MDM, therefore, provides a data foundation for CRM and other customer relationship initiatives, while allowing each business to manage its customer relationships uniquely.

MDM at Work

MDM enables and integrates the processes that manage customer data, while matching and linking records across systems. An MDM solution complements and extends existing systems and processes, allowing an organization to take advantage of its customer-facing interactions. As a result, businesses can leverage previous capital expenditures on legacy systems while gaining a better and more complete view of their customers. This complete view can then help increase revenues and strengthen customer interactions.

For example, companies often interact with the same customer on the phone, in person, and via a website. For a large company that sells several different products, this often leads to cases where a customer will have three or four (or more) individual records in a system, each perhaps with different credit card numbers, privacy preferences or contact details tied to a product purchase.

In this scenario, when a customer calls for support, an MDM system matches and links all records to present a complete, integrated picture of all products purchased and the customer’s entire relationship with the company. This enables the person answering the phone to offer the appropriate support while also leveraging relevant cross-sell and up-sell opportunities. To entice customers to make future purchases, a call center representative could also offer discounts on related products or send an e-newsletter to the customer touting new versions and features. These examples represent how greater customer knowledge can tailor the relationship and result in more valuable benefits.

MDM Implementation: Flexibility in Choices

Because MDM is a technology that can be integrated into an existing architecture, customers can choose how – and how much – to integrate. There are three distinct styles of MDM, which address different organizational structures and requirements. These styles include registry, transaction and coexistence. Each is discussed in detail below, including the strengths and challenges of their approach.

Registry style
The registry style of MDM matches and links data from disparate systems to provide a single view of the pertinent data about an end user without requiring organizations to build a centralized data repository.

The registry style is often used when an organization has multiple lines of business (LOBs) using different systems to manage their data, or if an organization must abide by regulatory or business requirements that do not allow data to be centralized. Businesses that have gained new data sources through mergers and acquisitions often start their MDM experience with a registry style hub, sometimes with an eye toward moving to a transactional hub down the road. A registry hub offers organizations a way to start seeing some ROI from MDM without making a significant investment in re-engineering, and without significantly disrupting the individual lines-of-business.

In a registry hub, data are “owned” by each contributing source system or database and maintained at the line of business level. Registry systems do not require data to be standardized to a common format, which makes installation relatively simple. The software taps into existing data flows and processes while avoiding data re-modeling disagreements and complex architectures.

The most critical component of a registry system is its ability to maintain synchronized data between the hub and source systems. Synchronization can be achieved by mimicking or mirroring familiar source-system processes: real-time updates, message processing, nightly batch updates, etc. A registry hub can handle hundreds of disparate source systems that have widely varying methods of data capture and architecture with no standardization required.

A registry approach is the least intrusive MDM style, since data owners remain autonomous and retain the responsibility for the maintenance of their data.

Many registry-style hubs also support a federated model. In this scenario, the data maintained in external source systems can be retrieved on demand by an enterprise user. This could be for the purposes of creating an up-to-the-minute calculation of a customer’s liability, for example, by retrieving current account balances for that customer from all sources. A registry model offers companies the flexibility to pick and choose which databases should be included and the ability to add or remove additional sources as needs change over time.

Simplified installation for the registry model provides a rapid ROI at the enterprise level, and lets users achieve their biggest, most pressing goals: gaining a better understanding of their customers and enabling an array of analytics without disrupting LOB operations. With better intelligence, businesses can re-engineer their processes for further ROI, still with minimal disruption.

Transactional style
A transactional hub sits at the other end of the spectrum from a registry model. It is often seen as the “big bang” approach or the end-goal to an MDM project. Many companies start with a registry hub to realize rapid ROI, but slowly rework their business processes with the goal of moving data into a central transactional hub.

Large organizations with homogeneous systems and processes that have a need for near real-time analytic information about customers and their activities often deploy transactional systems. They are common in manufacturing, financial services and other industries where companies typically have a large number of suppliers and customers.

Organizations seeking a unified strategy and business plan use transactional hubs to create a centralized, single view of customers and relationships, which might also include organizational hierarchies and other critical customer information. Transactional hubs allow companies to easily analyze sales information and quickly react to changes in the market.

A transactional hub is created by integrating customer data from multiple sources and storing them in one centralized hub to create a single, master version of customer information for the enterprise. As a result, the hub presents the same consolidated view of a customer to all users, with no need to reconcile different types of information from different databases. Since there is one centralized ‘source of truth’ in a transactional hub, the data management requirements of LOB systems are reduced and the availability of enterprise-wide data for analytics is assured.

There are two main phases involved in deploying a transactional hub. The first is to centralize data into a single hub, which usually requires some sort of data integration activity along with harmonizing to a common customer data model. The second is to re-architect all systems or business processes that work with customer data so that each requests customer information from the transaction hub in the same way; each system or business process interacting with a transactional hub must also model customer data in the same way, and work with that data in the same format.

There are a number of benefits to a transactional hub, including:

·         the ability to enforce standards required to maintain enterprise-wide data quality, since there is a centralized single function in place to correct and update data

·         the ability to make data available with no latency to all business users and systems throughout the enterprise

·         streamlined support for business analytics. Because all customer data is centralized, integrated and available in one location, the need to get data from source systems is eliminated.

While the benefits of a transactional hub are attractive, organizations considering this type of MDM implementation must realize that a transactional hub requires extensive re-architecting and standardization of both data and processes. This may contribute to higher costs and significantly longer implementation times than the registry style.

Co-existence or hybrid style
The third type of MDM system, a co-existence hub, is a hybrid or mid-way point between a registry and transactional style. A co-existence hub rests on a centralized database but also matches and links records from other outside sources. This combination serves to harmonize data across sources to provide a central reference.

The centralized database often contains attributes that remain the same across systems - such as customer name and address - but links to other databases to supply information about products purchased or support calls. It retains the single place to go to get centralized customer information, one of the elements that makes a transactional hub so appealing, but also enables individual LOBs to retain ownership of their data and, as necessary, make sensitive data unavailable to the central hub.

Some organizations will choose a co-existence style so that an MDM system using a centralized repository can successfully maintain customer information, yet still allow certain source systems to maintain ownership of and use their own customer data, even though they are also providing customer information updates to the centralized MDM hub. This scenario is common in organizations that ideally want a centralized transactional style, but are growing through acquisition and thus need to bring new products and customers on board while supporting seamless and efficient merger activities.

A co-existence hub is often a transition point within a business’ MDM evolution. If an organization starts with a registry style hub and begins to see significant ROI, a co-existence hub allows for an easier migration to a transactional hub. To succeed with a co-existence model, businesses usually re-engineer some processes and then examine additional processes and data flows separately to make the necessary adjustments on their own timeline. A co- existence style also allows source systems to be added to the central hub as they are ready, rather than adding them all at once, which is the requirement of a pure transactional hub implementation.

Core capabilities essential to MDM success
As businesses create more data about customers and potential customers, they move farther from a single, complete view. Data silos traditionally prevented information about a customer in one database to be linked to information about the same customer in a second database. Master data management solves this problem by matching and linking records across databases to provide a single, complete view of a customer or prospect.

Although one business may opt to test ROI with a registry style implementation while another moves to a transactional hub approach from the beginning, the end results will be the same. Regardless of the style used, there are certain universal benefits that an MDM solution provides.

When choosing an MDM solution, make sure it provides the ability to:

• Recognize the right customer. This is the core focus of an MDM implementation and is imperative to the project’s success. An MDM solution must be able to identify and accurately render all of the customer’s data, despite incorrect or incomplete data, in order to improve customer intelligence and analytics.
• Deliver customer data, throughout the enterprise, in real time. An MDM solution that allows latency in data updates will fail to report a customer’s most recent transactions. To deliver the service that customers expect, real-time recognition is a must. MDM solutions must also allow for batch updates from certain legacy systems, such as a nightly update of newly invoiced customers.
• Provide the flexibility to support all customer source systems, attributes and use cases. An MDM solution may support all systems currently in use, but may not be capable of supporting future systems. As needs evolve, different source systems will likely be added or upgraded and new data attributes may be required by legislation or best practice. An MDM system must have the flexibility to accommodate businesses as they grow and evolve, without excessive customization or painful data migrations, which can increase costs and implementation time.

The three styles of MDM each offer their own capabilities and advantages. When deciding which is best for your organization, consider your overall timeline and goals. If you want to test the MDM waters and prove ROI before going deeper, the registry style can provide you with a minimally disruptive way to improve your business intelligence and make valuable process changes. From there, a co-existence style hub can bridge the evolution towards a transactional hub that will provide a true customer master. In any case, an MDM solution vendor should have the experience and expertise to help your business provide a complete, real-time view of your customer or prospect on demand, enabling a wide variety of benefits that can help your business grow and thrive. The different approaches to MDM allow you to manage this evolution at your own pace, on a timeline that meshes with your strategic goals.

About the Author

Dr. Scott Schumacher serves as chief scientist at Initiate Systems where he is responsible for R&D of Initiate Systems’ matching algorithms. Initiate Systems, Inc. is the leading provider of MDM and enterprise master person index (EMPI) software for companies and government agencies that want to create the most complete, real-time views of people, households and organizations from data dispersed across multiple application systems and databases. For more information about Initiate Systems, please visit www.initiatesystems.com.

Technical Overview: Initiate Master Data Service™ Platform

Executive Summary:

Truly knowing – and trusting - your data empowers you to achieve an array of initiatives. Initiate Master Data Service enables enterprise-wide master data management (MDM) with several strengths, including:

·         High volume matching and linking via high performance data processing and scalable infrastructures

·         Integration through leading-edge middleware technologies

·         Tools that enable data stewardship, enterprise search, configuration and performance monitoring

White Paper: Laying the Foundation for Customer Data Integration

            Executive Summary:

Accurate and complete customer data helps increase revenues, improve profitability and optimize business processes. Customer data integration (CDI) emerged to meet these goals by delivering accurate customer views. Learn:

·         The evolution of CDI as an answer to CRM’s limitations

·         Three styles of CDI - transactional, registry and co-existence - and their strengths and uses

·         How to lay the foundation for a successful CDI implementation

Podcast: “Where to Start in Master Data Management”

Marty Moseley, Initiate Systems’ chief technology officer, encourages you to go after something that matters to your enterprise. In this segment, you’ll learn about some common questions you might ask while choosing an area for your first MDM deployment:

·         Identifying Outside Constraints such as Regulatory, Customer, or Supply Chain pressures

·         Identifying Areas of Cost or Risk that Impact your Business

·         Identifying Opportunities for doing something that shows value to a broad segment of your enterprise

There is consistent growth in all types of MDM approaches and philosophies including registries, repositories and transaction hubs. Each approach to managing master data has its merits. The real issue is matching the MDM approach to a company’s organizational maturity and the business value required of the data at that life stage. An important aspect for any company to consider when it adopts technology is whether the desired solution is flexible enough to meet immediate needs and able to scale and transform over time to meet future needs. Flexibility and connectivity to source applications is key here.

A realization is resonating throughout the market. Companies are coming to understand that a profound issue skirts the edges of discussions relating to which MDM approach or philosophy is best suited for them. That realization relates to the nature of the data that will populate the MDM implementation itself.  MDM efforts are expensive, time-consuming, and labor-intensive. Companies want to understand what data they have to begin with and the overall quality of the data that will be migrated to the MDM.

We are also witnessing the birth of a new MDM driver: an awareness of “unaccounted for” risk and the dangers it represents. Due to the current economic climate, investors and regulators are demanding greater transparency and visibility into the financial disclosure process for large companies, especially those in the financial services sector. Unaccounted for risk has felled Wall Street titans, such as Lehman Brothers and Bear Stearns. For the companies that have survived, financial institutions and insurance companies alike, there is a swelling aversion to risk that is spurring these enterprises to embrace the concept of “data hubs.”

Financial service and insurance enterprises are sizeable companies that have patchworks of systems distributed all over the country. These systems are truly data silos with no automated process to reconcile and validate data related to risk exposure. So these firms employ teams of MBAs who sift through reams of system data to relate risk factors in manual processes. The result is that differences in data standards, formats, accuracy, naming conventions and completeness between source systems and applications require human interpretation of data significance and hamper accurate reporting and business intelligence.

By deploying data hubs, companies could establish a central repository to manage core master data – all information would be published to or updated from the hub. That, however, is the challenge. For a successful data hub implementation to happen reliably, all source systems must be modified to publish to and be updated from the data hub—a cumbersome, expensive, time-consuming, and daunting task.

Rather than jump head-first into the MDM process, many companies we speak with are choosing to get their toes wet by first tackling a huge issue: data quality. Companies that strive to dig into the real details of the data that drives their business and risk rating models, key performance indicators, and decision-making seek provably correct data based on verified facts. Master Data Management systems can improve data consolidation and make the viewing of customer and product information easier, but if the underlying data is inconsistent, incomplete, inaccurate, or error-prone, all business decisions based on that data are at risk. Widely held beliefs that data and information is correct foster false confidence in decision-making, and the intended results of those decisions are never achieved. As a result, these companies are looking closely at the current state of their data (using best-of-breed automated profiling and investigation tools) and ways to improve it. These strategies often begin at the project level with a charter to scale enterprise-wide within specific time frames.

This ties into what we think is the biggest challenge facing companies that are moving forward to implement MDM: data governance. Implementation and integration issues can be resolved from a technical perspective, but data governance is a business strategy based on a best-fit process for every enterprise that optimizes the data over its useful life. The actual data governance plan will vary from one company to another based on its maturity, individual needs, goals and internal competencies.  The demands of data governance will swiftly confront any company exploring the benefits of MDM, because the investment to create master data is so intense that companies acknowledge they need to set up processes to improve and maintain accurate data over time.  Clearly, to be successful, data governance initiatives need to involve people other than just IT, including the business users of the data and executive management. Involving users cross-functionally requires a cultural paradigm shift in many organizations.

In many cases, then, while there is a desire to “go big” with MDM and consolidate all instances of the same concept into a single unified view, the effort involved may exceed the appetite of those doling out the budget. This scenario recurs across the case study landscape, with the premise that one should start out small on the MDM program, either concentrating on one small data set (perhaps reference data) used in the organization, or (and this is a more likely situation) on consolidating one master data object type from a subset of the business applications. This can be contrasted to “going big” by selecting a single master data object type, seeking out all applications that create, access, or modify instances of that master data object type, and formulating the master environment in your architecture of choice.

MDM might be motivated by tactical drivers or strategic drivers. If MDM is being driven purely by operational efficiencies, then there are likely to be quantitative measures for evaluating whether operating expenses are reduced as a byproduct of the unified view, and this may ultimately suggest starting small and making incremental changes. If MDM is strategic, then progress may be measured by quantifying organizational change and maturity, and this might suggest that starting small may take away from reaching the long-term goals.

Starting small does have some benefits – there is a limited set of stakeholders from whom buy-in is required, there is not as much need for enterprise-wide standards and collaboration, and consolidating two data sets is fundamentally simpler than consolidating many of them. On the other hand, realize that incremental adjustments require incremental actions, and there are some other expected impacts as well. For example, the more we “consolidate,” the more likely we are to lose critical differentiating information associated with each source application. In addition, continual unification of business rules associated with the creation of data introduces additional specifications and environmental challenges in adjusting existing legacy application to conform to downstream expectations that were never aligned within the specific line of business that is creating that data – this leads to the perception of additional work in the absence of added value, organizational conflict, stonewalling, and other behavioral idiosyncrasies.

Yet, demonstrating incremental value does provide some collateral for additional business buy-in, and that is always a good thing, so the answer to the question is a combination: Plan big and strategically, identify key measurable tactical, operational, and strategic benefits, plan tactical phases that contribute to the strategic end-game, and execute against short-term expectations. An example of doing this might be instead of grabbing two data sets and throwing them against the data integration tools to create a third merged data set, consider planning a master data model that can accommodate the union of all instances of that master object type in the organization, but then migrate a small number of data sets into that master model.