Master Data Management With SAP Supplier Relationship Management
Content
Master Data Management with SAP Supplier Relationship Management
Master Data Management with SAP Supplier Relationship Management
Summary
This article describes the evolution of the SRM Catalog. Author(s): David Marchand Company: SAP Labs Created on: 11 May 2007
Author Bio
David Marchand works for SAP Labs in Palo Alto as SRM product manager for catalog and master data management. David started with SAP France 10 years ago as an MM consultant, then moved to Walldorf at the end of 2000 when SAPMarkets was created. In early 2006, he moved to Palo Alto. Through all these years, he has kept his French accent, which makes any of his presentations rather fun to listen to. David holds a MS in Engineering and an MBA in supply chain management.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1
Master Data Management with SAP Supplier Relationship Management
Table of Contents
Summary.......................................................................................................................................... 1 Author Bio ........................................................................................................................................ 1 Start with a bit of strategy…............................................................................................................. 2 Focus on SRM Catalog.................................................................................................................... 4 SRM-MDM Catalog, your preferred solution ................................................................................... 4 SRM-MDM Catalog main process steps ......................................................................................... 5 Migrating to SRM-MDM Catalog...................................................................................................... 5 Conclusion ....................................................................................................................................... 6 Copyright.......................................................................................................................................... 7
Start with a bit of strategy…
Arguably, any observer of catalog management market over the past years has noticed the evolution of both technology and market demand. I am not sure which one is driving the other, but certainly the catalog management functionalities requested in 2000 are significantly different than the ones of today’s market. Catalog management software solutions have followed the typical Geoff Moore path, from pure innovation to commoditization and retirement. We have seen significant market consolidation over the last 2 to 3 years, where leaders of yesterday do not even exist today. Some players have been acquired every year, several times in a row. Independent players, after surfing the lucrative wave of “let us have fun on the web” (i.e.: years 999-2001) during which the use case was to publish suppliers provided content on a catalog search engine, have consolidated over the years 2002-2005 and tried to provide cheaper Total Cost of Ownership solutions, preferably with more integration with operational systems (typically procurement systems). From an architecture standpoint, the right move was to plug a catalog engine next to the procurement application. At the same time, independent software providers had to look for other potential revenue streams. Most of them tried to market a variety of data management services. But on the typical range of commodities addressed with a procurement focused catalog engine, the business case is far from being lucrative. Which customer would spend a cent on cleansing its MRO catalog data? Probably none, or at least not too many. The business case failed miserably. For now, and I believe this is going to persist for the next few years, SAP customers consider their catalog items data as a flavor of their master data, resulting of the consolidation of externally sourced content (i.e.: suppliers) and internally sourced data (i.e.: multiple procurement systems / supply chain systems). There are no reasons anymore to manage catalog data in a different way than any other type of master data. Furthermore, as it relates to software development, there is no need to run a catalog engine next to the application which consumes the data (such as procurement or ERP system). The right approach, from a total cost of ownership (TCO) / architecture standpoint, is to run the catalog engine as a service shared across the entire landscape. In other words, we are witnessing the combination of 2 moves: 1. Catalog engine becomes a functionality of a master data management system, and not a system on its own anymore 2. Master data management systems do not run on the application layer, but on the platform layer, which is located underneath, as a service shared to all applications.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 2
Master Data Management with SAP Supplier Relationship Management
This is crucial to understand. On the same master data management (MDM) system, different type of master data can be stored, managed and consumed (example for procurement business processes: catalog items with suppliers, products and categories). The applications which consume these master data (such as SRM, ERPs) share the master data across the platform. Catalog items are considered as a flavor of master data and are now an integral part of the master data management strategy. From a software solution offering standpoint, SAP had to make a number of decisions to address this significant market change. Basically, after the years during which SAP offered a partnership solution bundled with our e-procurement solution (B2B, EBP, SRM), it has been decided to go for the fully integrated / very low TCO solution (i.e.: SAP CCM) that can be deployed as an add-on to the ABAP layer. This would have been a good move, at least up until market demand changed 180 degrees (this is a U turn, not a temperature). So at the end of 2005, we, from the SAP SRM group, have decided to accelerate the adoption of SAP Netweaver MDM. As catalog items are a form of master data, the concept is to use a master data application to run a catalog engine. Primarily, MDM as a SRM catalog (namely SRM-MDM Catalog) is the showcase of the adoption of MDM by the SAP SRM application. Many other MDM based scenarios will follow. Here are listed the ones which are being developed as we speak:
•
SRM 2007: Duet “simple buying”. MDM is used a product catalog engine searchable from Microsoft Outlook when the user creates a shopping cart. SRM 7.0: Supplier registration and qualification. MDM is used a central hub for all supplier data shared across the landscape (ROS. SUS, SRM server and multiple ERPs). Purchasers will be able to consolidate, harmonize and distribute the supplier data within the landscape. SRM 7.0: Supplier Directory. MDM is used as a directory of suppliers which can be connected to SRM thru the Open Partner Interface (OPI).
•
•
We will have many opportunities to discuss these scenarios with more details. If there is one point to go home with, this is to consider SAP MDM now as a strategic component of your SAP SRM application, and far beyond the simple product catalog scenario. This is true for SAP SRM, is also true for other mainstream SAP applications. This is not a well kept secret that SAP CRM may soon adopt MDM as well, although no dates or precise plans have been communicated yet. At least, I do not know them with sufficient details to share them with you. The value of Netweaver MDM is then decupled (which means multiplied by 10 – not to confuse with “decoupled” as many of you could think…), as the SAP applications are on their way to adopt it with standard, high value integration scenarios. I have been told the license fees will not be decupled, which makes the model even more attractive! But for sure current MDM strategies may need to be revisited. Recently, I had the opportunity to present the SRM 7.0 supplier registration scenario to a top-class SAP customer, who is currently running as many MDM projects are there are master data types. The discussion, which is still ongoing, rapidly turned into a debate: Should we promote a central master data management deployment, or an application driven MDM deployment? On one side, suppliers are centrally created once in MDM. MDM has to syndicate out the supplier data to the applications (SRM and eventually multiple ERPs). On the other side, the creation of the supplier is initiated by the end-user (a supplier online or a purchaser) directly into the application (SRM). The supplier data are then replicated into MDM, which keeps track of key mapping across all the other applications. Which one deployment should be chosen? I believe the pragmatic answer is both. The 2 deployments do not overlap but complement each other. As a matter of fact, the central creation scenario is a subset and simplified deployment of the other one. I
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 3
Master Data Management with SAP Supplier Relationship Management
believe it is necessary to enable a great flexibility in deploying one or the other. Later on, during the ASUG/SAPPhire conference in Atlanta, I could confirm with other customers this is the right thing to do.
Focus on SRM Catalog
We launched SRM-MDM Catalog v1.0 in restricted shipment on September 18th 2006. We invited our very first customers for complementary trainings (VIP lunch and dinner included) in Palo Alto and in Walldorf. Projects have rapidly started afterwards. We also trained a bunch of SAP consultants and partners, with a newly dedicated training course, which will soon be made available on the SAP Education framework, under the code SRM270. We met our internal Key Performance Indicators (KPIs) earlier than expected and have decided to end the restricted shipment period 3 weeks in advance, on December 8th 2006. Since that date, the software has been downloaded in average 9 times a week by distinct customers (not inclusive internal or partner downloads). As we speak, software has been downloaded 202 times and we report at least 34 projects ongoing, based on the traffic on OSS. Some of these customers have gone live already and are sharing their experience at SAPPhire US and EMEA this year. As far as I could see, following in details most of these customer projects, the efforts vary from 30 days to 100 days to migrate from a previous catalog solution to SRM-MDM Catalog, for an duration of 3 to 4 months in average. SAP partners, such as Bristlecone (bcone.com), Inquera (inquera.com), EDS, Accenture, IBM and others are investing on the solution and send some of their good consultants to the trainings we have organized. I would like to thank them for their trust. I believe these are the kind of partners who do not hesitate to adopt new solution earlier than others. Not a secret why they are leaders in their respective domain of expertise. The first projects on which they are involved are successful. I trust many other partners will follow soon. Partners are very important to the success of our joint customers.
SRM-MDM Catalog, your preferred solution
Moving forward, I would like to give you a few hints on why SRM-MDM Catalog should be considered as your preferred catalog solution:
•
Because I tell you. At the end, being the product manager of all SRM catalog solutions, I have made my choice. So why not picking my pick? More reasonably, SRM-MDM Catalog offers, even with v1.0, a significant level of functionality, which is for sure much better than SAP CCM 2.0, and most if not all other third party catalog solutions I know (and I know many of them) Netweaver MDM is itself a mature solution. Some people could say this is due to the fact SAP has not built it on its own… (Just kidding)…SAP acquired the solution from A2i in 2004. MDM was being marketed for quite some time already. In other words, there is no reason to believe the solution is not mature. For the particular SRM catalog scenario, the only portion of the code which is new is the search engine end user interface. This consists of a set of a dozen of screens which have been specifically developed to standardize the SRM catalog search experience. It is the first step of your global MDM strategy. For sure, any customer has to solve the master data problem. Why not starting with the easier part, product catalog, to get familiar with the MDM solution, and then expand towards a more global adoption of MDM on other type of master data. When you learn SRM-MDM Catalog, you know most of MDM.
•
•
•
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 4
Master Data Management with SAP Supplier Relationship Management
SRM-MDM Catalog main process steps
A standard catalog process consists of 6 steps: 1. Manage the repository: A repository is a placeholder in which your catalog data reside. Within a repository, the catalog items are modeled (SAP delivers a predefined data model). The administrator, with a more functional role here, has the ability to make a number of decisions related to the repository: which new fields, tables should be created? How many users do we need? Which roles? How many concurrent taxonomies, hierarchies and schema do we need? Which administration procedures should be run? All these tasks are managed with the SAP MDM Console 2. Import and Map: This is the process step in which the data, from different sources and of different types, are loaded into the repository. The SAP MDM Import Manager is the client module the content manager works with, if he likes to perform this step manually. Alternatively, the SAP MDM Import Server is capable of doing the same tasks automatically, repeatedly and as a background process. Among other tings, the content manager has the ability to map the source data to the repository catalog items data structure, using quite advanced mapping techniques. Not only are the fields mapped, but also the values, which can be split, normalized or converted as being mapped. Work can be saved in the form of maps, which can be re-used afterwards, in the same repository, or transferred to another repository. An advanced key mapping technique, relying on the concept of remote systems, may be found very efficient to map different sources of content to a unique data structure. This enables simultaneous maintenance of multiple keys for the same object, in respect of the multiple sources. As an example, a catalog item 4711 (for some reasons, most of examples or demos in SAP literature refer to the code 4711. If you know the reason why, send me a mail. The th 4711 good response will win a free training on MM module of SAP R/3 4.0b). So, the catalog item 4711 could be coded as ABC in ERP1, XYZ in SRM or 123 at a given supplier. MDM will store the matrix of systems and values as key mappings. This a bit complex first hand, but happens to be very valuable to harmonize your data across. 3. Enrich content: Running the SAP MDM Data Manager, one could add structured and unstructured content to catalog items of the repository. This could be images, hyperlinks, pdf documents and so on. Also, items may be moved from one category to another, or be changed massively (e.g.: change the material group of all selected items at the same time) 4. Approve content: Still running the SAP MDM Data Manager, workflows (which are a sequence of steps in a guided procedure) can be designed, using the Microsoft Visio Pro plug-in. Depending on validations (which are rules detecting events such as the increase of price by more than 10% for example), the task to check the price and make a decision (approved, reject) can be assigned to a user or a group of users in the organization. 5. Enable web catalog: This is the last step of the process for catalog managers, who will be able to configure the masks or named searched (as known as views in reference to SAP CCM), the Open Catalog Interface (OCI) settings and the display settings of the user interface (sequence and visibility of fields). 6. Search items: The SAP Java Webdynpro based user interface renders the content of the repository and enables end users to search (and find) items with different search methods, such as keywords search, advanced search, hierarchy browsing, or refinement by attributes and values.
Migrating to SRM-MDM Catalog
Now that you know what SRM-MDM Catalog is capable of doing for you, the very next concrete question is: how to organize a migration from XYZ catalog to SRM-MDM Catalog? First of all, find out how much in a hurry you might be. For example, if XYZ happens to be Requisite Bugseye , you probably know the support and maintenance provided by SAP has ended on December 31st 2006, midnight, Walldorf time (which is CET). The SAP Note 485884 gives you a bit of useful information (I wrote the note…).
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 5
Master Data Management with SAP Supplier Relationship Management
I am sure most of you agree that running a non-supported catalog solution is not a comfortable experience. There is a level of risk associated, even so that particular catalog solution is arguably quite stable and does not necessarily require additional support. I don’t like to create more panic than necessary, but it is highly advisable to think about a migration to, guess what, SRM-MDM Catalog. I know most of SAP customers who know SAP for quite some time do not like to install the first version of any SAP application. Typically, the IT manager would order the installation CDs (which are DVDs now) and give them to his kids to play with. You cannot imagine so much fun you could have with SAP logo-ed DVDs… I have 2 kids and recently ordered the 84 installation DVDs of SRM 6.0…. Although this might be true for some (most) of SAP applications, it happens to not be true with SRM-MDM Catalog v1.0, as so for two reasons: 1- There are no DVDs for SRM-MDM Catalog. The software has to be downloaded from the SAP service marketplace (http://service.sap.com.swdc – Download – Support Packages and Patches – Entry by Application Group – SRM Catalog – SRM-MDM Catalog 1.0). 2- As mentioned a bit earlier, the solution relies on a mature platform. Only the user interface is new. Still, for the ones who cannot implement the v1.0, the v2.0 will be made available (unrestricted shipment) on July 2nd 2007. Which are the key questions to keep in mind? 1- Assuming the business process is clear for all (this is simple catalog management after all), the data model has to be finalized. SAP delivers a predefined data model for catalog items, which can be appended with many more fields and table of a variety of data type, depending on the complexity of the business process and variants. Data Modeling has to be the lion share of your implementation time. 2- Only when the data model is crystal clear, go for a prototype to validate the data model. Gain experience on the loading and mapping techniques. Work on your workflows. 3- Validate the solution with power and key users. Think 3 dimensions: content managers, purchasers, end users 4- Deploy and roll out the solution. Think 3 dimensions: per commodity, per purchasing organizations, per contracts The IT folks may care about deployment models, architecture, available platforms and sizing. To address all these fundamental and very exiting questions, there a very good presentation posted on the SAP service marketplace, titled SRM-MDM_Details. It can be found at: http://service.sap.com/srm - SRM in Details – SRM 5.0 – Catalog Content Management – SRM-MDM Catalog.
Conclusion
As we come to the end of this article, that I hope you found interesting, I would like to collect your feedback. Please send me an email at [email protected], or post a public comment about this article in the forums.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 6
Master Data Management with SAP Supplier Relationship Management
Copyright
© Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 7
Master Data Management with SAP Supplier Relationship Management
Summary
This article describes the evolution of the SRM Catalog. Author(s): David Marchand Company: SAP Labs Created on: 11 May 2007
Author Bio
David Marchand works for SAP Labs in Palo Alto as SRM product manager for catalog and master data management. David started with SAP France 10 years ago as an MM consultant, then moved to Walldorf at the end of 2000 when SAPMarkets was created. In early 2006, he moved to Palo Alto. Through all these years, he has kept his French accent, which makes any of his presentations rather fun to listen to. David holds a MS in Engineering and an MBA in supply chain management.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 1
Master Data Management with SAP Supplier Relationship Management
Table of Contents
Summary.......................................................................................................................................... 1 Author Bio ........................................................................................................................................ 1 Start with a bit of strategy…............................................................................................................. 2 Focus on SRM Catalog.................................................................................................................... 4 SRM-MDM Catalog, your preferred solution ................................................................................... 4 SRM-MDM Catalog main process steps ......................................................................................... 5 Migrating to SRM-MDM Catalog...................................................................................................... 5 Conclusion ....................................................................................................................................... 6 Copyright.......................................................................................................................................... 7
Start with a bit of strategy…
Arguably, any observer of catalog management market over the past years has noticed the evolution of both technology and market demand. I am not sure which one is driving the other, but certainly the catalog management functionalities requested in 2000 are significantly different than the ones of today’s market. Catalog management software solutions have followed the typical Geoff Moore path, from pure innovation to commoditization and retirement. We have seen significant market consolidation over the last 2 to 3 years, where leaders of yesterday do not even exist today. Some players have been acquired every year, several times in a row. Independent players, after surfing the lucrative wave of “let us have fun on the web” (i.e.: years 999-2001) during which the use case was to publish suppliers provided content on a catalog search engine, have consolidated over the years 2002-2005 and tried to provide cheaper Total Cost of Ownership solutions, preferably with more integration with operational systems (typically procurement systems). From an architecture standpoint, the right move was to plug a catalog engine next to the procurement application. At the same time, independent software providers had to look for other potential revenue streams. Most of them tried to market a variety of data management services. But on the typical range of commodities addressed with a procurement focused catalog engine, the business case is far from being lucrative. Which customer would spend a cent on cleansing its MRO catalog data? Probably none, or at least not too many. The business case failed miserably. For now, and I believe this is going to persist for the next few years, SAP customers consider their catalog items data as a flavor of their master data, resulting of the consolidation of externally sourced content (i.e.: suppliers) and internally sourced data (i.e.: multiple procurement systems / supply chain systems). There are no reasons anymore to manage catalog data in a different way than any other type of master data. Furthermore, as it relates to software development, there is no need to run a catalog engine next to the application which consumes the data (such as procurement or ERP system). The right approach, from a total cost of ownership (TCO) / architecture standpoint, is to run the catalog engine as a service shared across the entire landscape. In other words, we are witnessing the combination of 2 moves: 1. Catalog engine becomes a functionality of a master data management system, and not a system on its own anymore 2. Master data management systems do not run on the application layer, but on the platform layer, which is located underneath, as a service shared to all applications.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 2
Master Data Management with SAP Supplier Relationship Management
This is crucial to understand. On the same master data management (MDM) system, different type of master data can be stored, managed and consumed (example for procurement business processes: catalog items with suppliers, products and categories). The applications which consume these master data (such as SRM, ERPs) share the master data across the platform. Catalog items are considered as a flavor of master data and are now an integral part of the master data management strategy. From a software solution offering standpoint, SAP had to make a number of decisions to address this significant market change. Basically, after the years during which SAP offered a partnership solution bundled with our e-procurement solution (B2B, EBP, SRM), it has been decided to go for the fully integrated / very low TCO solution (i.e.: SAP CCM) that can be deployed as an add-on to the ABAP layer. This would have been a good move, at least up until market demand changed 180 degrees (this is a U turn, not a temperature). So at the end of 2005, we, from the SAP SRM group, have decided to accelerate the adoption of SAP Netweaver MDM. As catalog items are a form of master data, the concept is to use a master data application to run a catalog engine. Primarily, MDM as a SRM catalog (namely SRM-MDM Catalog) is the showcase of the adoption of MDM by the SAP SRM application. Many other MDM based scenarios will follow. Here are listed the ones which are being developed as we speak:
•
SRM 2007: Duet “simple buying”. MDM is used a product catalog engine searchable from Microsoft Outlook when the user creates a shopping cart. SRM 7.0: Supplier registration and qualification. MDM is used a central hub for all supplier data shared across the landscape (ROS. SUS, SRM server and multiple ERPs). Purchasers will be able to consolidate, harmonize and distribute the supplier data within the landscape. SRM 7.0: Supplier Directory. MDM is used as a directory of suppliers which can be connected to SRM thru the Open Partner Interface (OPI).
•
•
We will have many opportunities to discuss these scenarios with more details. If there is one point to go home with, this is to consider SAP MDM now as a strategic component of your SAP SRM application, and far beyond the simple product catalog scenario. This is true for SAP SRM, is also true for other mainstream SAP applications. This is not a well kept secret that SAP CRM may soon adopt MDM as well, although no dates or precise plans have been communicated yet. At least, I do not know them with sufficient details to share them with you. The value of Netweaver MDM is then decupled (which means multiplied by 10 – not to confuse with “decoupled” as many of you could think…), as the SAP applications are on their way to adopt it with standard, high value integration scenarios. I have been told the license fees will not be decupled, which makes the model even more attractive! But for sure current MDM strategies may need to be revisited. Recently, I had the opportunity to present the SRM 7.0 supplier registration scenario to a top-class SAP customer, who is currently running as many MDM projects are there are master data types. The discussion, which is still ongoing, rapidly turned into a debate: Should we promote a central master data management deployment, or an application driven MDM deployment? On one side, suppliers are centrally created once in MDM. MDM has to syndicate out the supplier data to the applications (SRM and eventually multiple ERPs). On the other side, the creation of the supplier is initiated by the end-user (a supplier online or a purchaser) directly into the application (SRM). The supplier data are then replicated into MDM, which keeps track of key mapping across all the other applications. Which one deployment should be chosen? I believe the pragmatic answer is both. The 2 deployments do not overlap but complement each other. As a matter of fact, the central creation scenario is a subset and simplified deployment of the other one. I
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 3
Master Data Management with SAP Supplier Relationship Management
believe it is necessary to enable a great flexibility in deploying one or the other. Later on, during the ASUG/SAPPhire conference in Atlanta, I could confirm with other customers this is the right thing to do.
Focus on SRM Catalog
We launched SRM-MDM Catalog v1.0 in restricted shipment on September 18th 2006. We invited our very first customers for complementary trainings (VIP lunch and dinner included) in Palo Alto and in Walldorf. Projects have rapidly started afterwards. We also trained a bunch of SAP consultants and partners, with a newly dedicated training course, which will soon be made available on the SAP Education framework, under the code SRM270. We met our internal Key Performance Indicators (KPIs) earlier than expected and have decided to end the restricted shipment period 3 weeks in advance, on December 8th 2006. Since that date, the software has been downloaded in average 9 times a week by distinct customers (not inclusive internal or partner downloads). As we speak, software has been downloaded 202 times and we report at least 34 projects ongoing, based on the traffic on OSS. Some of these customers have gone live already and are sharing their experience at SAPPhire US and EMEA this year. As far as I could see, following in details most of these customer projects, the efforts vary from 30 days to 100 days to migrate from a previous catalog solution to SRM-MDM Catalog, for an duration of 3 to 4 months in average. SAP partners, such as Bristlecone (bcone.com), Inquera (inquera.com), EDS, Accenture, IBM and others are investing on the solution and send some of their good consultants to the trainings we have organized. I would like to thank them for their trust. I believe these are the kind of partners who do not hesitate to adopt new solution earlier than others. Not a secret why they are leaders in their respective domain of expertise. The first projects on which they are involved are successful. I trust many other partners will follow soon. Partners are very important to the success of our joint customers.
SRM-MDM Catalog, your preferred solution
Moving forward, I would like to give you a few hints on why SRM-MDM Catalog should be considered as your preferred catalog solution:
•
Because I tell you. At the end, being the product manager of all SRM catalog solutions, I have made my choice. So why not picking my pick? More reasonably, SRM-MDM Catalog offers, even with v1.0, a significant level of functionality, which is for sure much better than SAP CCM 2.0, and most if not all other third party catalog solutions I know (and I know many of them) Netweaver MDM is itself a mature solution. Some people could say this is due to the fact SAP has not built it on its own… (Just kidding)…SAP acquired the solution from A2i in 2004. MDM was being marketed for quite some time already. In other words, there is no reason to believe the solution is not mature. For the particular SRM catalog scenario, the only portion of the code which is new is the search engine end user interface. This consists of a set of a dozen of screens which have been specifically developed to standardize the SRM catalog search experience. It is the first step of your global MDM strategy. For sure, any customer has to solve the master data problem. Why not starting with the easier part, product catalog, to get familiar with the MDM solution, and then expand towards a more global adoption of MDM on other type of master data. When you learn SRM-MDM Catalog, you know most of MDM.
•
•
•
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 4
Master Data Management with SAP Supplier Relationship Management
SRM-MDM Catalog main process steps
A standard catalog process consists of 6 steps: 1. Manage the repository: A repository is a placeholder in which your catalog data reside. Within a repository, the catalog items are modeled (SAP delivers a predefined data model). The administrator, with a more functional role here, has the ability to make a number of decisions related to the repository: which new fields, tables should be created? How many users do we need? Which roles? How many concurrent taxonomies, hierarchies and schema do we need? Which administration procedures should be run? All these tasks are managed with the SAP MDM Console 2. Import and Map: This is the process step in which the data, from different sources and of different types, are loaded into the repository. The SAP MDM Import Manager is the client module the content manager works with, if he likes to perform this step manually. Alternatively, the SAP MDM Import Server is capable of doing the same tasks automatically, repeatedly and as a background process. Among other tings, the content manager has the ability to map the source data to the repository catalog items data structure, using quite advanced mapping techniques. Not only are the fields mapped, but also the values, which can be split, normalized or converted as being mapped. Work can be saved in the form of maps, which can be re-used afterwards, in the same repository, or transferred to another repository. An advanced key mapping technique, relying on the concept of remote systems, may be found very efficient to map different sources of content to a unique data structure. This enables simultaneous maintenance of multiple keys for the same object, in respect of the multiple sources. As an example, a catalog item 4711 (for some reasons, most of examples or demos in SAP literature refer to the code 4711. If you know the reason why, send me a mail. The th 4711 good response will win a free training on MM module of SAP R/3 4.0b). So, the catalog item 4711 could be coded as ABC in ERP1, XYZ in SRM or 123 at a given supplier. MDM will store the matrix of systems and values as key mappings. This a bit complex first hand, but happens to be very valuable to harmonize your data across. 3. Enrich content: Running the SAP MDM Data Manager, one could add structured and unstructured content to catalog items of the repository. This could be images, hyperlinks, pdf documents and so on. Also, items may be moved from one category to another, or be changed massively (e.g.: change the material group of all selected items at the same time) 4. Approve content: Still running the SAP MDM Data Manager, workflows (which are a sequence of steps in a guided procedure) can be designed, using the Microsoft Visio Pro plug-in. Depending on validations (which are rules detecting events such as the increase of price by more than 10% for example), the task to check the price and make a decision (approved, reject) can be assigned to a user or a group of users in the organization. 5. Enable web catalog: This is the last step of the process for catalog managers, who will be able to configure the masks or named searched (as known as views in reference to SAP CCM), the Open Catalog Interface (OCI) settings and the display settings of the user interface (sequence and visibility of fields). 6. Search items: The SAP Java Webdynpro based user interface renders the content of the repository and enables end users to search (and find) items with different search methods, such as keywords search, advanced search, hierarchy browsing, or refinement by attributes and values.
Migrating to SRM-MDM Catalog
Now that you know what SRM-MDM Catalog is capable of doing for you, the very next concrete question is: how to organize a migration from XYZ catalog to SRM-MDM Catalog? First of all, find out how much in a hurry you might be. For example, if XYZ happens to be Requisite Bugseye , you probably know the support and maintenance provided by SAP has ended on December 31st 2006, midnight, Walldorf time (which is CET). The SAP Note 485884 gives you a bit of useful information (I wrote the note…).
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 5
Master Data Management with SAP Supplier Relationship Management
I am sure most of you agree that running a non-supported catalog solution is not a comfortable experience. There is a level of risk associated, even so that particular catalog solution is arguably quite stable and does not necessarily require additional support. I don’t like to create more panic than necessary, but it is highly advisable to think about a migration to, guess what, SRM-MDM Catalog. I know most of SAP customers who know SAP for quite some time do not like to install the first version of any SAP application. Typically, the IT manager would order the installation CDs (which are DVDs now) and give them to his kids to play with. You cannot imagine so much fun you could have with SAP logo-ed DVDs… I have 2 kids and recently ordered the 84 installation DVDs of SRM 6.0…. Although this might be true for some (most) of SAP applications, it happens to not be true with SRM-MDM Catalog v1.0, as so for two reasons: 1- There are no DVDs for SRM-MDM Catalog. The software has to be downloaded from the SAP service marketplace (http://service.sap.com.swdc – Download – Support Packages and Patches – Entry by Application Group – SRM Catalog – SRM-MDM Catalog 1.0). 2- As mentioned a bit earlier, the solution relies on a mature platform. Only the user interface is new. Still, for the ones who cannot implement the v1.0, the v2.0 will be made available (unrestricted shipment) on July 2nd 2007. Which are the key questions to keep in mind? 1- Assuming the business process is clear for all (this is simple catalog management after all), the data model has to be finalized. SAP delivers a predefined data model for catalog items, which can be appended with many more fields and table of a variety of data type, depending on the complexity of the business process and variants. Data Modeling has to be the lion share of your implementation time. 2- Only when the data model is crystal clear, go for a prototype to validate the data model. Gain experience on the loading and mapping techniques. Work on your workflows. 3- Validate the solution with power and key users. Think 3 dimensions: content managers, purchasers, end users 4- Deploy and roll out the solution. Think 3 dimensions: per commodity, per purchasing organizations, per contracts The IT folks may care about deployment models, architecture, available platforms and sizing. To address all these fundamental and very exiting questions, there a very good presentation posted on the SAP service marketplace, titled SRM-MDM_Details. It can be found at: http://service.sap.com/srm - SRM in Details – SRM 5.0 – Catalog Content Management – SRM-MDM Catalog.
Conclusion
As we come to the end of this article, that I hope you found interesting, I would like to collect your feedback. Please send me an email at [email protected], or post a public comment about this article in the forums.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 6
Master Data Management with SAP Supplier Relationship Management
Copyright
© Copyright 2007 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.
SAP DEVELOPER NETWORK | sdn.sap.com © 2007 SAP AG
BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com 7
