IBM Master Data Management Master Data Management Server v 8

IBM Master Data Management Master Data Management Server v 8
IBM Master Data Management Master Data Management Server v 8.0 Q1, 2008

Agenda Master Data Management Market Update IBM Multiform MDM Strategy – Keep it simple Introduction to IBM MDM Server v8 Key Supported Features Implementation Styles Packaging and Pricing CDI Entry Level Concept Case Studies

Gartner’s View of the CDI market
CDI Hub Total Software Revenue, By 2010, the customer data integration hub software market will grow to $706 million, with a five-year compound annual growth rate of 30%. Source: Gartner’s “Market Share and Forecast: CDI Hub Software, Worldwide, ” by Fabrizio Biscotti and John Radcliffe, December 2006 Source: Gartner Dataquest (December 2006)

Gartner Estimates Significant Growth in PIM Market
Increasing customer recognition that inaccurate product data is the root cause of significant business challenges Value of PIM extending beyond early adopter industries, e.g. A&D, Industrial manufacturing Requirements are becoming more complex Business drivers such as multi-channel and eCommerce Nature of data in new industries (e.g. A&D) is inherently complex Gartner expectations: By 2010, IBM, Oracle and SAP will command more than 50% of PIM SW revenue (0.7 probability) No leader will emerge in the PIM market before 2009 (0.7 probability) Gartner Estimated PIM Market Opportunity 2009 Est. $860M PIM SW (lic. & maint.) $ in millions 2007 Est. $460M $300M $214M Analysts estimate that IBM will capture significant percentage of PIM market opportunity over next three years Source: Magic Quadrant for Product Information Management, 2Q07, Gartner, Inc.

Master Data Management Market
Master data management is a large, fast growing, highly fragmented market $4 billion software and services in 2005 (IDC) >15% CAGR through 2009 Key infrastructure requirement across all industries Consolidation occurring across all segments Complexity of integration, scalability, product extensions, and service skills driving investments IBM views this market as core to Services Oriented Architecture (SOA) strategies Enable the delivery of composite applications across heterogeneous environments Drive efficiencies and new processes in multi-product, multi-channel, multi-geography based companies

Gartner Magic Quadrants
Gartner Magic Quadrant For Product Information Management 2007 Magic Quadrant for Customer Data Integration Hubs 2007 Source: Gartner, Inc. “Magic Quadrant for Customer Data Integration Hubs, 2Q06” by John Radcliffe. May 26, This Magic Quadrant graphic was published by Gartner, Inc. as part of a larger research note and should be evaluated in the context of the entire report. The Gartner report is available upon request from IBM. Source: “Magic Quadrant for Product Information Management, 2005” Gartner ID: G , Andrew White, Published on 16 May 2006

IBM is #1 rated MDM solution – Perfect Score!
IBM’s MDM product portfolio is very threatening to competitors because it leverages best-of-breed DBMS, DW, DI, DQ and data governance products; has been packaged, customized and licensed effectively for the leading MDM horizontal and vertical markets; and is delivered through IBM’s global professional services force. – Current Analysis, Inc.

Growth of the MDM Market
IBM already fields one of the strongest MDM suites on the market, having made several DM vendor acquisitions in recent years—most notably, EII/ETL pioneer Ascential—to build up its portfolio, while providing packaged MDM offerings targeted at the CDI and PIM markets. - Jim Kobielus, Current Analysis, October 2007- By 2012, the market for enterprise MDM solutions (software & services) as both strategic initiatives and to refresh aging legacy MDM capabilities will exceed US$3B…Through , mega IT vendors (IBM, ORCL, SAP, & TDC) will dominate the MDM market with niche/best-of-breed vendors thriving in specific industries & horizontal/corporate applications. - Aaron Zornes, Chief Research Officer, The CDI Institute, December 2007 Now that MDM is starting to mature it has the potential to become the authoritative way to manage the single trusted view of the customer. - Judith Hurwitz, The Hurwitz Group, October 2007-

Multiform Master Data Management The Application Process and Function Problem
CRM Billing ERP Data and Functionality unique to each application Application-unique Functionality & Data Application-unique Functionality & Data Application-unique Functionality & Data Data and data functionality common to applications: Customer, Account, Product Common Functionality & Data Common Functionality & Data Common Functionality & Data Most people can easily identify the symptom – data is fragmented across business applications – it’s inaccurate, incomplete, and in conflict with data in other systems It’s not as easy to identify the root cause – but it is the functionality of the applications themselves that cause this problem. No one application is aware of how other applications consume the data it uses – it doesn’t have the business logic and function to manage data at an enterprise level. Therefore it adds and updates data profiles based on its narrow set of rules, and does share data with other applications – and that is why data gets out of synch and is inaccurate. Symptom Data is inaccurate, incomplete and conflicts with other systems Root Cause Common data and data function is siloed

Multiform Master Data Management Definition
Definition of Master Data Key facts describing core business entities High value information impacting most important business processes Siloed in multiple processes, applications, and LOBs Definition of Master Data Management Application Support all applications that create and consume master data Contain configurable functionality to maintain and be the system of truth for master data Maintain and leverages relationships among master data entities Manage the complete data lifecycle Support all implementation approaches

The Simple Story! Multiform MDM Strategy
Master Data Management has 2 requirements: Data Domains – Manage master data on party, product, account and location – and maintain relationships among them MDM Function –Business processes associated with the Master Data Collaborate Operationalize Analyze Party, Product, Account, Location Create and Define Real-time business services Insight and Analysis MDM Function MDM Data Domain Multiform Master Data Management

1. Multiform Master Data Management Defining Domains
Party, Product, Account, Location Party can reflect any legal entity, whether individual or organization Product encompasses both physical goods as well as services Account includes terms and conditions, and associated relationships Location may serve as a primary or secondary domain ...Not only must these domains be managed but also the relationships among them... Party PRODUCT Agent Customer Employee Prospect Supplier Part Product Product Bundle Item/SKU Service Terms & Conditions ACCOUNT LOCATION Contract Agreement Transaction Reward Program Financial Account Location Address Contact Method Geography/Region

1. Multiform Master Data Management Master Data Domains
An MDM application must manage deep data on a single primary data domain — party, product, account An MDM Application must manage complex relationships among data domains to gain understanding of master data Party Multi-domain Relationship Management Account Voice over - How it would work without relationships/linkages - Product Location

2. Multiform Master Data Management Why Multiple Functions?
Data is dynamic, not static Applications that use master data play different roles … … the same application may create data, consume it, and require analysis of it One Functional style can trigger another An MDM System must be able to Provide mechanisms for consistent use of master data across the organization Integrate the functional styles to manage data lifecycle processes Data Lifecycle Management Operational Analytical Collaborative

Multiform Master Data Management Characterized By Multiple Users, Multiple Usages
Collaborate Operationalize Analyze Party (customer, citizen, prospect, organization, supplier, distributor, etc.) Product (good, service, product bundle, catalogue, product component, etc.) Account (Agreement, financial account, reward program, etc.) Define, create and synchronize Master Information Deliver Master Information as a service for business operations Drive real time business insight Application-unique Functionality & Data Common Functionality & Data Operational Business Applications Real-time SOA data access Operational Data Usage Data Creators e.g., Administrators, trading partners, etc. Business Applications Collaborative Analytical master data Data Warehouses Reporting & Analytics Provide examples for each usage style Define and create master data

The Simple Story! – One Small Addition…
Master Data Management has 2 requirements: Data Domains – Manage master data on party, product, account and location – and maintain relationships among them MDM Function –Business processes associated with the Master Data … and MDM may be implemented in 4 different styles Collaborate Operationalize Analyze Party, Product, Account, Location Create and Define Real-time business services Insight and Analysis Consolidation Registry Co-existence Transaction MDM Function MDM Data Domain MDM Implementation Style Multiform Master Data Management

Multiform Master Data Management Consolidation Example
Registry Co-existence Transaction Batch Import Consolidation Full data model across multiple data domains Batch import capabilities + Information Server integration Data stewardship and governance functionality Batch export to target systems MDM Database Full Data Model Matching Governance Batch Export

Multiform Master Data Management Registry Example
Consolidation Registry Co-existence Transaction Registry Index (cross-reference) capabilities for any data entity and attribute in the IBM MDM Server database Search and inquiry services Capabilities for virtual consolidated view via Information Server capabilities (federated queries) Data stewardship and matching Source Source MDM Database Index Virtual View

Multiform Master Data Management Co-existence Example
MDM Implementation Style Consolidation Registry Co-existence Transaction Batch Import Co-existence Full data model across multiple data domains Cross-reference keys, subscription management, and message notification capabilities Search and inquiry SOA services MDM Database Full Data Model Matching Governance Application Application Application

Multiform Master Data Management Transaction Example
MDM Implementation Style Consolidation Registry Co-existence Transaction Application Application Application Transaction System of record add and update SOA transactions, with full business logic Transaction audit logging and database change logging and auditing Authorization an the data attribute level – rules of visibility to control data access Transaction processing capabilities – transactional integrity across all business services and ability to participate in enterprise (cross application) transactions MDM Database Full Data Model Matching Governance Application Application Application

Multiform Master Data Management Implementation Styles
Consolidation Registry Co-existence Transaction Multiform MDM requires multiple Implementation Approaches to ensure customer success IBM is the only MDM vendor able to deliver on all 4 Implementation Approaches: The Transaction approach is a superset (100% functionality) encompasses the full functionality of all others Consolidation, Registry and Co-existence are a partial deployment/use based on specific use cases/requirements Multiple approaches may be used simultaneously (i.e, single deployment, single install) to meet specific business needs/requirements within: Data domains or individual subject areas/attributes Business units Consuming applications Geographies

Party, Product, Account, Location
IBM Is Uniquely Positioned to Deliver On Multiform MDM Through IBM MDM Server and WebSphere Product Center IBM Master Data Management Server Integrity Action Intelligence Data Governance Knowledge Master Profile Services interface Business rules to manage events Rules of visibility Maintains single record MDM business services IBM WebSphere Product Center Intelligence Business rules to manage events Leverage Aggregate and syndicate data Insight User Interface Knowledge Flexible data model Interaction User and Role- based Access IBM MDM Server and IBM WebSphere Product Center deliver Multiform MDM capabilities Consolidation Registry Co-existence Transaction MDM Implementation Style Collaborate Operationalize Analyze Party, Product, Account, Location Create and Define Real-time business services Insight and Analysis MDM Function MDM Data Domain Multiform Master Data Management

IBM Master Data Management Server IBM MDM Server Addresses Multiple Domains via Operational Functionality IBM MDM Server is first product to deliver significant capability across domain and function. IBM is also able to address multiple implementation styles. Primarily operational but offers some collaborative and analytical. Multiform MDM is IBM’s strategy for the most complete MDM offering by addressing: MDM Domains MDM Functions MDM Implementation Styles. Index Reference Data System of Record Data

Multiform Master Data Management WPC Addresses Collaborative Style, Product Domain
Collaborative Usage of MDM: Manages the process of Creating, Defining, and Verifying master data Focused on the definition of Master Data that can be synchronized with Operational and Analytical Systems Multiform Master Data Management Collaborate Operationalize Analyze Party (Customer, citizen, prospect, organization, supplier, distributor, etc.) Product (good, service, product bundle, catalogue, product component, etc.) Account (Agreement, financial account, reward program, etc.)

IBM WebSphere Product Center
The most experience with Product Information Management implementations Largest customers in the world Multi-faceted requirements Multiple verticals Ranked as leader by industry analysts Recognized leader in expanding collaborative and operational requirements for product domain into broader MDM offering Out of the box functionality Excels in heterogeneous environments IBM WebSphere Product Center’s key differentiators (bullets) and core value proposition (bottom). Customer logos here represent only a sample of our customers. WebSphere® Product Center allows companies to create a single, up-to-date repository of product information that can be used throughout their organization for strategic business initiatives.

IBM MDM Server – Release Summary
Technology Benefits Cross-domain capabilities Manage Risk & Compliance Master Data Lifecycle Support Manage Information Complexity Optimized Infrastructure WPC Prod Collaborative “Cambridge” Collab Operational Analytical WPC Customers WPC Party Acct Prod 2010 Prod Collaborative “Hollywood” Multiform Phase III “Bordeaux” WPC Customers WPC Collab Operational Prod Collaborative Party Acct Prod 2009 “Glendale” IBM Master Data Management Server Multiform Phase II “Auckland” Operational Business Benefits Revenue Enhancement Customer Care Thread and Fraud Services Optimization Operational Efficiency Party Acct Prod WCC Customers 2008 WCC Multiform Phase I Party Operational

Party, Product, Account, Location
Multiform Master Data Management Operational MDM Operational Function of MDM: Use and Maintenance of Master Data occurs within Operational process/applications Master Data is consumed by other systems via real-time accessible SOA Services Collaborate Operationalize Analyze Party, Product, Account, Location Create and Define Real-time business services Insight and Analysis MDM Function MDM Data Domain Multiform Master Data Management

IBM Master Data Management Server v. 8.0
Manages the complete master record for operational customer data to all systems & channels Capable of being the system of record – with full transaction processing and business logic capabilities Provides accurate and complete customer data to all operational business processes that require customer data Improved and differentiated customer service Increased revenue via improved cross-selling and event management Ability to persist ‘new’ customer data such as privacy preferences, events, and multi-channel interactions Regulatory compliance

IBM Master Data Management Server
Integrity Intelligence Data Governance Knowledge Master Profile Services interface Business rules to manage events Rules of visibility Maintains single record Action MDM business services MDM Server is a service-oriented business application Action 100% service oriented – every function is a business service to maintain the master customer profile More than 700 large and fine grain business services Integrity Data quality components are integrated with MDM business services Detection of duplicate parties, data validation rules Data stewardship UI – managing data and data quality within MDM Server customer master profile Intelligence Business rules – event detection and notification Critical data change management Data Governance Privacy, data security & governance – manage user/role access to data at a granular level Knowledge Party-centric model with complex hierarchies Contains operational database and history/audit trail database to maintain master data audit trail Note: all information represents IBM's current intent, is subject to change or withdrawal, and represents only goals and objectives

IBM Master Data Management Server Adding a New Customer
Action- MDM Server kicks off a large grain business service called ‘add new customer’ to begin transaction Knowledge – MDM Server houses and stores the new record MDM Server’s Integrity and Intelligence called on to perform search, data validation, party matching and event notification capabilities to ensure accuracy of data and notification to other systems Data Governance provides security around who can view and edit the data Action Intelligence Integrity Knowledge Check User Authorization Duplicate Suspect Processing Information Integrator for Standardization & Matching Event Notification New Customer Added Add Customer Search Person Check for Duplicates Name Address Contact Method Identification Relationship Financial Profile Right side – graphic – show the most common function for the product and how the functional groups (e.g., previous slide) are used (e.g., identify a person – how are all the parts used) Left side – text Describe how each component comes into play

IBM Master Data Management Server Multiform MDM Function - Operational
Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Designed for integration to multiple applications Contains both large and fine grain services Add customer, value package management, add product (large grain) Update phone number, add hierarchy node (fine grain) Flexibility Easily extend or build new services from existing services Business Logic components integrated with business services Rules of visibility to authorize data access Critical data change business rules Event processing Duplicate suspect processing

IBM Master Data Management Server Multiform MDM Function - Operational
Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile New business services Account & agreement Value package management Product Product category & hierarchy management Know-your-customer compliance Needs analysis Person and organization demographics Coarse grain cross-domain business services

IBM MDM Business Services - Categorization
New in IBM MDM Server v8 Party Demographic Services Roles-related Services Customer Service and Sales Services Account Services Product Services Party Party Macro Roles Interaction History Contract Product Basic Demographics Contract Party Roles Campaigns Contract Component Product Type Hierarchy Definable Demographics Rebate/Claim Party Roles Privacy Contract Party Role Product Values Party Names Grouping Party Roles Customer Preferences Contract Details Product Search Party Values Hierarchy Part Roles Party Values (Value Profile) Contract Location Product Terms & Conditions Party Search Relationship Party Roles Notes/Alerts Contract Terms & Conditions Product Relationship T&C Delete Party Search by Party Role Contract T&C Override Product Category Hierarchy Delete Party History Contract-Product Relationships Product Identification Contract Note/Alert Product Equivalency ID Product Content Mgmt Ref Data Stewardship Services Party Relationship Services Location Services Contract Search Contract Relationship Product Relationships Value Package Management Category Hierarchy Equivalency Category Hierarchy Search Duplicate Suspect Management Party Relationships Address Category Hierarchy Values Collapse/Split Parties Party Grouping Contact Method Terms & Conditions Aggregate View Duplicates Hierarchy Management Household Terms & Conditions Parameters Collapse with Rules Role Relationships Location Group Contract Services Source System Data Line of Business Role Location Data Decay Metadata Address Standardization Suspect Search Address Demographics Contract Create Search Contract Component Contract Party Role Contract Location Party Financial Profile Services Party Identification & Directory Services Events & Customer Insight Services History & Audit Services Billing Rebate/Claim Contract Note/Alert Bank Account Party Identification Registration Party Events Party History Audit Trail Contract Search Credit Cards Party Equivalency ID Events Account History Audit Trail Contract Relationship Payroll Deduction Search Party Equivalency ID Customer Value Profile Product History Audit Trail Holding Income Source System Key ID Corruption Management Transaction Audit Log Acxiom Abilitec KeyRetrieval Needs Analysis Delete Party History KYC Questionnaire

IBM Master Data Management Server Multiform MDM Function - Collaborative
Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Integration with Information Server Quality Stage Probabilistic matching Standardization Data Stewardship Application enhancements Task management Party management capabilities Data decay and recency Hierarchy management Grouping and relationship management

IBM Master Data Management Server Multiform MDM Function - Analytical
Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Event management engine Detect master data events Trigger actions – notification messages Integration with IBM Industry Model Data Warehouses Banking Data Warehouse Insurance Information Framework Telco Data Warehouse Retail Data Warehouse Ability to interface with insight stored within DW or store value profiles within IBM MDM Server

IBM Master Data Management Server Platform Features
Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Flexibility Multiple extension methods – dynamically extend/add data model via multiple mechanisms. Data model/service configuration (rename and disable parts of the product) Performance Performance management reporting Performance optimization Federated Deployments Multiple application instance deployments Data Validation Engine Message Notification Engine Common Audit Trail Metadata management Integrated platform tooling – Development, Test & Deployment

IBM Master Data Management Server Multiform MDM Data Domains
Intelligence Single view of CUSTOMER Single view of PRODUCT Integrity Action Maintains single record MDM business services Services interface Data Governance Agent Customer Employee Prospect Supplier Part Product Product Bundle Item/SKU Service Terms & Conditions Knowledge Master Profile Replication of data in siloed projects Requirements grow over time and require different POVs Master ACCOUNT record Single view of LOCATION Location Address Contact Method Geography/Region Contract Agreement Transaction Reward Program Financial Account

Intelligence Integrity Action Maintains single record MDM business services Services interface Data Governance Knowledge Master Profile Hierarchy Party Events & Insight Identification Product Roles Relationships & Groups Account Interactions Location Terms & Conditions

Intelligence Integrity Action Maintains single record MDM business services Services interface Data Governance Knowledge Master Profile KYC Compliance Location Demographics Party model with support for different Party Roles Interaction Relationships Privacy Roles Agent Customer Employee Prospect Supplier Party Contract and Product Financial Profile Events and Insight Data Stewardship Identification

Base Contract Relationships to Party Relationships to Product Contract Terms and Conditions Contract Services Value Package Sample IBM Master Data Management Server Intelligence Integrity Action Maintains single record MDM business services Services interface Data Governance Knowledge Master Profile Terms and Conditions Cross-reference Keys Account Relationships Account model with support for different Party Roles Contract Agreement Transaction Reward Program Financial Account Account to Product Relationship Agreement Account Account to Party Role Account Components Account Account Alerts

Account MDM Domain – The natural evolution
Customer Domain always had the notion of “holdings” as those items that make the customer a customer These where initially expressed as agreements (in fin. serv.) or contracts (other industries) As customer centricity objectives advanced, a more comprehensive need emerged: a comprehensive ability to offer, capture and administrate accounts for customers, that can support complex “holdings”, i.e. wide-ranging products, services subscriptions, product owned/registered, etc. or bundled versions thereof Account is a natural linkage point between the customer (party) and product domains Retail Examples: Store Card Accounts, Contracts with Suppliers etc. The Account domain would be used to manage the Contract between a Retailer and Vendor (Supplier) The Account domain would be used to manage the Contract (Store Card Account) between a Retailer & Customer PURPOSE: every time a vendor sells to retailer – there is a contract (account associated with a vendor)

MDM Account It can be used to offer new services for existing accounts
MDM Account provides a single source of truth of accounts and relationships among accounts. It can be used to offer new services for existing accounts Consolidated Statements Consolidated Billing & Payments Account Sweeps Rewards Points across accounts It can be used to offer new products by aggregating existing accounts Value Packages MDM Account Value Package X (Managed Account) Cheque Account (Ref Account) Savings Account (Ref Account) Credit Account (Ref Account) In all cases, the Account hub is made up of Managed Accounts and Reference Accounts Managed Accounts are system of record and can be transacted against. Reference Accounts are managed in other systems (analogous to WCC contract) IBM MDM Server v8.0 focuses on foundational and value packages. Cheque System Savings System Credit System Cheque Account Savings Account Credit Account

Account Details Examples of some elements added to contract:
agreement type, agreement status type, service level type, managed account indicator, agreement name / nickname, signed / executed / terminated dates…

Value Package Example How do we govern the terms and conditions of a value package? Value Package product is defined using product structure This includes terms and conditions with attributes Eg, “Core components must be in a valid status” with attributes “normal-open”, etc When a Value Package is sold to a customer, a contract (account) is created with relationships to the contracts included in the package. When a subsequent transaction updates contract details (for a reference account), event manager entries created. Rule executed to re-evaluate conditions. Have ideas on how to advance design around terms and conditions to provide more support for condition evaluation. Looking for feedback. Also with other topics such as product model.

Value Package (Product Bundle) Example
Account Domain Product Party “Triple Account” Value Package (Managed Account) Checking Account (Ref Account) Savings Account (Ref Account) Credit Account (Ref Account) Cheque System Savings System Credit System Checking Account Savings Account Credit Account

Features Base Product Product Type Hierarchy Product Dynamicity Product Terms and Conditions Category Hierarchy Localization Product Services IBM Master Data Management Server Intelligence Integrity Action Maintains single record MDM business services Services interface Data Governance Knowledge Master Profile Good Service Category Product model with support for different Party Roles Part Product Product Bundle Item/SKU Service Terms & Conditions Hierarchy Product Cross-reference Keys Terms and Conditions

Product Domain Millions of products and relationships
Support for large, complex product implementations Millions of products and relationships Complex data model requirements Validation framework Auditing and Effectivity Dating Out of the box product data model Flexible and Extensible Standards based Links to other data domains Support for complex product structures and relationships Item to Item, Up-Sell, Cross-Sell, Bundles, Packaging Hierarchy Support for multiple product hierarchies and mapping Inheritance Out of the box business services PURPOSE:

MDM Product MDM Product provides a single source of truth for product information. When deployed as a “Collaborative Hub” supports the collaborative authoring of products. When deployed as an “Operational Hub” provides product information out to the enterprise. Basic constructs include Products, Relationships, Product Catalogs, Product Terms and Conditions. Product domain addresses the fact that different types of products have different attribution associated to them. The definition of a CS service is different than the definition of a credit card product which is different than the definition of a deposit account product… IBM MDM Server v8.0 focuses on foundational and the Operational Hub style.

Card Product Loan Product Product Details Credit Facility Deposit Prod

Sample Set of Services AddProductInstance UpdateProductInstance
GetProductInstance SearchProductInstance AddProductAdminSysKey UpdateProductAdminSysKey GetProductAdminSysKey GetProductAdminSysKeyByProductId GetProductAdminSysKeyByIdPK GetAllProductAdminSysKeys AddProductIdentifier UpdateProductIdentifier GetProductIdentifier GetAllProductIdentifiers AddProductInstanceRelationship UpdateProductInstanceRelationship GetProductInstanceRelationship GetAllProductInstanceRelationships AddProductType UpdateProductType GetProductType GetAllProductTypes AddProductTypeSpecUse UpdateProductTypeSpecUse GetProductTypeSpecUse GetAllProductTypeSpecUsages GetAllProductSpecs (bordeaux) CategorizeProduct CategorizeProducts (bordeaux) UpdateProductCategoryAssociation RecategorizeProduct (bordeaux) GetAllProductCategoryAssociations GetProductCategoryAssociation GetAllProductsInCategory About 20 Category-Hierarchy services not shown in this list TermCondition services not shown in the list.

Product Bundle Example
Product Data Account Data Starving Student Bundle Joe Eager (Student) Student Checking Product Starving Student Bundle Shell (managed account) Student Savings Product No Frills Credit Card Product iPod Student Checking Account (reference account) Will receive a rate discount on the credit card Student Savings Account (reference account) Discount = 5% Credit Card Account (reference account) Free iPod if accounts in good standing after three months override Will receive a rate discount on the credit card The accounts within the bundle must be in a valid status Discount = 7% Status = Active Status = Credits Only

Implementation Approaches
Consolidation Registry Co-existence Transaction Multiform MDM requires multiple Implementation Approaches to ensure customer success IBM is the only MDM vendor able to deliver on all 4 Implementation Approaches: The Transaction approach is a superset (100% functionality) encompasses the full functionality of all others Consolidation, Registry and Co-existence are a partial deployment/use based on specific use cases/requirements Multiple approaches may be used simultaneously (i.e, single deployment, single install) to meet specific business needs/requirements within: Data domains or individual subject areas/attributes Business units Consuming applications Geographies

IBM Master Data Management Server Implementation Styles
Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Consolidation Registry Co-existence Transaction Full data model across multiple data domains Batch import capabilities + Information Server integration Data stewardship and governance functionality Batch export to target systems

Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Consolidation Registry Co-existence Transaction Index (cross-reference) capabilities for any data entity and attribute in the IBM MDM Server database Search and inquiry services Capabilities for virtual consolidated view via Information Server capabilities (federated queries) Data stewardship and matching

Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Consolidation Registry Co-existence Transaction Full data model across multiple data domains Cross-reference keys, subscription management, and message notification capabilities Search and inquiry SOA services

Intelligence Business rules to manage events Integrity Action Services interface Maintains single record MDM business services Data Governance Rules of visibility Knowledge Master Profile Consolidation Registry Co-existence Transaction System of record add and update SOA transactions, with full business logic Transaction audit logging and database change logging and auditing Authorization an the data attribute level – rules of visibility to control data access Transaction processing capabilities – transactional integrity across all business services and ability to participate in enterprise (cross application) transactions

Key Business Drivers for MDM
Revenue Enhancement – More intelligent cross-sell & up-sell via complete understanding of customer (profile, accounts & interactions) to leverage bundling opportunities Consistent Customer Treatment – Blending channels to deliver common customer interactions /experiences across all touch points Operational Savings & Efficiencies – “Once & done” enterprise-wide services for key customer processes such as account changes (name, address) Privacy & Regulatory Compliance – Central location for consistent rules of visibility & entitlements M&A Infrastructure – Shortening M&A customer, desktop, & billing integration timeframes

High value customer 10% off Sales History Product: 1234, 5748
Inconsistent Customer Treatment Siloed views of customer information lead to inconsistent customer service. Web Site Contact Center Store Jane Smith Is a high value web customer Yet… to the call center she is completely unknown Jane places an order via the contact center The call center rep does not see that Jane is a High Value customer And is not given the discount promotion she is offered on the web site Name: Jane Smith Name: Name: Jane F. Smith Address: 437 Easy Street Address Address: 123 Main Street High value customer 10% off Preferences Sales History Product: 1234, 5748 Sales History Product: 6574 Customer Value: High

Consistent customer treatment Deliver common customer interactions / experiences across all touch points. Web Site Contact Center Store Jane Smith MDM Server business services provide every customer interaction point with the complete view of the customer Jane is now viewed and treated equally across channels And Service Improves… “Yes I do see the order you placed on 2/2.” Did you know you qualify for a discount promotion?” “Would you like me to send that to your home address?” getParty Service Customer-centric Business Service Name: Jane F. Smith Interaction History: Service Issue 4/23/06 Web Order 2/2/06 Store Order 1/5/06 Demographics: Income - $100,000 Interests - Running Age - 41 Address: Home Main St Billing – 437 Easy St Relationships Household: Daughter – Jenny Husband – John Employer – IBM Life Events: Daughters Birthday Wedding Anniversary X-Sell Up-Sell: Items 5432, 4355 Privacy Preferences: Solicitation - No Agreements & Contracts: Service Contract Warranty Customer Value: High Sales History: Product 1234, 5748, 6574 Identifier IDs

High value customer 10% off Sales History Product: B, 2234 68
Operational Inefficiencies Problem: Inability to sell and service bundled product Web Site Product Sys 1 Product Sys 2 Jane Smith The marketing department wants to offer this ideal customer bundled products to increase revenue and drive customer loyalty Operational systems are not capable of managing bundles, which are relationships among existing products The result is significant manual effort and cost to create the illusion of a bundle (e.g., manually discounting a product in multiple systems) and no way to manage or track the bundle over time Name: Jane Smith Product A: Address: 437 Easy Street Product B Discounted Product High value customer 10% off Product C Sales History Product: B, Product Discounted Customer Value: High

Operational Savings and Efficiencies Lower costs by managing and servicing valuable product bundles centrally. Web Site Product Sys 1 Product Sys 2 Jane Smith MDM Server lets you manage the terms and conditions of the product bundle It lets you manage eligibility – who can buy the bundle, and at what terms and conditions Account – service the bundle once purchased MDM Server manages bundle data – the discount, relationships, Terms & Conditions Customer-centric Business Service Name: Jane F. Smith Interaction History: Service Issue 4/23/06 Web Order 2/2/06 Store Order 1/5/06 Demographics: Income - $100,000 Interests - Running Age - 41 Address: Home Main St Billing – 437 Easy St Relationships Household: Daughter – Jenny Husband – John Employer – IBM Life Events: Daughters Birthday Wedding Anniversary X-Sell Up-Sell: Items 5432, 4355 Privacy Preferences: Solicitation - No Agreements & Contracts: Bundle Service Contract Warranty Customer Value: High Sales History Product: B, Identifier IDs

MDM Packaging and Pricing Highlights
Tiered approach helps maintain value based price point Pricing done through Passport Advantage via offline calculator More simplistic than previous WCC model Will provide more consistency in pricing Reduces need for heavy discounting Collapsed number of Party record types Sold with Value units as the pricing metric New structure for selling according to functional style More enablement coming prior to launch***

MDM Server: Overview of Chargeable Components
Sold with Value Units as metric Value units calculated on three factors: Industry (5) 5 choices – align with IBM Sectors (i.e. COMM, DIST, FSS, IND, PUBLIC) Types of Records (4) Functional Usage Styles (2) Foundation is pre-requisite for Transaction Hub No relevant product functionality at this time for Transaction Hub usage style for Product record type Industry: XYZ Types of Records Functional Usage Styles Party: Individual Party: Organization Account Product Foundation Transaction Hub

MDM Server Pricing: Step 1 – Industry
MDM Server’s LI (and calculator) will include all industries in IBM’s standard sector/industry definitions (see below) Communications Sector Distribution Sector Financial Services Sector Industrial Sector Public Sector Telecommunications Media& Entertainment Utilities Retail Industry Consumer Products Travel & Transportation Banks Financial Markets Insurance Automotive Electronics Aerospace & Defense Chemical & Petroleum Industrial Products Government Education Health Life Sciences

MDM Server Pricing: Step 2 – Records
Customers will determine the number and type of records required based on the following 4 categories of records: Party: Individual Party: Organization Account Product Types of Records Party: Individual Party: Organization Account Product A Party: Individual record describes an actual person represented. Examples of Party: Individual include: person customer, person prospect, employee, agent, broker, and citizen. A Party: Organization record describes a recognized legal organization or logical grouping of individual person parties. Examples for party-organization include: organization customer, organization prospect, supplier, vendor, and any group defined legal entity. An Account describes a contract or agreement that is owned by an individual (an actual person) or recognized legal organization or logical grouping of individual person parties. Examples for Account include: a savings account, an insurance policy, and a service agreement A Product record describes a finished physical good or contract or agreement that is offered to either individuals or organizations. Examples of Product include: a box of cereal, a food processor, a savings account, an insurance policy or a service agreement.

MDM Server Pricing: Step 3 – Functional Usage Style
Customers will determine the Functional Usage Style(s) required for their deployment needs Customers may need both Foundation and Transaction Hub to address their needs Purchase of the Transaction Hub usage style mandates a pre-requisite of the Foundation usage style for that particular Record category E.g. If a customer requires a Transaction Hub Usage style for their Party: Individual records, the customer would need to purchase both Party: Individual – Foundation and Party: Individual – Transaction Hub MDM Server team plans to install ITLM compliance switches for second release of MDM Server Functional Usage Styles Foundation The Foundation functional usage style describes when the MDM Server is used to store and use party data as an Index, Operational Data Store, or referential system. Transaction Hub The Transaction Hub functional usage style describes when the MDM Server is used as a system of record in a transactional manner. The Transaction Hub functional usage style pre-requisites the Platform functional usage style for any given category of Record. Term in license: right to auditing. Tehse include SQL reports we’ve shipped that let us count the record types. 2. Configuration manager to determine if used or deployed. Records: within a particular line of business Platform Party: Account Index and account native key/cross-reference structure needed for party & product index Platform Account: Party Index needed (same as above) (same thing with Account except they also need product index); for product - & product Platform Product: for party & account Can’t have different counts for the same implementation. From platform to transaction Hub. Combinations of boxes with prerequs: Party: Individual: Party: Organization: Account: Retail Account: Commercial Product

Functional Usage Styles
MDM Server Pricing – More detail Industry: XYZ Types of Records PARTY ACCOUNT PRODUCT Functional Usage Styles Foundation Indexes & Source Values: party equivalency, native key, product x-ref table, default source value, granular services, contract role Basic Party data & functionality: person, org, person name, org name, identifier, granular data services, large grain services (data centric), data validation engine, data decay Supporting part data & functionality: org type, industry type, party misc values, financial profile (bank accts), person and org demographics, income source, granular data services, privacy data (no rules/defaults) Hierarchy & grouping & relationships: hierarchy, grouping Alerts: notifications, party alert, account alert, campaigns Interactions: interactions Duplicate suspect processing & matching engine: data steward UI, Dup suspect services & tables, Evergreen app, Data corruption mgmt Other: History, D&B Basic account data (reference data): Contract and contract component, billing summary, claims Product Data: all basic services in v8 release Transactional Hub Advanced party data & functionality: LOB relationships, critical data change management (pending), advanced duplicate suspect processing (known duplicate) management, federation services, KYC & needs analysis, ROV, macro role, coarse grain business services, transaction security & user authentication, delete services, privacy rules/defaults, large grain services (business functionality) Events: event manager, evergreen Other: Axciom, Fast Track, ILOG Account relationships Value package management (all relationship services) Campaign – foundation Fast track – txn hub? Inquiry only Lob – in txn hub ***Advanced dup suspect – kelvin, simon want it in? Need to confirm why? Txn security & user authentication – txn Data validation – internal val rules + engine (foundation), old external (txn hub)*** Coarse grain – add party in foundation, add contract in account foundation…. History audit DB – foundation *** Acxiom & dnb – foundation *** acxiom in txb hub Ilog – txn hub Data decay – foundation Delete – txn hub Privacy – data in foundation, rules/defaults in txn hub Interaction – foundation Notifications – foundation Event mgr – txn hub Evergreen – txn hub Data corruption – txn hub

Agenda Master Data Management Market Update IBM Multiform MDM Strategy – Keep it simple Introduction to IBM MDM Server v8 Key Supported Features Implementation Styles Packaging and Pricing CDI Entry Level Concept – MDM CoreAdvantage Case Studies

Current Challenges in the MDM Market
We are seeing niche vendors in more and more deals Past WCC messaging reemphasizes competitor's messaging One size fits all not as effective Desire to increase volume of MDM deals Difficulty deploying POCs Implementation effort seen as too large and expensive Customer misperception that one vendor fits one style Customer having limited capital resources to start their projects More than 98% of WCC phase I implementations are Coexistence/Registry and NOT Transactional!

MDM CoreAdvantage Concept
Project team in place building capability Availability expected end of Q1 2008 Built on MDM Server v8 Will be priced via Foundation for MDM Server Pricing Model Leverages Information Server v8 Data Stage for Initial Load, delta updates QualityStage for Standardization and Matching Information Analyzer for data analysis Implementation options for multiple phases Each phase less than 2 months/200K

Functional Usage Styles
MDM Entry Level Offering Industry: XYZ Types of Records PARTY ACCOUNT PRODUCT Functional Usage Styles Foundation Indexes & Source Values: party equivalency, native key, product x-ref table, default source value, granular services, contract role Basic Party data & functionality: person, org, person name, org name, identifier, granular data services, large grain services (data centric), data validation engine, data decay Supporting part data & functionality: org type, industry type, party misc values, financial profile (bank accts), person and org demographics, income source, granular data services, privacy data (no rules/defaults) Hierarchy & grouping & relationships: hierarchy, grouping Alerts: notifications, party alert, account alert, campaigns Interactions: interactions Duplicate suspect processing & matching engine: data steward UI, Dup suspect services & tables, Evergreen app, Data corruption mgmt Other: History, D&B Basic account data (reference data): Contract and contract component, billing summary, claims Product Data: all basic services in v8 release Transactional Hub Advanced party data & functionality: LOB relationships, critical data change management (pending), advanced duplicate suspect processing (known duplicate) management, federation services, KYC & needs analysis, ROV, macro role, coarse grain business services, transaction security & user authentication, delete services, privacy rules/defaults, large grain services (business functionality) Events: event manager, evergreen Other: Axciom, Fast Track, ILOG Account relationships Value package management (all relationship services) MDM CoreAdvantage Campaign – foundation Fast track – txn hub? Inquiry only Lob – in txn hub ***Advanced dup suspect – kelvin, simon want it in? Need to confirm why? Txn security & user authentication – txn Data validation – internal val rules + engine (foundation), old external (txn hub)*** Coarse grain – add party in foundation, add contract in account foundation…. History audit DB – foundation *** Acxiom & dnb – foundation *** acxiom in txb hub Ilog – txn hub Data decay – foundation Delete – txn hub Privacy – data in foundation, rules/defaults in txn hub Interaction – foundation Notifications – foundation Event mgr – txn hub Evergreen – txn hub Data corruption – txn hub

How to recognize an entry-level opportunity?
Are you competing against niche vendors(Siperian, Initiate, Purisma,…) Does your customer only need access to basic party data? Is your prospect not requiring bi-directional real-time updates? Does your prospect have severe budget limitations? Is your customer mainly concerned on short term results? Is the scope defined to a single department or LOB? Are there only one or two channels of many being integrated?

Recent Win - Physicians Mutual Insurance Company
Company Overview Life and Health insurance provider Approx 1 million customers Big IBM shop – extensive user of IAA model Competitive Situation Engaged in head to head competitive situation with Siperian Siperian had offered low license price of less than 500K First WCC quote was 1.5 million Siperian already had “verbal” agreement for POC How we won the deal IBM was the preferred choice from a strategic perspective Executed a 4 week POC and stopped Siperian POC effort Gave a competitive license price based on PM requirements Bundled in QualityStage for 356K license price

Classic Example of Style Progression
BUSINESS PROBLEM Guest data scattered across dozens of property and reservation systems Inability to recognize high value guests and target for reward program membership Poor data quality and inability to recognize customers SOLUTION Phase 1 Phase 2 Phase 3 Implementation Registry Registry, Co-existence, Transaction hub Transaction hub, Registry, Co-existence Function Operational Operational, Collaborative Data Guest, reservation Guest, reservation, preferences Guest (deep), reservation, preferences

IBM MDM Server The most experience - numerous proven high volume MDM implementations Ranked as leader by industry analysts The most complete MDM application available to the market - significant out-of-the box MDM application functionality Enables any MDM strategy - simple or the most complex – or anything in between Allows for phased, multi-style, multi-phased implementation Begin with our proven rapid start implementation Evolve to any level of complexity and scale using the same platform, technology and skills

Appendix Case studies

Client Example Consolidation, Co-existence, & Transaction style
Challenge Full understanding of business relationship with clients Need to understand credit risk Improve credit decisioning Improve ability to provide complete Basel II compliance Solution & Components Phase 1 Phase 2 Phase 3 Implementation Consolidation Consolidation, Co-existence Transaction hub, Registry, Co-existence Usage Style Operational Operational, Collaborative Data Party(Person, Organization); D&B data Party, Account, D&B data Customer Profile Customer: Industry: Location: No. Employees: Main Competitors: Annual Revenue: Core Business: URL: Company Background Business and Technical Drivers Solution Impact or ROI Products For More Information IBM Case Study: IBM Reference Database: APPROVED FOR EXTERNAL USE

Guest data scattered across dozens of property and reservation systems
BUSINESS PROBLEM Guest data scattered across dozens of property and reservation systems Inability to recognize high value guests and target for reward program membership Poor data quality and inability to recognize customers SOLUTION Phase 1 Phase 2 Phase 3 Implementation Registry Registry, Co-existence, Transaction hub Transaction hub, Registry, Co-existence Function Operational Operational, Collaborative Data Guest, reservation Guest, reservation, preferences Guest (deep), reservation, preferences Here we have Carlson companies, owner of several prominent hotel chains, knew they were having a problems around access to data, with customer data scattered across dozens of property systems. But, they decided early on that this wasn’t just an IT problem, so, they engaged their business units, to look at how they were affected by inconsistent data. So they really tied to fixing their Master Data problem to key business issues. They wanted to grow their loyalty program, and be able to recognize and indentify their customers across all their disparate systems. They also wanted to be able to understand and track guest preferences… This guest always prefers NS rooms, business traveler, king size bed, premeium mattresses, and maybe on their abiliity to get around, ,may need a handicap accessible room, always prefers a ground floor room, or at least one closer to an elevator,

Low cross selling rates across LOB
BUSINESS PROBLEM Multiple brands from acquired companies – no single face to the customer Low cross selling rates across LOB High costs, operational inefficiencies SOLUTION & COMPONENTS Phase 1 Phase 2 Phase 3 Implementation Registry Transaction, registry Transaction, registry, co-existence Function Operational, Collaborative Data Person customer, name, address, ID, account, data stewardship + privacy preferences (SOR) + Person customer (deep), account (reference data), privacy preferences Here we have Nationwide, Large Us based insurer. Has mulitiple brands acquired from acquired silos, and basically had a typical policy centric, IT siloed IT landscape. So, Nationwide tied their MDM project to several key business inititiatives, ability to cross sell, providing operational effieiencei… So, if I had a property and casualty policy, their was no way to understand that I had a different policy, Property and Casualty is the largest of the existing LOBs..

Inability to effectively cross sell to customer base
BUSINESS PROBLEM Client data fragmented across multiple systems – inability to deliver a consolidated view of the customer Inability to effectively cross sell to customer base Inability to introduce service differentiation and efficiencies SOLUTION & COMPONENTS Phase 1 Phase 2 Phase 3 Implementation Transaction - Retail Transaction - Institutional Transaction, consolidation Function Operational, Collaborative Operational, analytical Data Party (deep), location, account & claims (reference), Party (deep), location, account & claims, insight value scores

SOLUTION & COMPONENTS Phase 1 Phase 2 Phase 3 Implementation Registry,
BUSINESS PROBLEM In the process of implementing new web-based ATMs across the entire banking company. Their existing CIF system didn’t have the ability to store ATM customer preferences without significant costs for changes Need to eventually replace core CIF Integrate with the Banking Data Warehouse for Basel II compliance SOLUTION & COMPONENTS Phase 1 Phase 2 Phase 3 Implementation Registry, Transaction Consolidation, registry Transaction, consolidation, registry Function Operational Operational, collaborative, Analytical Operational, analytical, collaborative Data Party (light), account (light), preferences Party (deep), location, account (reference) Party (deep), location, account & claims, insight Company Strategy: The strategy for the bank is to create a consolidated customer profile and enable customer-centric processing by providing enriched customer data to service and sales processes & applications. Tactical need is the ability to manage “new” customer data that wasn’t managed in the current Customer Information File (CIF) – preference data Long term strategy is to replace the legacy CIF to reduce maintenance costs while preserving existing application interfaces as much as possible Business Problems: SunTrust was in the process of implementing new web-based ATMs across the entire banking company. Their existing CIF system didn’t have the ability to store ATM customer preferences without significant costs for changes, and they needed this capability without the costs SunTrust needed a foundational application to replace their existing core banking CIF system SunTrust needed to be able to integrate with the Banking Data Warehouse and with the existing CIF system for Basel II compliance Solution and components: The Phase 1 solution is to use WCC to manage customer ATM preferences. Phase II is tentatively going to be an infrastructure play that enables other business initiatives, including Wealth Management, Basel II, and others. It will be focused on adding the customer information in the existing CIFs to the ATM preference data housed in WCC. Then, customer value information will be added from a marketing warehouse, and that will be followed by a Wealth Management initiative Components: CDI – WebSphere Customer Center Overview: SunTrust Banks, Inc., headquartered in Atlanta, is one of the nation's largest banking organizations, serving a broad range of consumer, commercial, corporate and institutional clients. The company operates an extensive distribution network primarily in Florida, Georgia, Maryland, North Carolina, South Carolina, Tennessee, Virginia, and the District of Columbia, and also serves customers in selected markets nationally. Its primary businesses include deposit, credit, trust and investment services. Through various subsidiaries, the company provides credit cards, mortgage banking, insurance, brokerage, and capital markets services. Strategy: What problem did SunTrust identify? SunTrust was in the process of implementing new web based ATMs across the entire banking company. In their current CIF system, the bank didn’t have the ability to easily store ATM customer preferences without significant costs for such modifications. What was the opportunity cost of the problem Provide ability to store and manage customer’s ATM preferences Provide foundational application to replace existing core banking CIF Provide integration with Banking Data Warehouse and existing CIF for Basel II compliance it when they did v. waiting (what is the compelling event) Need to support ATM rollout with appropriate customer functionality How did they solve the problem before their IBM purchase? Had been using existing CIF for all customer system of record needs. The CIF contained more than 80% of their customers and had point to point connections to over 70 different systems. What solution alternatives did they evaluate? Evaluated Siebel UCM and in-house build WCC was selected due to: References CDI functionality Data Model SOA Services Architecture Competitors sales tactics Siebel greatly discounted the price Tried to sell at upper executive level Why Did Sun Trust Choose IBM? Ability to create CDI infrastructure for future projects Discussions with references Financial Services experience Completeness of product around Data Model and Services Quick Overview WCC Enablement for Phase I: Manage customer ATM preferences WCC Enablement for Phase II: Infrastructure play that enables other business initiatives, including Wealth Management, Basel II and others. It is focused on adding the customer information in the existing CIF to the ATM Preference Data. Then customer value information will be added from a marketing warehouse followed by a wealth management initiative. WCC Functionality: Party Person Organization Location Groups Contact Methods Misc Values Contracts Contract Roles Privacy Preferences What was the business case benefits for MDM Benefits were entirely IT driven Provide ability to be system of record for ATM preferences Enable other bank customer centric initiatives Basel II Wealth Management CRM

BUSINESS PROBLEM SOLUTION & COMPONENTS
Customer and policy information scattered across multiple applications and lines of business Needed to shift operational focus from product-centric to customer-centric Inefficiencies in sales and back-office systems due to redundant processes SOLUTION & COMPONENTS Phase 1 Phase 2 Phase 3 Implementation Transaction – LOB 1 new business processing Transaction – Additional LOB 50+ apps integrated where IBM is system of record Transaction, Co-existence style for smaller LOB Function Operational Operational, Collaboration Data Party (deep), account (policy), product, location

BUSINESS PROBLEM SOLUTION & COMPONENTS Phase 1 Phase 2 Phase 3
Customer and policy information scattered across multiple applications and business units Lacked consistent practices for data cleansing and matching with application-independent rules and processes Need single customer view for web-based account management, privacy management, and improved compliance and cross-selling SOLUTION & COMPONENTS Phase 1 Phase 2 Phase 3 Implementation Transaction (new business) Transaction, Co-existence Function Operational, Collaborative Data Customer (location, privacy); Mutual Fund (account) Customer (location, privacy), Org; Mutual Fund, Policy

Notice The MDM Pattern? Simultaneously address multiple requirements
Initial MDM Deployments Implementation Approaches Customer Success Function Domain Business Value Co-existence Transactional Operational Customer Party Account Streamline new business process to increase revenue and retention Registry Transactional Account/policy Product Capture preferences to increase customer retention and revenue Operational Collaborative Customer Party Registry Co-existence Guest Location Party Enhance customer identification and service across all hotels and brands Operational Location Product Consolidation Co-existence Operational Collaborative Customer Supplier Hierarchy Location Enhanced sales and executive planning via complete relationship understanding of customers and suppliers Registry Transaction Customer Account Party Operational Collaborative Increased ability to cross-sell/up-sell, while reducing IT related costs Co-existence Consolidation Product Location Supplier Collaborative Automated and streamlined New Product Introduction processes

IBM Master Data Management Master Data Management Server v 8

Similar presentations

Presentation on theme: "IBM Master Data Management Master Data Management Server v 8"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

IBM Master Data Management Master Data Management Server v 8

Similar presentations

Presentation on theme: "IBM Master Data Management Master Data Management Server v 8"— Presentation transcript:

Similar presentations

About project

Feedback