implementing a “green-field” mdm - community archive · pdf fileimplementing a...

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com | UAC - uac.sap.com

© 2010 SAP AG 1

Implementing a “Green-Field” MDM

Applies to:

Enterprise Information Management, SAP MDM. For more information, visit the Master Data Management homepage.

Summary

The article explains the business case, nuances & challenges for implementing a “green field” master data management project where the master data is defined & built from scratch.

Author: Ketan Phanse

Company: Wipro Technologies

Created on: 18 January 2010

Author Bio

He has been associated with Wipro Technologies and SAP MDM for more than a year and has completed his Master's in IT and MBA in Systems Management.

http://www.sdn.sap.com/irj/sdn/nw-mdm

http://www.sdn.sap.com/irj/sdn/nw-mdm



© 2010 SAP AG 2

Table of Contents

Introduction ......................................................................................................................................................... 3

Realizing the Need of a New Master Data Object .............................................................................................. 3

Conceptualization of a New Entity ...................................................................................................................... 4

Defining “Models” ............................................................................................................................................ 4

Identifying the Owner ...................................................................................................................................... 4

Basic Characteristics ....................................................................................................................................... 4

Implementing a Sustainable Model .................................................................................................................... 6

Data Collection ................................................................................................................................................ 6

Data Consolidation into MDM ......................................................................................................................... 6

Building a Central MDM platform .................................................................................................................... 7

Lessons Learnt & Conclusion ............................................................................................................................. 8

Related Content .................................................................................................................................................. 9

Disclaimer and Liability Notice .......................................................................................................................... 10



© 2010 SAP AG 3

Introduction

Most of the MDM projects we see are built to address some of the very typical pain areas: multiple sources of master data, poor data quality & duplicity, different business process across geos, multiple owners of master data etc. To address these, we start with consolidation, harmonization followed by a central master data management model.

But, the recent MDM implementation I worked on was very different from the above scenario. It didn’t have any of those “typical” pain areas, in-fact, it had everything opposite: no source of system of data, no data quality issue, no processes for data management & no owners of data. This was a total green-field because the data did not exist itself! One needs to approach such projects with a totally different mindset though we are using the same set of tools like SAP MDM, SAP EP, SAP PI. The flexibility of the tools becomes more important than the functionalities of it. Also, a lot of emphasis & time needs to be given on having the correct data definitions, than the data as they will be defined for the very first time & changing them later become very challenging.

The below article explains the business case, nuances & challenges faced during such an implementation with “Models” as the example master data object.

Realizing the Need of a New Master Data Object

The company wanted to have a standard definition of all there Products across organization. They only had “Product Models” for a limited set of items they sold & the concept of a unique product model did not exist across all divisions. Those which existed did in spreadsheets & powerpoint presentations. Hence whenever the company sold a product, it did not have unique set of accessories, services, warranties etc to offer to end customer.

Further, company was not able to associate sellable materials to the customer facing products. The Marketing team did not have clear set of rules to define a Models when they launched. The Finance team had no attributes to perform analytics & reporting on. In the discovery phase, they also realized they would need to define a sustainable model which can be leveraged across all business units & hence a data governance structure built. It also meant investing in IT infrastructure, data stewards, changing existing processes & hence the foundation needed to be extremely strong to embark on this journey.

All these lead to an agreement within the top management that there is a clear need to define a new master data as “Models”: a set of foundational data elements to describe what the company sold. A core team consisting of business process expert, IT Architect & data steward was founded for this project.



© 2010 SAP AG 4

Conceptualization of a New Entity

Defining “Models”

The very first thing the team did was to set a clear definition of Models. This was the most crucial step as it was important to have a clear concise definition of what we were building & then communicate it across organization. The simple definition the team settled on was: “Models is sold to a customer for a price”.

It was also equally important to define what it was not. It was not transactional finished good (or FERT of SAP Materials), it was a level above finished goods. The basic differentiator between the Models & Materials was:

Models had Features which describe the core capability from a customer’s view. Example: A high-speed color printer with wireless capabilities

Material had Specifications which describe the physical properties of that offering.

Example: 80 pages per minute, 2400x600 dpi, 802.11 compliant

Additional simple rules were set as:

Every sellable material must have a Models associated with it.

One Material can have only a Models, whereas one Models can be linked to multiple Materials.

Models definitions must be used across systems & across all geographies

Models must be defined before its launch

Identifying the Owner

The next step was to identify the owners. Since the data did not exist, neither did the owners. Clearly to have a sustainable model it was important to identify the business owners who would drive this for years to come. Questions like When is a Models created? Who would create the Models? What lifecycles the Models will undergo? Who would decide when to withdraw the Models from the market? were raised across organization & the Marketing Team came out to be the preferred choice for ownership. Having identified the owners was one thing but asking them to devote there time & leadership to this new beginning was all together a different ball game!

These definitions & rules were communicated multiple times by the business process owners across company using newsletters, meetings & messages from the CXO’s. It was a difficult task to get a buy-in from all stakeholders including the material production team, the IT teams, the marketing team etc but it was necessary to get everyone on-board before the. This was the by far the most difficult part of the entire project & more important to a green-field type project.

Basic Characteristics

In parallel, the core team had already started on defining the basic master data attributes of Models.

“Model Id” was identified as the key field for the master data. Rules such as unique, non-multilingual, maximum 10 character length, can be alpha-numeric were defined. Each rule came out as result of multiple debates & discussions.

“Models Hierarchy” was identified as an important part of the master data & the team wanted to leverage a drill-down capability to link the Models. A 3-level hierarchy was defined which encompassed all product lines of various divisions in the organization.

“Features” were defined as the customer facing offerings of the model that would give more details on its capabilities

“Relationships” were identified as another requirement to link multiple Models with each other for generating reports & performing analytics

“Characteristics” were defined as the supporting attributes to a model like its Name, Division, Consumer Segment etc.



© 2010 SAP AG 5

“Multi-dimensional elements” like announce & withdraw dates of a Models in different countries, multi-lingual description etc were identified as part of the Models master data attributes.

Defining an all inclusive list of master data elements is a difficult job especially when there is no existing data which can be leveraged for data profiling. The team needed continuous focus on not to involve transactional or reporting or historical attributes & only have the global master data attributes of Models.



© 2010 SAP AG 6

Implementing a Sustainable Model

Data Collection

A data steward was identified as the responsible person to gather existing data for these fields from various corners of the organization. A simple excel file with multiple worksheets was designed to collate this date. This excel file became our “source of origin”. An IT Architect defined the various system integrations & technical landscape of the MDM system. Decisions like whether to use SAP PI or webMethods, which system should consume this data, what all system changes would be required in each system was identified.

As the data started coming in, new issues came along like if the field is an integer field or a numeric set of values, should a particular field be mandatory or should it have “NA” (Not Applicable) as a value in lookup table etc. These changes required the MDM structure to very flexible & at the same time to understand the limitations of SAP MDM tool capabilities.

Each look-up table was discussed in detail & every value in the lookup table was defined. Many of the work-streams did not use these fields / values but the team managed to convince the business on the benefits of using them across the company.

Data Consolidation into MDM

Till the time above activities was taking place, my role was more of an MDM Business Analyst than a SAP MDM Consultant. Once the above fields were defined by the business, then started the work of using SAP MDM capabilities

Model Id became the unique primary field

Models Hierarchy became a Taxonomy table

Features became the Attributes of the Taxonomy table

Relationships were built using Parent-Child & Sibling capabilities of SAP MDM

Characteristics became either Text or Lookup tables

Multi valued elements became the Qualified tables

Validations & Assignments were developed to support data quality rules.

Since this was an altogether a new set of data, no messaging format or Idoc existed. The IT team defined an organization wide Canonical format which could be understood & consumed by all integrated systems. Based on the XML Schema, syndication maps were built in SAP MDM. But as and how the fields changed, the schema needed to be changed which resulted in change in syndication maps & the webMethods broker side.

Technical challenges were also faced at the consuming system’s end. As these were totally new data elements, the transactional systems also had to modify their process to accommodate them. For example, the PLM system had to create new tables & columns for the Models attributes & also have a small process defined in the system to have the users link Materials to Models.



© 2010 SAP AG 7

Building a Central MDM platform

The Phase 2 of the project involved building a centralized platform for defining & managing the Models & the attributes identified earlier. Using SAP Enterprise Portal, a web based UI was built on top of SAP MDM. The challenge now was to define a simple yet concrete CRUD business process & approval workflows that can best ensure data governance.

Generally, during centralization MDM projects, there exist multiple ERP systems across geographies or business unit & the challenge lies in defining a consolidated single business process in the organization. The issues generally faced in this stage are change management to users & training them to use the new workflows. Incase of a green field implementation, change is not a major issue as there is no existing process. However, the challenge was to develop workflows which all business users could relate to. There is a need for a lot of drive from the top management to enforce & generate awareness of the new MDM system being introduced. To address these issues, the CRUD processes that we built were kept relatively simpler. Also, as the entire master data including the look-up table values were going to be managed from this central MDM repository, there was a need to have CRUD process on look-up tables also. For example, when creating a new Models the user may not find a required value in drop-down & hence would first create a request for the new master value & then once approved, will go ahead with creating a new main table request.

On the technical front, a new system with new data elements with real time connectivity with existing systems brings in lot of challenges. Not all data elements can be seamless integrated with existing systems. For example, though we were able to manage real time syndication of Models, real time syndication of master value data when changed was difficult.



© 2010 SAP AG 8

Lessons Learnt & Conclusion

A green field MDM implementation is very different from a regular MDM project & hence some key things need to be considered throughout the project lifecycle.

More focus on data definitions than the data itself

Strong business leadership to drive the usage of “new master data object” in organization

Readiness of the business team to own & be responsible for additional tasks

Flexibility in MDM design to accommodate changes to data model

Willingness to change exiting IT landscape within the organization

KISS: Keep It Small & Simple

Communicate & keep communicating about the project progress to all stakeholders like business users, IT system owners, DG team etc

The previous decade saw the emergence of Master Data Management as a concept & focused on the core master data objects namely Models, Vendors, Customers & Materials. As MDM matures in this decade & much more agile advanced functionalities get added like those in SAP MDM 7.1, organizations will start moving towards newer objects other than core objects. Some examples can be found here. Many of such implementations will fall in the “green-field” category & necessary to have a clear end to end implementation as well as change management strategy.

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10824



© 2010 SAP AG 9

Related Content

Overcoming Challenges to Master Data Management Implementation

Multi-Entity MDM Enablement

Common Master Data Management Pitfalls to Avoid

http://www.information-management.com/issues/20060401/1051113-1.html

http://www.information-management.com/specialreports/2009_166/master_data_management_mdm_pim_cdi_governance_enablement-10016215-1.html

http://www.information-management.com/issues/20060601/1056284-1.html



© 2010 SAP AG 10

Disclaimer and Liability Notice

This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.

SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk.

SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document.

implementing a “green-field” mdm - community archive · pdf fileimplementing a...

Documents