managing master data with kalido 8hosteddocs.ittoolbox.com/ad041505.pdf · managing master data...

Managing Master Data with KALIDO® 8 A Technical Overview September 2004 Andrew Davis – Head of Pre-sales, Kalido Andrew Ellicott – Product Marketing Director, Kalido

© Copyright 2004 Kalido www.kalido.com 2

Table of contents

1 The Master Data Management Dilemma...................................................................3 1.1 Overview.....................................................................................................3 1.2 What is master data and why is it valuable?......................................................3 1.3 Master data management challenges and needs ................................................4

2 Creating a Master Data Warehouse with KALIDO.......................................................6 2.1 What is a Master Data Warehouse?..................................................................6 2.2 KALIDO MDM Architecture..............................................................................6 2.3 The types of data held within KALIDO MDM ......................................................7

3 Managing Master Data with KALIDO MDM ................................................................9 3.1 KALIDO MDM Users.......................................................................................9 3.2 The Consumer - Browsing & Searching Master Data ...........................................9

3.2.1 Searching .............................................................................................. 10 3.3 Providers – Acquire, Edit, Map, Merge ............................................................ 11

3.3.1 Editing Master Data ................................................................................. 11 3.3.2 Mapping................................................................................................. 12 3.3.3 Merging ................................................................................................. 13 3.3.4 Data Acquisition...................................................................................... 13

3.4 Administrators—Model, Publish, Secure.......................................................... 14 3.4.1 Master Data Modeling .............................................................................. 14 3.4.2 Defining Workflows.................................................................................. 15 3.4.3 Security................................................................................................. 16 3.4.4 Publishing and Distributing Master Data...................................................... 16

4 Integrating KALIDO MDM with other systems ......................................................... 18 4.1 Integrating with KALIDO DIW ....................................................................... 18 4.2 Integration with 3rd- party software ............................................................... 18

5 Summary.......................................................................................................... 19 5.1 Real-world KALIDO MDM applications............................................................. 19


1 The Master Data Management Dilemma

1.1 Overview In order to gain insight into and optimize corporate performance, companies make major investments in analyzing business transactions. The context for these transactions—master data—includes information about products, customers, suppliers, regions and other business data. It is the data by which sales, expenditures and other transactions are grouped for business analysis and reporting. To date, there has been too little attention paid to the management of master data. Poor master data in business intelligence results in inaccurate views of business performance leading to millions of dollars in lost sales and cost savings opportunities annually. The problem is most acute within companies that have a history of reorganizations or mergers and acquisitions (M&A); they face issues of reconciling and consolidating master data on an on-going basis. This is not a new problem, yet the issue of managing master data is getting greater visibility due to pressure to increase corporate transparency, accountability, and performance on an enterprise-wide basis. This white paper describes one solution—implementing a master data warehouse using KALIDO® MDM™, a master data management application included in the KALIDO 8 enterprise data warehousing software suite. It is a workflow-driven, web application that enables business people to collaboratively define, consolidate, manage and authorize master data, which helps increase business performance reporting integrity. It accomplishes this without the need to modify the operational (ERP, CRM, SCM, et al) and analytical systems, from across which master data is sourced. This technical white paper explains:

• Master data management challenges

• Key KALIDO master data management concepts

• How KALIDO MDM operates

1.2 What is master data and why is it valuable?

Master data (a.k.a. “reference data”) represents a company’s business vocabulary—the business entities, terminology, definitions and classifications used to describe business information. Master data provides the context for recording transaction data—facts about events in the business. Consider the following transaction: Sales rep, Laurie Murphy, sold 100 dining tables to Rochester Furniture on May 29 for $45,000 at a profit of $15,000. The context for this transaction, the master data, includes who sold what when and to whom. If you lack a definitive list of sales reps, products and customers it’s impossible to accurately analyze sales performance and profitability by those dimensions. As a result, you could lose millions annually due to weakened sales and product line productivity. Master data inconsistencies can cause other problems:

• A “Tower of Babel” scenario where divisions within an enterprise have different nomenclature, definitions and visibility into the business. This results in misunderstanding, operational inefficiencies, weaker customer service, channel conflict and other margin- and agility-lowering effects

• Inconsistent customer, supplier and product IDs across IT systems make it impossible to get a “single view” of customer and supplier relations or product performance on a global basis

• 50% of enterprises surveyed maintain master data separately in 11 or more source systems

• 50% of enterprises surveyed consider master data management to be a high or top priority

• Over 80% of enterprises surveyed plan on centralizing master data management

Source: Tower Group


1.3 Master data management challenges and needs Managing enterprise master data is challenging. To illustrate, consider the following scenario: A global producer of consumer food products wants to analyze profitability trends over the last 2 years by product, channel, customer, brand and region. Challenge #1: Master data required for this analysis (Products, Customers) is duplicated in multiple IT systems (CRM, ERP, etc.) that run independently in each region. It must be consolidated, and inconsistencies must be eliminated. Challenge #2: Some of the master data is outside the scope of operational IT systems—lists of brands and channels are supplied by business users. Extending operational IT systems to support this data enterprise-wide can be prohibitively expensive. Challenge #3: Definitions for some master data such as product class exist in programming logic (such as spreadsheet functions and data transformation routines, etc.) and are therefore inaccessible to users and systems—this needs to be available and controlled by business people. Challenge #4: The accuracy of this company’s profit analysis depends on associations between customers and channels, channels and regions, products and brands, etc. being correct. Master data is inter-related and hierarchical; referential integrity must be validated. Challenge #5: Business users must be integrated into the master data management process—they’re best equipped to reconcile data inconsistencies, contribute missing data, ensure the validity of the data and authorize its use.

Challenge #6: Analyzing trends is difficult—customers merge, products are discontinued, etc., but the operational systems from which master data is sourced reflect the present. Historic master data views must be maintained to support trend analysis and audits. Challenge #7: Different “views” of master data must co-exist to support different business functions. For example, ice cream products are purchased from Good Humor-Breyers, Inc. in the US and from Langnese-Iglo GmbH in Germany. For central supplier relationship reporting purposes, these suppliers map to their parent company, Unilever. A solution must capture and map between different master data views. Challenge #8: Once this master data is prepared, it must be transferable, in whole or in part, to a data warehouse to facilitate profit and other business analyses. It may also be transferred to ETL/EAI systems to update master data in transactional systems for greater operational consistency or for supply chain integration. Challenge #9: Master data is at least as important to people as to systems—it should be made accessible throughout the extended enterprise to increase corporate transparency and help everyone understand far-reaching customer relationship implications and market presence of brands, etc. for efficient operational execution and reporting.

“Master data management is currently handled independently in many separate analytic and transactional systems. The lack of coordination limits the ability for

organizations to accurately track, analyze and manage information about their customers, products and suppliers.”

Henry Morris

VP Applications & Information AccessIDC


Based on common scenarios and challenges like those above, Global 2000 companies are discovering that an ideal master data management solution must:

• Consolidate master data from disparate IT systems

• Support complex master data models

• Be business-user driven to validate the completeness, semantic correctness and referential integrity of master data

• Be business-user accessible to improve business transparency and operational efficiency

• Map between multiple master data views (e.g., global and local)

• Preserve master data history

• Interface with enterprise data warehouses to help ensure business analysis and reporting consistency

• Be easy to implement with little impact on operational systems

KALIDO MDM meets the requirements above, enabling companies to create a central master data “warehouse” and have business users collaboratively control, enrich and authorize master data to ensure consistency and semantic validity. Now let’s see how KALIDO MDM operates.

CRMMasterData

PartnerMasterData

SCMMasterData

ERPERPDW

MasterData

DWMasterData

Master data must be centrally consolidated, stored and managed, independent from source systems

Product

Brand

BrandSub Group

• Size

Product Usage

Target Industry

Product

SegmentCatalog

Line Item

Finished Product• Height• Length• Width

Product Spec

Product Sub Group

Product Group

Product Manager

• ColourProduct

Business users are key participants—they contribute data, ensure semantic validity, authorize use, browse

Product

Brand

BrandSub Group

• Size

Product Usage

Target Industry

Product

Segment

Catalog

Line Item Finished Product• Height• Length• Width

Product Spec

Product Sub Group

Product Group

Product Manager

• ColourProduct

“Master” is relative—multiple views (e.g., central vs. local) must be supported

Master data model

Real-world business model hierarchies and relationships must be reflected—including historical changes

Master data must be transferable to data warehouses and other systems

CRMMasterData

PartnerMasterData

SCMMasterData

ERPERPDW

MasterData

DWMasterData

Master data must be centrally consolidated, stored and managed, independent from source systems

Product

Brand

BrandSub Group

• Size Product

Brand

BrandSub Group

• Size

Product Usage

Target Industry

Product

SegmentProduct Usage

Target Industry

Product

SegmentCatalog

Line Item

Catalog

Line Item


Product Spec


Product Spec

Product Sub Group

Product Group

Product Manager

• ColourProduct

Product Sub Group

Product Group

Product Manager

• ColourProduct

Business users are key participants—they contribute data, ensure semantic validity, authorize use, browse

Product

Brand

BrandSub Group

• Size

Product Usage

Target Industry

Product

Segment

Catalog


Product Spec

Product Sub Group

Product Group

Product Manager

• ColourProduct

Product

Brand

BrandSub Group

• Size Product

Brand

BrandSub Group

• Size

Product Usage

Target Industry

Product

SegmentProduct Usage

Target Industry

Product

Segment

Catalog

Line Item

Catalog


Product Spec


Product Spec

Product Sub Group

Product Group

Product Manager

• ColourProduct

Product Sub Group

Product Group

Product Manager

• ColourProduct

“Master” is relative—multiple views (e.g., central vs. local) must be supported

Master data model

Real-world business model hierarchies and relationships must be reflected—including historical changes

Master data must be transferable to data warehouses and other systems

Key master data management requirements


2 Creating a Master Data Warehouse with KALIDO 8

2.1 What is a Master Data Warehouse? A master data warehouse stores and manages master data independently from operational IT systems. It feeds business-user-controlled master data to enterprise data warehouses to ensure consistent and accurate business performance analysis and reporting. KALIDO MDM is a solution for creating and operating a master data warehouse. It leverages and integrates with the unique adaptive enterprise data warehouse capabilities of the KALIDO application suite and distinguishes itself from other solutions by:

• Integrating business users into the master data management process

• Providing automated and collaborative master data modeling, data entry, validation, mapping, merging and other management capabilities

• Maintaining historic, present and planned master data views

• Enabling employees to browse master data via corporate portals for better business transparency

• Rapidly deploying master data across KALIDO data warehouses and accelerating master data management by importing existing master data and models from KALIDO enterprise data warehouses.

2.2 KALIDO MDM Architecture

Presentation Layer

MDM

IE6

OracleDB2

SQL Server

JSP Front EndJ2EE Container

MDM hub(s)

Browser

Web Services

Database

Windows platform

Cmd Line

COM/Java API

Adaptive Services Core

MDMservice

MDMTasks

MDMMonitor

XML over HTTP (SOAP)

Initiates

C++ interface

EAI Layer

Application Layer

Data Layer

WebServer

ERP DWSCM

Presentation Layer

MDM

IE6

OracleDB2

SQL Server

JSP Front EndJ2EE Container

MDM hub(s)

Browser

Web Services

Database

Windows platform

Cmd Line

COM/Java API

Adaptive Services Core

MDMservice

MDMTasks

MDMMonitor

XML over HTTP (SOAP)

Initiates

C++ interface

EAI Layer

Application Layer

Data Layer

WebServer

ERP DWSCM

KALIDO MDM is web-based and can be rapidly deployed. Its user interface is created with JSP and style sheets, which makes it easy to customize or integrate with portals. Web Service, Java and COM interfaces enable integration with EAI and other systems.

•Merging•Cataloging•Security•Validation•Authorization•PublishingSCM ERPCRM

ETL/EAI

““Golden CopyGolden Copy””Reference Data

ReferenceData

“Harmonized”business

intelligence

Business users browse and

manage master data via the

web

KALIDO® MDM™

•Workflow•Modeling•Searching•Versioning•Mapping•Segmenting

“Master reference data warehouse”

Enterprise Data Warehouses

•Merging•Cataloging•Security•Validation•Authorization•PublishingSCM ERPCRM

ETL/EAI

““Golden CopyGolden Copy””Reference Data““Golden CopyGolden Copy””Reference Data

ReferenceData

ReferenceData

“Harmonized”business

intelligence

Business users browse and

manage master data via the

web

KALIDO® MDM™

•Workflow•Modeling•Searching•Versioning•Mapping•Segmenting

“Master reference data warehouse”

Enterprise Data Warehouses

KALIDO MDM produces a master data warehouse which is populated directly by business users or by loading data from source systems. Users collaboratively review, reconcile, enrich, authorize and export master data to data warehouses or other IT systems, resulting in consistent and accurate business reporting. Master data can be browsed by employees via portals for greater business transparency.


2.3 The types of data held within a KALIDO master data warehouse Understanding KALIDO MDM requires knowledge of how it organizes master data. Master data “Subjects” (such as Products and Customers) are stored by KALIDO MDM along with their associated “Records” and can be versioned using “Contexts.” Master data types, structures and management workflows are defined by “Categories” and “Templates.” This section explains these concepts in greater detail. Subjects In KALIDO MDM, all information is organized as Subjects. Subjects can be anything, but they generally represent real-world business things such as products, brand definitions, customer segments, target markets or business definitions, etc. Records A Record is a set of information about a Subject. It can contain fields of textual data, other attributes or references to other Subjects. Record structures may be simple and flat or richly nested with interrelated subcomponents (e.g. XML style structures.) Records can be versioned, so there may be multiple Records holding different information about the same Subject. Multiple versions of a Record can exist simultaneously (holding different aspects of information), or sequentially over time (to reflect changes that have occurred to real-world Subjects, such as a person moving to multiple departments throughout the year.).

Categories and Templates Subjects are defined by their Category. The data in a Record is validated against a Template defined as part of the Category. The rules defined in the Template can validate the contents of a Record in a number of ways: • Optional or mandatory fields • Valid references to other Subjects • Correct data types • Uniqueness of identifiers

Categories also contain workflow definitions (see 3.4.2) which control the editing, review and authorization of master data by business users (“Providers”). Invalid Records KALIDO MDM recognizes that in building up the information for Subjects, there will be times when, as work-in-progress, data may be invalid in some way. There may be mandatory fields missing, more values present than allowed, references to invalid Subjects, etc. Fields may also be present that are not defined in the Template at all. KALIDO MDM automatically flags invalid data so business users can quickly spot and address issues. Records that do not conform to the Template are said to be Invalid. Validation occurs when Templates or Records are changed, data is imported, or when Subjects of one Category are merged into another.

PeopleCategory

Template {{

This template defines the rules for

validating People subjects

Numeric

Text

Link to Organization

Text (Mandatory)

Tel

Email

Employer

Manager

Subject

Record

J Smith+1 201 555 3459

[email protected]

“Unileever”

A Jones

Tel

Email

Employer

Manager

!

{{

FordCar

This subject is invalid because it has fields

that do not conform to the template

Validates

PeopleCategory

Template {{



Numeric

Text


Text (Mandatory)

Tel

Email

Employer

Manager

PeopleCategory

Template {{



Numeric

Text


Text (Mandatory)

Tel

Email

Employer

Manager

Subject

Record

J Smith+1 201 555 3459

[email protected]

“Unileever”

A Jones

Tel

Email

Employer

Manager

!

{{

FordCar



Subject

Record

J Smith+1 201 555 3459

[email protected]

“Unileever”

A Jones

Tel

Email

Employer

Manager

!

{{

FordCar



Validates


Records may be invalidated because:

1. Source systems do not supply all of the necessary data, requiring users to enter the missing information.

2. Multiple systems hold the same data resulting in multiple conflicting values (e.g., the CRM and ERP systems hold conflicting customer information).

3. Data is supplied in the wrong format

The ability of KALIDO MDM to flag and hold invalid data, and allow users to correct it is a

key requirement for managing master data

Catalogs To make it easy to find and browse master data, KALIDO MDM uses a Catalog and sub-catalog paradigm to organize Subjects. Just like real-world catalogs, Product Subjects, for example, could be grouped in a Product Catalog, which is further organized by Product Line, Brand and Discontinued sub-Catalogs, etc. Searches can be performed within or across Catalogs and Sub-Catalogs. A Subject can belong to multiple Catalogs enabling you to create different views of master data. For example, a product called “Vanilla Fudge Ice Cream” can belong to the “Consumer Product” Catalog as well as the “Ice Cream Product Line” Catalog.

Contexts KALIDO MDM can support multiple, versions of a particular set of Subjects. At any one time, the user works within a Context that represents a particular version of the data. Contexts can also be used to hold subsets of data that is of interest to specific user groups (e.g. Branding Classifications may only be of interest to Marketing).

Subjects and Records can be copied between Contexts (e.g., to create a new version based on a previous one). Users can “Publish” Contexts (see section 3.4.4), thus authorizing the use of the data in data warehouses and other applications and freezing them from additional changes.


3 Managing Master Data with KALIDO MDM

3.1 KALIDO MDM Users There are three main types of users:

• Administrators – Often IT workers, they define master data models, security, workflows and Templates.

• Providers – Business users who collaboratively control, edit, or authorize master data within the context of models and workflows created by an Administrator

• Consumers – Business users who browse and search master data in order to gain greater visibility into and understanding of the business.

The rest of this paper explains how KALIDO MDM operates by illustrating usage scenarios for these users, starting with the Consumer experience.

3.2 The Consumer - Browsing & Searching Master Data Consumers have read-only access to master data. They log in using a user name and password, or use their network ID to log in automatically Once logged in, they select the Context they wish to use, then browse master data by navigating Catalogs and Categories or perform searches. Once viewing a Subject, they can drill up and down links between Subjects.

This shows the information a Consumer would browse. The Consumer is viewing a Catalog under “My Data” that holds a subset of the product data. They can see Packed Products and Brands. Most items have a green check mark to show that they are authorized. Administrators can hide unauthorized data using security if they wish One of them has a red ! to show that the data is invalid – in this case it is missing a Brand Code.

KALIDO MDM supports the full master data management lifecycle

ConsumerRead-only access to all data allowed

by security

ProviderCreate new data, edit existing and authorize master

data

AdministratorSet up the

business model, workflows and

security

Model

Acquire / Create

Enrich

Map

Authorize

Publish

Browse& Search

Security& Admin

ConsumerRead-only access to all data allowed

by security

ProviderCreate new data, edit existing and authorize master

data

AdministratorSet up the

business model, workflows and

security

Model

Acquire / Create

Enrich

Map

Authorize

Publish

Browse& Search

Security& Admin

Model

Acquire / Create

Enrich

Map

Authorize

Publish

Browse& Search

Security& Admin


3.2.1 Searching Consumers can use the following search capabilities to help them find relevant Subjects:

• General search—finds Subjects in a Context that include the specified text in their “Display” attributes (i.e., descriptor column fields that appear on-screen when viewing lists of Subjects)

• Catalog (and sub-catalog) search –limits the search to the Catalog or sub-Catalog currently being viewed

• Advanced search – find Subjects based on detailed search criteria.

This shows the details of a Subject. More fields appear in the detailed view compared to lists of Subjects shown previously. An error message can be seen here indicating a required field is missing. There is also a link between the brand and its lead rep and a definition of the brand—this supplemental information increases understanding of the business among employees who browse the master data. The data owner can be emailed if a problem is spotted with the data.

The advanced search screen has flexible search text options. Advanced search field options change automatically based on the Category being searched. It is also possible to search for invalid records only.


3.3 Providers – Acquire, Edit, Map, Merge Providers are business users who control the accuracy and quality of master data and business definitions within the context of models and workflows set up by Administrators. This section explains the following KALIDO MDM functionality: • Editing master data • Raising change requests • Maintaining time-variant master data • Mapping master data (e.g.,

subsidiaries to parent companies, sales reps to regions, divisional to head-office nomenclature, etc.)

• Merging master data together (e.g., to reflect product line consolidations, customer reclassifications, etc.)

• Acquiring or importing master data into KALIDO MDM from external sources.

3.3.1 Editing Master Data With the correct security, Providers edit Subjects individually or place multiple Subjects in a “basket” and perform bulk operations on them. Providers have the ability to Authorize Subjects and move items through a workflow that has been defined by an Administrator. Providers see a list of issues requiring their attention via a workflow “Inbox.” Typical Provider tasks include: • Creating new master data items • Progressing data items through

workflows • Adding missing fields (e.g. market

segmentation fields not available in the source system)

• Selecting which field is correct if more than one is present after a merge

• Raising or addressing an issue or change request

Change Requests and Issues Along with automatically flagging invalid master data, KALIDO MDM allows change requests and issues to be raised manually against any item of master data. Workflows can be triggered, which highlight issues and change requests to other users. Issues and change requests can be opened and closed by Providers, with appropriate comments.

Here, a Provider edits details for a customer site. They can assign it to Catalogs, select an owner, set security and enter other information. New parent Catalogs can be selected via drop-down lists or via an advanced search (search results are shown to the right). Links in the top right enable Providers to navigate to Inbox, Basket and Deleted Record contents.

This shows an item of master data with an issue raised against it. KALIDO MDM facilitates issue identification and resolution for fast, cost-effective master data management by business users.


Time Variance Fields in KALIDO can be defined as time-variant. This means multiple values are allowed through time, even if the cardinality allows only 1 at a time. Validation ensures that if multiple values are supplied, then they must not overlap their dates or have gaps between dates (depending on the cardinality). This unique capability is critically important to companies who need to recreate historic views of master data to support trend analysis or audits. It’s also useful for defining changes that will or could happen (e.g., for scenario planning).

3.3.2 Mapping “Mapping” is a critical master data management requirement, especially in global companies. KALIDO MDM mapping features help maintain the referential integrity of master data for more accurate business performance reporting and easier information exchange across divisions. Among other things it can help ensure:

• Customers are mapped to their correct regions and sales reps, etc.

• Products are mapped to their correct brands, lines and classifications

• Subsidiary suppliers and customers are mapped to their parent companies

• And so on KALIDO MDM can run custom-defined mapping processes to automatically determine links between Subjects. Typically, child Subjects contain text used by the mapping facility to derive the likely parent in a relationship. The text is a parent ID, or a separate field that holds useful information.

Where a reference is invalid (i.e., the parent cannot be found or none was supplied), it is said to be “unresolved.” References between Subjects are derived using a number of techniques: Field Comparison Matches parent and child Records by finding exact or substring matches in specified field values. Prior Match Checks the supplied text to see if any siblings have the same value and have been successfully mapped; then it maps based on the precedent. Lookup Table Users can provide a simple table of 2 columns with the child values, and the parent value to look for. Automatic mappings result in one of the following outcomes: • A single successful map was made • Multiple possible or inexact matches

were found and the record is invalid until the user selects one of them

• No match was found, and a “no match” workflow can be triggered.

This shows a history of Customer Accounts with which this Delivery Point has been associated. A gap in the history data (for 2003) must be filled to make the record valid

This shows a mapping between Local Products and Packed Products. This mapping compares fields in the two Categories and checks for an exact match.


3.3.3 Merging Merging allows Providers to combine the contents of a child Category into a linked parent Category. Merging can be used to:

1. Stage data before it’s moved into a parent Category

2. Create a unified Category where multiple sub-Categories exist, thus simplifying the model. This helps when multiple sources exist for the same information

3. Add local products into a global catalog

Typically, Merging follows a Mapping process (to establish the parents with which to merge) within a single workflow. When merging, if there are values for a field in both the child and the parent, users can control whether:

• The child’s value replaces the parent’s

• To ignore the child value if the parent has a value

• If both parent and child have different field values, the merge can result in the parent having 2 or more values. This potentially invalidates the parent and may trigger a workflow for the user to select the correct value.

The merge facility supports annotation, which can be used to make it clear in the parent what the source of merged data is.

3.3.4 Data Acquisition Providers can load data into KALIDO MDM from external sources. Data feed definitions are created by a KALIDO MDM Administrator; Providers can execute them. Formats allowed for loading include:

• SOAP / WSDL for web services – KALIDO MDM can be updated by Web Service calls, and the Web Service Description describes the fields available and the format. This is the same process the presentation layer uses to communicate with the KALIDO MDM application server.

• KALIDO XML – allows loading of very detailed information from one file, including multiple Catalogs or Categories, time variant data, and complex record structures.

• CSV and Tab Delimited – these can be used for tabular data such as spreadsheets.

The feed definition allows the loading of fields not specified by the master data model - for example source system key fields can be loaded without having to be defined as part of the data model. Other fields not specified by the model can be loaded (for example if a web service call incorporates a new field), but will be treated as invalid as the field does not form part of the Template. This is easy to rectify, as the model can be amended afterwards to ensure it encompasses the new data, causing a revalidation of the data for the Category.

This is a merge screen that will merge Delivery Points into a Customer Account Category


3.4 Administrators—Model, Publish, Secure Administrators manage the business model, security and workflows. They can also Publish data which locks it from further updates. This section explains the following KALIDO MDM features: • Creating master data models • Defining workflows for Providers • Defining security • Publishing and exporting master data

3.4.1 Master Data Modeling Master data models define master data structure, definitions and relationships. Compared with traditional data models, master data models do not define how master data is stored— KALIDO MDM stores master data in a generic format. Therefore:

• Models can be highly conceptual, and communicate rich business meaning (which is why master data can be readily browsed by Consumers)

• Data can be loaded into the model from disparate IT systems—even if the incoming data does not rigidly conform to the model

• Models can be changed without reloading or reformatting data already stored in the master data warehouse

Models can be created within KALIDO MDM or they can be generated based on models defined within an existing KALIDO DIW enterprise data warehouse. The data model can be changed at any time – Categories can be added, or changed. If a change invalidates some Subjects classified by the Category – for example by adding a new mandatory field that has not been populated–invalid Subjects will automatically be flagged and trigger corrective workflows.

This shows a model being maintained. The Delivery Point Category holds information about the default Catalog for Subjects, security for them, and the workflow. The Template holds the fields and rules for the Records of a Subject. The fields can include references to another Subject in another Category, and their cardinality. Changes to this Template may result in the Subjects being revalidated.


Associations can be defined between Subjects in KALIDO MDM. The association may be a simple hyperlink, or it may be an explicit relationship maintained within the database as a separate association record for easier navigation. Subjects can be associated with multiple possible parents allowing complex relationships to be configured (e.g., an allowed parent could be from a separate Category). Changes to associations such as cardinalities, or allowed parents can be made at any time, resulting in revalidation of the Subjects. The definition of advanced models directly via XML and also via the API is supported. Users can define lists of components with attributes. It is also possible to include conditional validation based on other values in the Record. KALIDO MDM can be used to build rich enterprise master data models. KALIDO MDM supports the structures of a relational database, plus many of the attributes of XML documents such as nested structures.

3.4.2 Defining Workflows Workflows help users manage data effectively and highlight issues, invalid data and change requests to the appropriate users. Workflow automation greatly facilitates master data management by business users and is critical to success when you consider the fact that a master data warehouse can contain hundreds of thousands of data items. Workflows are defined in terms of the following elements:

• States which hold groups of Subjects • State Type which can be one of Edit,

Approval or Matching • State Transitions which can move

Subjects between States • Events which are system-detected

changes

This shows a workflow definition. Events fire when the system detects something has happened – for example a Record Created Event. The workflow then sets the Subject into a Workflow State. State can change when another Event occurs (e.g. Validation Failure) or when the user presses a button (e.g. Reject). States are assigned to a user who will receive Subjects into an Inbox when they login (or via email if configured via the API).

This shows a Recipe Record containing a Formulation sub-component that includes the quantity of and reference to each material in the recipe

When defining new Record attributes, there are many properties to model including Data Type, which can range from simple types such as string and integer to complex types such as rich text, URL, XML Names (e.g. Tag Names) and value lists, etc.


Events Events are very powerful as they highlight issues to interested users for resolution. For example if a number of records are loaded, and some are amended by the load, but others are not changed, the Record Amended Event detects this change and passes the records to users for review and approval. The Events have a priority so that the most important Events are fired first, and they are (in order of priority):

• Change request raised

• Issue raised

• Match required

• Validation failure

• Becomes valid

• Record amended

• Record undeleted

• Record deleted

• Record created Event History As items of data are edited and progress through workflows, a history of these events is recorded. This can be viewed by any user and facilitates auditing and control. 3.4.3 Security Administrators control access to KALIDO MDM and master data. They can define new users and assign them secure login information. Users are also assigned a role: Consumer, Provider or Administrator. The email address can be specified to facilitate communication back to the data owners where appropriate. Administrators can specify that certain information is hidden from, or updating is restricted to certain user groups (or individuals). Security can be cascaded by Catalog, Context, or from a parent so that all security is propagated down from high- level items to their children.

3.4.4 Publishing and Distributing Master Data Publication The publication process allows administrators to close off a set of data (classified by a Context) as a version and prevent further editing by users. This is especially useful for data that is distributed on a cyclical basis – e.g. a new chart of accounts is distributed each month, or a new sales hierarchy is put into production quarterly. Once the data has been published, a new copy is created so that new changes are made in a descendant Context. During the publication process, any change request, issues and all event history is archived and excluded from the published version.


Exporting Master Data Administrators can set up definitions for exporting subsets of master data to a file for loading into other systems. Export formats can be either flat file, or XML in either the KALIDO XML format, or as a Topic Map (XTM). Export Definitions contain a list of the fields of a Category to include in the export file. Destination systems (such as a KALIDO DIW enterprise data warehouse) are likely to only request data that has been validated and authorized. The administrator can set up filters on the export to ensure that only the required subset of the data is exported. If further filtering is required, then there are some sample database views available that allow further constraints to be used against any field required.

Here, an Administrator defines which fields in the Brand Category to include in the export file.

Users can control whether to include unauthorized and invalid records in the export


4 Integrating KALIDO MDM with other systems 4.1 Integrating with a KALIDO DIW warehouse KALIDO MDM can import model definitions and data created in a KALIDO DIW warehouse, and allows export of data back to KALIDO DIW—typically when it has been authorized and published. The import of a model and data from KALIDO DIW into KALIDO MDM is very simple. The user selects the Dimensions, Classes of Business Entity (model), and whether they wish to import the Business Entities (master data), then run the import. The administrator can then set up security, and additional configuration information such as workflows, and default catalogs for the master data. This simplifies KALIDO MDM administration considerably and allows a common core model to be shared between data warehouses and KALIDO MDM. The following KALIDO DIW model definitions are imported: • Dimensions • Roles • Classes of Business Entity • Coding Structures • Measures & aggregated measures • Business Entities (including mapped

but excluding time BEs, which are not typically maintained)

Once the data has been imported, changes to the master data can be loaded back into the data warehouse using the export capability. The export can be filtered to only allow exporting of valid and authorized data.

4.2 Integration with 3rd- party software KALIDO MDM can be used with other software for a best-in-class master data management architecture:

• Data quality tools – perform advanced mapping using phonetic and statistical matching. The output can be loaded into KALIDO MDM for authorization and manual checking. KALIDO MDM users complete matches that were not successfully identified

• Data Profiling –investigate complex or poorly documented source systems and identify a set of extractions to feed into KALIDO MDM

• EAI – load data into or distribute data from KALIDO MDM in real time (e.g., after a user authorizes data in KALIDO MDM, it could be distributed instantly to multiple destination systems)

• ETL – extract and transform large quantities of data between KALIDO MDM and transactional systems on a scheduled basis. Loads can be initiated via jobs or Web Services

This shows some data imported from KALIDO DIW. If entities are changed in the data warehouse, they can be re-imported, and Template definitions will adjust automatically. Once loaded, the Category can be edited to specify user security and workflows.


5 Summary KALIDO MDM is a KALIDO 8 application component, and it uniquely enables business people to collaboratively define, consolidate, manage and authorize master data in a workflow-driven, web-based environment—without needing to modify operational IT systems. The benefits of managing master data with KALIDO MDM and distributing it to enterprise data warehouses and employee information portals include:

• Highly accurate and consistent business performance reporting

• Employees gain greater visibility into the business for more efficient operations

The benefits are achieved through the unique capabilities of KALIDO MDM, which:

• Consolidates master data from disparate IT systems

• Supports complex master data models

• Is business-user driven to validate the completeness, semantic correctness and referential integrity of master data

• Is business-user accessible to improve business transparency and operational efficiency

• Maps between multiple master data views (e.g., global and local)

• Preserves master data history

• Interfaces with enterprise data warehouses and other systems to help ensure analytical and operational consistency

5.1 Real-world KALIDO MDM applications KALIDO MDM supports many strategic initiatives within Global 2000 companies including:

• A financial services company is streamlining global financial reporting by defining and mapping between head-office and subsidiary accounting master data with KALIDO MDM. Central governance gets fast, accurate views of financial performance with less manpower spent on consolidated reporting and without the cost and delay of standardizing accounting nomenclature across the company.

• An international brewing company increased business transparency and operational efficiency across its brand companies by publishing 3,000 business policy and metric definitions, along with customer, product and market master data to employees via KALIDO MDM.

• A consumer packaged goods company is managing hundreds of thousands of customer, supplier, financial, product and other master data items in KALIDO MDM. Business data experts at the head office define central views of the data (including business definitions), and co-workers in other countries map their domestic views of the data into KALIDO MDM to facilitate business intelligence reporting and information exchange across divisions. The information is accessible to employees via a corporate intranet to help everyone gain greater visibility into the business.

If you would like to discuss KALIDO MDM in more detail, see it in action or try it yourself, please visit www.kalido.com.


www.kalido.com

For more information please contact us:I: www.kalido.comE: [email protected]

Kalido25 Burlington Mall RoadBurlington, MA 01803Tel: +1 781 229 6006

Kalido8 York RoadLondonSE1 7NAUnited KingdomTel: +44 (0) 20 7934 3300

Kalido17 Square Edouard VIIF-75009ParisFranceTel: +33 (0) 1 5343 9130

www.kalido.com

For more information please contact us:I: www.kalido.comE: [email protected]

Kalido25 Burlington Mall RoadBurlington, MA 01803Tel: +1 781 229 6006

Kalido8 York RoadLondonSE1 7NAUnited KingdomTel: +44 (0) 20 7934 3300

Kalido17 Square Edouard VIIF-75009ParisFranceTel: +33 (0) 1 5343 9130

managing master data with kalido 8hosteddocs.ittoolbox.com/ad041505.pdf · managing master data...

Documents