Keep Your Eye on the Enterprise:

Developing a long-Term

master Data management strategy

For business decision makers, there is perhaps nothing

more troubling than realizing that you’ve painted

yourself into the proverbial corner as the result of earlier

decisions. What do you do when further progress will

either complicate or undo the groundwork you’ve

carefully laid—and often at considerable expense?

many life sciences companies find themselves in this unfortunate situation when it comes to their systems for managing their master data—information on customers and products that’s used by multiple functions in the organization. given the cost and complexity of developing an enterprise-wide solution, they’ve allowed spot solutions to proliferate function by function, only to have integration issues later on.

However, companies need not be forced to choose between an expensive and powerful enterprise tool that they don’t yet need and functional solutions that won’t scale later on. With proper forethought and careful planning, they can ensure that their mDm solutions solve their immediate needs and build toward what they’ll need in the future.

setting a master Data management (mDm) strategy for a life sciences company is one of those

responsibilities that largely goes unnoticed by downstream information consumers—that is, unless it was shortsighted or overly ambitious. adopting an enterprise-wide solution that isn’t agile enough may leave some users frustrated as they stand in line for their unique needs to be addressed. yet, allowing functions to choose their own solutions could lead to incompatible systems that are at odds with the very purpose of mDm: having a single version of the truth for a customer, a product or any of the mDm domain records. so how do you choose between an enterprise-wide solution and those that are specific to individual functions? is it possible to start with tools at the functional level and “grow into” an enterprise system? Can multiple mDm solutions “peacefully co-exist?” When should an organization make the leap from single-purpose systems to a broader solution that’s standardized across the company?

Here we’ll offer our views on how life sciences companies can think strategically, preparing for the long term, and act tactically to satisfy local and immediate needs when developing their mDm systems. spoiler alert: the key is to understand where your company is headed and create a “road map” that will guide you along the way, ensuring that any tools created for a single-use case can be integrated later on. Decisions made today will not need to be countermanded tomorrow if they’re made with all of the right future considerations.

Functional vs. enterprise solutions

“Functional mDm solutions” are those that are designed specifically to satisfy the needs of a particular business function—for example sales (or even a specialized sales force) or managed markets or compliance. They are, by definition, limited in scope and geared to a specific purpose. in contrast, “enterprise mDm solutions” are those that serve multiple company functions simultaneously, and they may even be common across geographies. They are powerful, complex and comprehensive systems, yet difficult to modify or upgrade once they are in production.

FUNCTIONAL SOLUTIONS

Because functional mDm systems address more focused needs, they don’t need a great deal of processing power and are less expensive to create than systems that must address the diverse needs of multiple stakeholders. They are practical, fit-for-purpose solutions, so they don’t automatically include features and utilities that aren’t needed. Typically, they require only a limited amount of configuration and can be up and running in a fairly short timeframe, providing quick “time to insight” for the specific functional team.

small and emerging companies may turn to separate functional mDm systems before they are ready or able to move to an enterprise system. alternately, in large companies that have installed enterprise systems, a functional system may simply be an easy way to meet an individual group’s needs quickly and painlessly. a new business unit or a new sales force may, for instance, need an mDm solution but be unable to wait until iT is able to incorporate its specifications into the existing company-wide solution. many of today’s functional mDm systems within the life sciences industry have sprung up in just this situation. even though the

company has invested in an enterprise system, there remain pockets of underserved master data users within the organization that cannot wait for the company-wide tool to be configured for them.

For all their benefits, functional solutions have three potential drawbacks. each can create a serious problem that can be expensive and time consuming to fix, but they are all avoidable with the right structure and technology. The first possible issue is that companies run the risk of outgrowing the functionality of their selection; the tool itself may not be robust enough to adapt to broader uses and more complex types of

data as users’ requirements grow. The second is that separate systems can, if not governed properly, quickly spawn multiple, conflicting records for the same entity. When this happens, there is no longer anything “master” about the data and the information can no longer provide a “single version of the truth.” and third, inevitably, a functional solution will need to share or receive information from another functional system, and thus begins a spider web of complexity that many companies can’t maintain over time.

To summarize, functional solutions are sufficient when only limited scope is required. However, even then, they must offer an upgrade path to more advanced features and broader application—at a price point and implementation timeframe that remains in line with the original intent of the functional solution. if by upgrading a functional solution it will become costly and unwieldy, you would have done better to have chosen an enterprise-wide solution at the outset.

ENTERPRISE-WIDE SOLUTIONS

solutions designed to serve multiple stakeholder groups are, naturally, more time-consuming to design and implement because they must address so many different downstream users’ needs, all in one. imagine the complexities in having to gather and satisfy user requirements from sales, sales reporting, marketing, speaker management, managed markets, the call center, compliance, finance, operations, and research. it is very difficult, organizationally, to reach the consensus required to design an enterprise-wide system.

The underlying technology for such systems, of course, needs to be powerful, flexible and capable of managing massive amounts of information. Typically, these systems are highly configurable and include a wide array of capabilities in anticipation of nearly every conceivable demand. in that respect, they are the “aircraft carriers” of the technology world.

While enterprise-wide systems can be more time consuming and costly to implement—a process that can take months or even years to complete—companies can realize savings in integration efforts and ongoing maintenance because the support team can be consolidated. Because they need only maintain one tool, companies can develop a center of excellence in the skills required.

on-premise vs. Cloud-Based solutions

There are several options for the technology platform that supports an mDm system—whether at the

functional or enterprise-wide level. it can reside on premise, as it has been done historically, or “in the cloud,” meaning that it is accessed via the Web and computing resources are available on demand with pay-as-you-go pricing.

The advantages of a cloud-based solution over an on-premise solution are the same in mDm as in other popular cloud-based offerings. Briefly, they include:

•

lower start-up costs. subscribers do not need to invest in software, hardware, data centers, disaster recovery, redundant systems, or iT staff.

•

Faster implementation. mDm as a service takes advantage of immediately available infrastructure.

•

ongoing savings. When the mDm software is purchased as a service (saas), the license fees associated

with on-premise solutions are eliminated.

•

automatic enhancements and upgrades. The service provider makes improvements as needed, without

having to push out new releases sporadically that lead to significant disruption and downtime for users.

•

Usage-based pricing. as with utilities, subscribers pay for only the services that they use and do not incur

costs for capacity and features that they simply don’t need.

•

scalability. Cloud-based applications can be scaled up or down as needed. The solution maintains performance levels while delivering new capabilities.

•

painless upgrades. saas solution providers must invest in keeping up with industry changes and in providing a solution that keeps subscribers current. all updates and upgrades are provided as part of the service; there are no patches or hot fixes to install … and no need to worry about the loss of support from a license expiring.

•

accessibility and security. saas solutions are available via a browser and secured behind unique user credentials and encryption protocols. Thus both remote and in-house users have connectivity to the system while corporate intellectual property is protected.

•

simplification. a saas application leverages industry-standard practices, which translates into less complexity across integrated commercial systems.

•

strong support. saas solutions are usually a center of excellence for providers, offering highly trained support resources for which the costs are spread across multiple clients.

making the Choice

There is no automatic right or wrong answer as to which type of mDm system (functional or enterprise) is best in any given situation. it depends on a number of factors:

•

What types of data are involved, and who needs access to them? Does one function, such as Finance,

need to perform analyses on data drawn from across the organization? or, do multiple functions need access to the same information—such as product reference data? in these cases, the database may require global management, arguing for an enterprise-level solution. (an exception might be if a company only has a small number of products, in which case it may not need a product reference hub just yet.)

or conversely, does the information pertain to a unique customer universe, such as oncologists who are of interest only to the oncology sales force, for example? in such a case, functional mDm may be a sensible solution.

•

Does the company’s strategy require a 360-degree view of the customer? When a company decides

that everyone with customer contact should be privy to all interactions with a given customer, the system must be powerful enough to provide commercial teams with a comprehensive customer record. Until such integration is necessary, it is quite possible to make do with functional solutions—provided that they follow certain design and governance principles as discussed below. (note: a single, 360-degree view of a customer does not preclude different users from looking at a given customer differently, based on their functions. For instance, the same physician may be of interest to research and sales, but the individual attributes that are important to each group may well be different.)

•

Are there efficiencies to be gained by adopting one system? admittedly, it is difficult to calculate the

return on investment from implementing an enterprise-wide mDm solution because the benefits are realized downstream by various users, not by the mDm team itself. even so, there often comes a point when it becomes too costly and cumbersome to manage and maintain data with different tools using different matching rules. Companies can also realize efficiencies by storing and managing using one tool with one support team.

•

How much rigor is required to support data quality? Typically, supporting an mDm solution does

not require a consistent level of resourcing. There are peaks and valleys with respect to special projects and data stewardship workloads that require flexibility in resources. By its nature, an enterprise solution should be capable of providing support for planned spikes in workload to ensure that negotiated service levels are attained consistently.

•

Are acquisitions, mergers, or co-promotions part of the business strategy? strong practices related

to reference data management are critical for organizations that must support acquisitions, mergers, and even co-promotions. Customer, activity, and sales data must be aligned with outside parties to ensure required synergies. in one case of a merger of two large pharmaceutical companies, the capabilities provided by one company cut the time to commercial integration of the sales teams by over 60 percent, thus setting a new industry benchmark for integration excellence.

There is no automatic right or wrong answer as to which type of mDm system

(functional or enterprise) is best in any given situation.

recommended practices

Companies can avoid the perils of going down the wrong path by following certain guiding principles in how they select and design their mDm systems. By following the recommendations below, companies can make any combination of functional and enterprise-wide systems work in the short and long term:

•

Take a long-term view

Companies should have a clear idea of the type of system they will want and need at least five years from now. Figure 1 illustrates the type of broad map that can guide choices. it is, in fact, safe to assume that in time, all successful companies will want and need an enterprise solution. They need not start there, but they must plan for the fact that their data and technological needs will almost certainly become more complex and more intertwined over time. Having this as an end goal will dictate certain decisions along the way and make the eventual transition to an enterprise system smooth. Companies can be guided in their journey by measuring their progress against an mDm maturity model.

if a company’s immediate needs can be met with a functional solution, the strategy and platform can be provided through an mDm as a service solution. This approach will permit the eventual growth to an enterprise solution with minimal pain and effort.

FigUre 1: THe ToUCHpoinTs oF enTerprise mDm

DATA GOVER_NA NC_E DATA ACCESS Master Data Field

Force CenterCall ProgramsSpeaker E-Detail E-Sample Customer Channels

Direct

Mail Convention Web

Reports Aggregate_Spend Supply Chain Managed Markets Compliance Finance Market Research Marketing Sales

KPIs Customer_Segments Campaign_ROI Business Intelligence Organizational Transparency Brand Planning Travel & Expense Speaker Programs Segmentation & Targeting Incentive Comp Campaign Mgmt Operational Customer

Analysis AnalysisMarket StatisticalAnalysis

Analytic Insights Sales Data Customer Interactions

•

Rely on a single, base source of industry data.

Having a single source for customer and product reference data as a common underpinning is what enables separate, functional mDm systems to speak to one another today … and then be easily integrated into an enterprise-wide system tomorrow. even separate systems should all start with the same basic profile information and use common definitions and identifiers. external sources can be supplemented with internally sourced data as needed. Companies that have opted to integrate multiple industry reference sources have found it very difficult to manage the conflicting updates and definitions that exist across sources.

•

Keep MDM processes and technology separate from the applications that will use master data.

it can be tempting to build an mDm system within an operational application (such as a data warehouse or a customer relationship management system or a financial system). But, what on the surface may seem like a natural fit can actually be quite problematic. This is the case because the tool’s layout, data models, and fields are all prescribed by the application, not by the data need. you cannot, for instance, add customer types or attributes that are not important to, or recognized by, the application, no matter how vital they may be to the business operation. additionally, operational mDm systems are usually limited to the customer data that is used by the application and does not facilitate integration of multiple, diverse sources. The rigidity and narrowness of an mDm solution emanating from a functional application limits both the current utility of the system and hinders—if not prohibits—expansion over time.

in contrast, when the mDm system (be it functional or enterprise-wide) is built with open application program interfaces (apis), it can accommodate real-time access from various applications. mDm systems that are built independent of operational applications can expand and change with the organization’s needs, without “breaking” the application itself. in a word, they are nimble.

•

Adopt a common underlying technology across MDM systems.

if different business functions are permitted to adopt mDm systems that emanate from their primary operational applications, multiple technology platforms are bound to spring up within the organization. and that, naturally, creates challenges for maintenance and integration.

The technology platform on which mDm systems are built should integrate seamlessly with the company’s systems and applications such that users can sign in once and move from one application to another. The best architecture centralizes customer data in a customer hub that feeds into multiple back-office systems (such as sales reporting, compliance reporting, compensation, and contracting) as well as integrates with customer-based applications including sales force automation, call center support, order management systems, expense and finance systems, campaign management, speaker programs, websites, and physician portals. (see Figure 2.) The resulting tools all share a common look and feel and can be supported by a common technical team and training resources.

FigUre 2: a CUsTomer HUb approaCH To mDm

SFA/CRM _CenterCall Order Mgt

Customer HUB

Master Data

Management

Website

ERP _ReportingSales Sales Comp Legacy

Physician Portal

•

Establish data governance policies and processes to maintain data integrity.

regardless of whether a company is supporting multiple functional mDms in anticipation of creating an enterprise solution later, or already has an enterprise-wide solution, it must establish data governance principles around the data and its use. These include:

•

standards around data definitions and taxonomy, metrics, and measures

•

policies and processes related to monitoring, measurement, change management, data access,

and delivery

•

Defined roles and responsibilities related to data acquisition, maintenance, and use

such an approach will ensure that there is one true representation (a single version of the truth) of the customer or product that underpins whatever applications may tap into the master data from across the organization.

•

Give careful consideration to the data stewardship model employed.

The quality of master data must be maintained by stewards who are able to make decisions on the disposition of individual data records according to the data governance rules that have been established. The best data stewards are those who work with life sciences reference data for a living and who

thoroughly understand the industry and all of the applications of master data. it is impossible to properly steward data without understanding how different commercial teams engage with customers, the regulations that apply to them, and the industry dynamics they face. indeed, entrusting this work to professionals is one of the key benefits for contracting with a provider for master data management as a service. Companies that do so benefit from the stewards’ expertise and realize faster ramp up time, more timely resolution of data inquiries, and improved data quality. at the same time, they reserve their own business experts for working on the core business functions for which they are responsible.

a company’s data stewardship model can either be federated or distributed. in the former, changes or updates to all data records are made by one set of stewards using one, all encompassing set of business rules. in the latter, they are pushed out to stewards responsible for each functional area, recognizing that it can be very difficult for one set of stewards to understand the needs of each functional area with the depth required. The best structure must be developed on a case-by-case basis, considering the functional areas served by the solution, the complexity of the data and business rules, and organizational decision-making structures. most functional mDm solutions will employ a distributed model, but this model should be based on common standards, policies, and processes across the broader organization.

•

Provide reports to stakeholders on system performance and usage.

The system(s) put in place should be capable of producing reports for stakeholders on the quality, timeliness, and accuracy of the master data contained within them. monitoring this output is an

important step in maintaining data standards as well as helpful when a company is considering moving from a functional mDm structure to an enterprise system. These metrics should be used to measure the performance of the organization’s data governance function.

Companies can avoid the perils of going down the wrong path by following certain

guiding principles in how they select and design their mDm systems.

Upgrading to an enterprise system

if disparate functional systems have been allowed to proliferate without a common, underlying technology, a single data source as the backbone, and strong governance principles, graduating to an enterprise-wide system is infinitely more difficult. essentially, a company will need to apply the seven steps detailed in Figure 3, a significant undertaking. Costs accrue from needing to rework processes, renegotiate with various vendors, adopt new technology, and match and harmonize the data. as a rule of thumb, it is safe to assume that 25-60 percent of the data records from different functional systems will require manual verification during the conversion to an enterprise system depending on rigor of the individual mDm solutions.

The preferable approach is clearly to have a future ready solution that takes into consideration an expanding use case for mDm. Functional solutions built according to the principles above can easily meet this criterion.

FigUre 3: THe seven sTeps oF masTer DaTa managemenT

Master Data Management

BIG DATA SOURCES • Dimensions • Transactions • Relationships REFERENCE DATA • Customers • Products • Procedures • Patients • Client files converted to standardized format • Name, address and other parsed attributes standardized • Exact and fuzzy matching • De-duplication • Augmentation with reference attributes • Create ‘golden’ record • People, process and technology to reconcile gray area matching • Manage data quality • Manual merges • Control what is of value and how it is defined • Workflow management • Operational and quality reporting • Maintenance of cross-references • History of all changes and updates • Standard outbound interface layer • Enable web services for data access and functionality • Role-based visibility and business rules • Systems integration services to enable downstream use of integrated data • Analytical and operational MDM users STEP ONE STEP ZERO Source STEP TWO Load and Cleanse STEP THREE Match, Merge & Augment STEP FOUR Steward STEP FIVE Report and Audit STEP SIX Publish STEP SEVEN Consume

vendor selection Criteria

no matter where you are in your mDm maturity journey and which type of mDm system will best address your needs at the moment, the provider you choose should:

•

Have the ability to both meet your current needs and scale with you as you grow. What meets your needs

today, may not in five years. if you begin with the right foundational elements and work with the right vendor, you can make a smooth transition over time.

•

Be intimately familiar with the master data itself and how it is used throughout the organization.

•

Understand the life sciences industry and the workings and requirements of all the functions within it that have a need for master data.

•

Be iso 9001 compliant. The accuracy of your master file is not merely a matter of efficiency and effectiveness. it is a critical company asset that has strong legal and compliance implications, and its management is a specialized responsibility.

all life sciences companies should assume that, no matter where they currently are in their mDm development, they will eventually want and need a common mDm solution across their commercial

organization. Whether it is for global financial analyses, for varying departments that need a comprehensive view of the customer, or for operational efficiencies, most organizations will at some point want to move beyond functional mDm solutions. This step can be part of a company’s natural evolution in mDm maturity and need not require a complete overhaul of systems and procedures, provided that functional solutions are built with this end goal in mind.

ABOUT THE AUTHORS

michael allelunas, general manager of information management, is responsible for developing and delivering a wide range of solutions to clients. Key disciplines within the information management practice include master Data management, specialty Data integration, Data Warehousing and information management strategy and Diagnostic services. Throughout his 19 years

ABOUT IMS HEALTH

IMS Health is a leading worldwide provider of information, technology, and services dedicated to making healthcare perform better. With a global technology infrastructure and unique combination of real-world evidence, advanced analytics and proprietary software platforms, IMS Health connects knowledge across all aspects of healthcare to help clients improve patient outcomes and operate more efficiently. The company’s expert resources draw on data from nearly 100,000 suppliers, and on insights from 39 billion healthcare transactions processed annually, to serve more than 5,000 healthcare clients globally. Customers include pharmaceutical, medical device and consumer health manufacturers and distributors, providers, payers, government agencies, policymakers, researchers and the financial community. Additional information is available at www.imshealth.com