Customer Data Integration

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.

Master Data Management Introduction

In a connected world, collaboration and sharing are key principals. In particular, the faster our networks are and the better our connectivity is, the more your organization will benefit from information sharing and operational collaboration. In turn, as we share more information among our partners, our connectedness is enhanced as well. It is not just systems that work better together, but the people managing those systems forge better working relationships, leading to more effective management of the business and ultimately, to competitive advantage. However, the more we share information, the more we realize that years of distribution of computing power and business applications into vertical lines of business has led to “islands of information coherence.” Data architectures designed to support operational processes within each business application area require their own definitions, dictionaries, structures, etc., all defined from the aspect of that particular business application.

The result is that the enterprise is composed of multiple, sometimes disparate sets of data that re intended to represent the same, or similar, business concepts. Yet, to exploit that information or both operational and analytical processes, an organization must be able to clearly define hose business concepts, identify the different ways that data sets represent those concepts, ntegrate that data, and then make it available across the organization. And this need has ntroduced a significant opportunity for organizational information integration, management and haring. n this white paper, we will discuss how these processes comprise a master data management MDM) program. We will look at questions such as:

• What is master data management?
• What are the characteristics of “master data”?
• What are some architectural approaches to MDM?
• What are the organizational challenges of instituting an MDM program?
• How does data quality figure in?

This paper is the first in a series exploring the basics of master data management, the policies nd procedures employed, and the tools and techniques used for a successful MDM program.

The Origins of Master Data

The introduction of workgroup computing coupled with desktop applications ushered in an era of information management distribution. Administrative control of a business application, along with its required resources, brought a degree of freedom and agility to a business manager. However, by virtue of that distribution, the managers of a line of business could dictate the processes and constraints associated with the development of their own vertical applications to run their own lines-of-business, leading to variance in the ways that business concepts and objects are defined.

Not only that, the increase in both power and functionality at the desktop has engendered an even finer granularity of data distribution, allowing an even greater freedom in describing and modeling business information. And whether it is in the mainframe files, the database server, or in the spreadsheets on your desktop, we start to see a confusing jumble of concepts, along with creative ways of implementing those concepts.

Over the past ten years or so, the pendulum has swung back to centralized computing (such as data warehousing) for applications that help improve the business, with the intention of consolidating the organization’s data into an information asset to be mined for actionable knowledge. And while the centralization of information for analysis and reporting has great promise, this in turn introduces a different challenge. As data sets are integrated and transformed for analysis and reporting, cleansing and corrections applied at the warehouse imply that the analysis and reports may no longer be synchronized with the source data. In essence, this just clarifies the benefit of creating a single source of truth for all enterprise applications – not just for analysis or reporting – and this embodies the concept of master data.

For example, consider your company’s customers. Each customer may participate in a number of business operations: sales, finance, customer service. Some of your customers may even participate in different contexts, perhaps as vendors or suppliers. In each of these contexts, the customer may play a different role, and in turn, the business may value some attributes over others depending on the context. But you clearly want to ensure that your business processes don’t fail because the customer appears multiple times in different data sets. In addition, you want to be confident that the customer’s activities are accurately portrayed in management reports.

In other words, different business applications record transactions or analysis regarding entities and their activities. And it is desirable for all the business applications to agree on what those entities and activities are. We can summarize two objectives:

• Integrate the multiple variations of the same business entities into a single (perhaps virtualized) source of truth.
• Enable enterprise applications to share that same view of the business objects within the enterprise.

Defining Master Data

So far we have used terms such as “business concepts” or “business entities” when referring to master data, but what are the characteristics of master data? Master data objects are those core business objects that are used in the different applications across the organization, along with their associated metadata, attributes, definitions, roles, connections and taxonomies. Master data objects are those “things” that we care about – the things that are logged in our transaction systems, measured and reported on in our reporting systems, and analyzed in our analytical systems. Common examples of master data include:

• Customers
• Suppliers
• Parts
• Products
• Locations
• Contact mechanisms

For example, consider the following transaction: “David Loshin purchased seat 15B on US Airways flight 238 from Baltimore (BWI) to San Francisco (SFO) on July 20, 2006.” Some of the master data elements in this example and their types are shown in Table 1 (below).

Master data tends to exist in more than one business area within the organization, so the same customer may show up in the sales system as well as the billing system. Master data tends to be relatively static, and does not change frequently. Master data objects may be classified within a hierarchy

For example, we may have a master data category of “party,” which in turn is comprised of “individuals” or “organizations.” Those parties may also be classified based on their roles, such as “prospect,” “customer,” “supplier,” “vendor,” or “employee.” While we may see a natural hierarchy across one dimension, the taxonomies that are applied to our data instances may actually cross multiple hierarchies. For example, a party may simultaneously be an individual, a customer and an employee.

In turn, the same master data categories and their related taxonomies are used for analysis and reporting. For example, the headers in a monthly sales report may be derived from the master data categories (such as sales by customer by region by time period). Enabling the transactional systems to refer to the same data objects as the subsequent reporting systems ensures that the analysis reports are consistent with the transaction systems.

What is Master Data Management?

As opposed to being a technology or a shrink-wrapped product, master data management (MDM) is comprised of a mixture of business applications, methods and tools. These aspects can implement the policies, procedures and infrastructure that support the capture, integration, and subsequent shared use of accurate, timely, consistent and complete master data.

• Assess the use of core information objects, data value domains and business rules in the range of applications across the enterprise
• Identify core information objects relevant to business success used in different pplication data sets that would benefit from centralization
• Instantiating a standardized model to manage those key information objects in a shared repository
• Managing collected and discovered metadata as an accessible, browsable resource, and using it to facilitate consolidation
• Collect and harmonize unique instances to populate the shared repository
• Integrate the harmonized view of data object instances with existing and newly developed business applications via a service-oriented approach
• Institute the proper data governance policies and procedures at the corporate or organizational level to ensure the continuous maintenance of the master data repository

Numerous technologies have, in the past, been expected to address parts of this problem through customer master tables or industry-specific consolidated product management systems. But these applications have been criticized (perhaps unfairly) as a result of the organizational management approach to their implementation: largely IT-driven, presumed to be usable out of the box, lacking enterprise integration and suffering from limited business acceptance. Resolving the issues pointed out by that criticism is what defines some of these considerations for implementing a successful master data management program:

• Effective technical infrastructure for collaboration
• Organizational preparedness
• “Round-trip” enterprise acceptance and integration
• Measurably high data quality
• Data governance

Architectural Approaches to MDM

Let’s consider an MDM infrastructure. In the best of all possible worlds, we desire a service-oriented environment that can support new applications while allowing for incremental integration with legacy applications. There may be many ways to develop a master data repository. Here, we explore three conceptual architectural approaches to developing this capability, each addressing different organizational needs. It is interesting to note, though, that once the MDM concept is accepted within the organization, it is relatively easy to transition between solution frameworks.

In a Central Master Data System, for each data “domain,” a set of core attributes associated with each master data model is defined and managed within a single master system. The master repository is the source for managing these core master data objects, which are subsequently published out to the application systems. Within each dependent system, application-specific attributes are managed locally, but are linked back to the master instance via a shared global primary key. In this approach, new data instances may be created in each application, but those newly-created records must be synchronized with central system.

In a Mapped Master System, an existing application system is selected to be the master, and other systems become dependent on that system as the main repository. New data instances are created in the master, which are then propagated to other systems. In this approach, different data objects are not necessarily linked by a global primary key, so it may be necessary to define mappings to link objects between systems. When new objects are created, they are distributed out to other applications, and similar to the central master approach, the other applications may not modify core attribute values but may introduce and modify their own application-specific attributes.

In a Hub Repository, a single repository is used to manage the core master system, and data is not replicated to other systems. Applications request information from central hub and provide updates to the central hub. Since there is only one copy, all applications are modified to interact directly with the hub.

There are other alternate approaches as well, yet all the approaches share these characteristics:

• Relevant core master data is managed within a single repository
• Dependent applications rely on publication of master information via a service-based approach
• An investment must be made in integrating data from across the application systems to identify the best sources of high-quality master data as well as that data’s use in dependent applications

Regardless, once the MDM system is in place, the corresponding data quality assurance and data governance framework must be in place to ensure ongoing synchronization.

Organizational Challenges and Master Data Management

A key success factor in creating a master data management program is an early understanding of the transition of responsibilities for data oversight and governance that will impact your organization. Years of distribution of business applications into vertical lines of business have led to discrete islands of information. As a result, the IT and data management structures associated with those lines of business have erected barriers to collaboration.

In addition, the politics of information ownership and management have created artificial fiefdoms overseen by individuals for whom centralization holds no incentive. And lastly, consolidating master data into a single repository transfers the responsibility and accountability for information management from the lines of business to the organization. Because of this, some of the greatest challenges to success are not technical – they are organizational.

It is largely because of these issues that MDM should be considered as a “program” and not as an application. Focusing on these directives will distinguish a successful MDM program from one destined for failure:

• Organizational Preparedness: Anticipate that a rapid transition from a loosely-coupled confederation of vertical silos to a more tightly-coupled collaborative framework will ruffle a number of feathers. Assess the kinds of training sessions and individual incentives that must be established in order to create a smooth transition.

• Data Governance: As management responsibility and accountability transition to the enterprise team, it is important to define the policies and procedures governing the oversight of master data. By distributing these policies and seeking proactive comments from across the different application teams, you have an opportunity to create the stewardship framework through consensus while preparing the organization for the transition.

• Technology Integration: As is often the case, new technologies that are dependent on application packages are like the tail wagging the dog. Recognize the objective to integrate technology to support the process instead of develop process around technology.

• Anticipating Change: As with any paradigm shift, proper preparation and organization will subtly introduce change to the way that people think and act. Since the nature of a master data management program is to integrate data for competitive advantage, encourage individuals to begin to explore new ways to exploit master data for improving business productivity.

Download Article

Insurance Application Architecture - IBM

Insurance for On Demand Business

As the insurance industry continues to deal with a fast pace of change, insurers face stark new challenges. In today’s marketplace, survival favors the agile; speed can be a critical differentiator; and the organizational status quo is often a liability. Successful insurers are beginning to adapt to continuous, unpredictable and accelerating change. Many insurers still struggle to manage a complex web of legacy silos, disparate systems, redundant functionality, excess capacity and inconsistent service levels. Enthusiasm for IT spending and decentralization has exacerbated the problem, saddling firms with overlapping – and often unproven – technologies. For many insurers, the results are all too familiar: disjointed operations, redundant capabilities, inefficient cost structures and duplication of work across product, geography and business lines.

Most insurers still operate largely within a vertical business structure, whereby distribution occurs mainly by product silo and operations are biased toward internally manufactured or developed products. Achieving material cost reductions in this structure is difficult, and consumers generally see very little or no differentiation among insurers. Given their financial challenges, insurers can no longer afford to have capabilities duplicated across product silos, with each product operating its own processes, systems and specific channels. This duplication causes significantly greater complexity in insurer operations, impacts costs and speed to market, and often increases operational risk.

In large enterprises, initiatives that attempt to optimize these processes in isolation, without first merging them, fail to fully address their complexity and overlapping functions. Process optimization generally focuses on vertical integration and often within single products or business units. To achieve a step change in performance, today’s highly complex insurance operating models must be simplified. Moving from process transformation to enterprise transformation is the key that will
unlock significant benefits for insurers.

Technology is a fundamental change enabler, but IT decisions need to remain firmly rooted in the business needs of the organization. To operate on demand, your organization will need to transform the way it operates by re-evaluating its business processes as well as its technology infrastructure.

Business Transformation
Most insurance firms know they need to change, but question if the analytical tools available to them are up to the task. Traditional, linear approaches, such as business process re-engineering, are useful for optimizing workflows and often yield improved sub-processes, but they do little to highlight similar activities that are scattered across separate processes within the enterprise. Successful insurers require a new way to view their business operations, one that will help them adapt and thrive in an environment of continuous change.

An insurance specific Component Business Model (CBM) helps by simplifying the way insurers look at their operations. With CBM, executives can extract themselves from the process “rut” and get at the real sources of value that drive their companies. They can identify the unique, standalone building blocks that comprise the insurer as a whole. Viewing business activities as autonomously managed components that can be optimized individually for greater value to the whole business enables decision makers to cut through historical boundaries that may have built up along organizational, product, channel, customer, geographical and informational lines.

Application Transformation
The use of component-based business modeling, underpinned by industry models, such as the IBM Insurance Application
Architecture (IAA), enables insurers to define their target business architecture and transformation goals. This drives
application transformation and often the design and implementation of new application solutions. The IAA models, with a rich
set of industry application component definitions, are a key accelerator for the logical design and architecture of building new
functionality.

Download Article

Master Data Management - White Paper Contents Copyright(c) SAP

1 EXECUTIVE SUMMARY
For many companies maintaining distributed IT landscapes, common master data is crucial for business success. But managing it can be a challenge. Many companies find them­selves storing the same duplicate master data across a number of different locations and systems. This produces redundancies and inconsistencies that can cost money, disrupt business, and adversely impact the quality of customer service.
Fortunately, SAP® Master Data Management (SAP® MDM) – a building block of the SAP® NetWeaver™ – enables companies to store, augment, and consolidate master data, while ensuring consistent distribution to all applications and systems within the IT landscape. Working across heterogeneous systems at multiple locations, SAP MDM leverages existing IT investments in business-critical data, delivering vastly reduced data mainte­nance costs through effective data management. And by en­suring cross-system data consistency, SAP MDM accelerates the execution of business processes, greatly improves decision making and helps companies maintain competitive advantage.

2 INTRODUCTION
Business processes without consistent master data have little business value-and can even negatively impact a company’s ability to compete. Within the context of large, heterogeneous IT landscapes, misaligned and inconsistent master data leads to costly data redundancies and even misleading analytics that can result in faulty business decisions.

But achieving master data consistency for all systems within a distributed IT environment has traditionally proven difficult. This reason alone explains why branch offices often work in­dependently of the larger enterprise. Mergers and acquisitions, too, present significant problems with regard to consistent master data. While at a technical level, companies can indeed link new software solutions obtained in an acquisition – true integration at the business process level is routinely impeded due to fundamental incongruities between master data models.

Ultimately, master data management (MDM) enables depend­able cross-system, enterprise-wide business processes and ana­lytics – ensuring that everyone involved in the process has access to the same information and knowledge. This is why a solution that enables both the consolidation of master data as well as the availability of consistent data across systems bound­aries offers a decisive competitive advantage.

MDM – A COST SAVINGS EXAMPLE

Take the example of a large retail company, Big Retail, Inc. Over time, Big Retail acquires three other retail establishments and operates them as wholly owned subsidiaries while maintaining their individual brand identities. These are Valuable Products Unlimited, The Quality Goods Company and Affordable Merchandise, Inc.
Running similar businesses, all three companies sell Deliciously Tasty Chocolate Bars. Each year, each of these companies buys approximately $100,000 worth of these chocolate bars from the manufacturer, Worldwide Chocolates. Lacking an integrated order process that links all three shops to the headquarters of Big Retail, each company deals with Worldwide Chocolates independently. In effect, then, Big Retail spends $300,000 annually for Deliciously Tasty Chocolate Bars.
However, because the master data from order processing is not integrated, Big Retail is unable to see this simple fact. Using MDM techniques to connect the order processes, on the other hand, Big Retail is able to see exactly how much annual busi­ness it does with Worldwide Chocolates and is able to negotiate a better deal. While Worldwide Chocolates awards a 5% dis­count on orders of $100,000, it is willing to award a 15% dis­count on the $300,000 order placed by Big Retail. Thus, with each subsidiary dealing with the manufacturer independently, Big Retail saves only $5,000. But when negotiating from infor­mation obtained through properly managed master data, Big Retail saves $45,000 – a significant cost savings that comes right off the bottom line.

SYSTEMS INTEGRATION VS. INFORMATION INTEGRATION

Some companies assume that enterprise-wide systems integra­tion will achieve, in and of itself, the kind of process and infor­mation integration that enables the smooth running of busi­ness on a global scale. This is not the case. To put it more precisely, systems interoperability is a prerequisite for business process integration, but doesn’t achieve the goal alone. Un­fortunately, many companies get bogged down in the details of the systems integration initiative – and never move on to the issues of master data required for full process and information integration. This is understandable. After all, traditional inte­gration initiatives require tremendous amounts of time and resources (coding point-to-point connections at the API level). As discussed later, a more efficient approach would be to employ an enterprise application integration (EAI) approach, using an exchange platform that ensures message handling, semantic mapping, routing and the queuing of data.
Once system interoperability is achieved, master data-at a busi­ness object level – needs to be exchanged and mapped on top of this technical integration layer. This, too, can be challenging. Companies engaged in such an effort will need a solution that can consolidate and harmonize master data – as well as enable consistent data maintenance and meticulous enterprise-wide data object distribution. Without such a solution, companies will continue to make the same mistakes – and continue to pay for them. A few examples:

• Costly, inefficient customer management: Customers want efficient service. But when customer information is loosely dispersed across a wide range of applications, this is a tough demand to meet. Without consolidating this infor­mation, customer management processes are forced to rely on locally available information – which is often incomplete or even obsolete. This can significantly detract from a com­pany’s business performance – both in terms of cost efficien­cy and customer loyalty.

• Proliferating parts diversity: For companies involved in the manufacture or assembly of physical goods, the storage, pro­curement and cataloging of parts requires tremendous enter­prise resources. Redundant master data can present a distort­ed picture of parts inventory, causing vexing supply chain gaps. Without efficiently managed master data, companies will continue to generate the kind of redundancies and low data quality that prohibit the smooth execution of collabora­tive logistics processes.

• Faulty cross-group reporting: As companies manage their bottom lines, inventories must be reduced, prices matched, and procurement processes streamlined. Cross-group report­ing forms the basis for the business decisions that guide these initiatives. But when it is based on inconsistent, ill-managed data, cross-group reporting can lead to the kind of faulty executive decision making that adversely impacts business competitiveness.

A properly implemented MDM solution can solve all these problems – by sharing harmonized master data across system boundaries, fostering enhanced business collaboration, and ensuring cross-system data consistency regardless of the physi­cal location or vendor origin of independent systems within the distributed IT environment.
We now turn to a detailed explanation of concepts central to Master Data Management.

THE MDM CONCEPT

Successful MDM in a heterogeneous IT environment involves more than the integration of systems. Master data must be accounted for and supported in its overall cross-system context throughout each business process.
At the same time, while companies may readily see the business advantages to properly managed master data, they cannot afford the downtime required to implement large enterprise-wide software packages. In addition, in this time of IT budget consciousness – following years of intense IT investment – most companies are in a mood to use what they already have rather than replace existing investment. That’s why any MDM solution must be:

• Quickly implemented without altering the existing systems landscape
• Tailored to the company’s business and organizational requirements through flexible business processes and the mapping of organizational structures
• Introduced on a step-by-step, evolutionary basis that minimizes disruptions to the daily flow of busines

Download PDF Article