In continuance to my previous blog on MDM, where we looked upon MDM as an application, a product, or as just another application under the umbrella of SAP NetWeaver that could help resurrect the era of digital marketplaces. In this blog, I will approach the same solution from the other end of the spectrum. From the world of PIM or Product Information Management applications and to link up the same with GDS and RFID and take a look at SAP MDM as another PIM solution and how it can fit into your overall scheme of things. Organizations have not been new to the solution, rather, some of them have been out there for a very long time. Having burnt their fingers with best-of-breed applications facing rough financial weather, this organization (ORGA) is now in the process of evaluating point solutions vis-Ã -vis MDM to leverage the SAP NetWeaver platform to use their existing SAP landscape and other systems to meet these requirements. PIM products have been in existence with great ideas coming from vendors with many different strengths and approaches encompassing enterprise data management/master data management , enterprise content management, Global Data Synchronization services, product life-cycle management solutions, printing and publishing catalog solutions and vertical industry-specific applications. In this blog, I will put forth a part of my study on this subject for Org.A in helping them arrive at an ESA roadmap.
The Evolution of PIM
The PIM application space evolved a few years back along with Web catalog management and print catalog management products merged to extend themselves towards:
1. Extraction and transforming product data. Ensuring that the solution helps in normalizing, classifying and cleansing the existing master data in terms of various attributes and rules specified.
2. Integrating structured product data with unstructured content. Having the application assist in merging structured and unstructured content like long descriptions, images, video clips, and data sheets for items with the items in the same repository.
3. Print/Publishing Catalog content . A need that evolved during this time that needed catalogs to be published online, as paper catalogs and continue as a catalog handling system for digital marketplaces, exchanges and e-procurement systems.
4. Data Synchronization. Synchronization that goes beyond existing data internally within other source or multiple-source systems, but primarily aimed towards global data synchronization with external data pools Transora or UCCnet, or other pools.
5. Advanced Integrated capability. A need that help the solution offer additional functionality, like pricing and promotion management by making use of advanced search, workflow, and auditing/reporting integrated with the existing applications.
The hunt for an ideal PIM Solution in Org. A
1. Enterprise data management, or master data management, as the online Laundromat solution, which entails the process of consolidating, harmonizing and cleansing or enriching the data for distributing reference information based on the nature of master data forms the very core of Org.Aâ€™s needs as it exists today.
2. Enterprise Content Management or ECM to address the managing of various types of structured data and unstructured content such as Web content, documents, digital and media assets, report data, and collaboration objects.
3. Catalog publishing has always been the need of the hour for Org.A (as discussed above) in terms of web-publishing for its online store. This is the starting point for all its initiatives around SAPMDM.
4. Trading Partner Community Management through Global data synchronization (GDS) as Org. A belongs to this vertical, to leverage the CPG effort around the exchange of standardized electronic data, starting with item data. Product data is to be routed through data pools, which need to be connected to a global registry. Org. A is looking at Transora and UCCNet(1SYSNC) as the data provider to help streamline all PIM projects internally.
5. Product Life-Cycle management or PLM as an iterative, technology-assisted process to continually improve the cost-effectiveness and profitability of a portfolio of products within Org.A leading to vertical specific business content usage in the future. Org. A is not looking at a PIM solution that would just offer a catalog management application that would be limited for the use of a few departments within the organization.
From MDM to GDS and RFID
Master Data Management , as the backbone application for Org. A, now with SP02, has to be viewed from a perspective of a vertical industry driven application, unlike the technological solution it may seem to some today. MDM, as an initiative, needs to be viewed from this perspective only, aligning with vertical specific business content through EP, BI and XI, cannot be a big-bang project. The solution architecture involving the orchestration of other applications is what is going to make all the difference.
The alignment with RFID (radio frequency identification), where there is a cautious approach in the industry today, warrants the need for global data synchronization (GDS). In the retail industry, the move does make sense. MDM is required as a stepping stone here as unless complex product management can be taken care of by a PIM application, there cannot be a move in GDS and RFID. As a result of this, the first step that Org. A will take with MDM is to get it online as a web store-front â€“ nothing different that what was the scene 7-8 years back and wait for customers to come. But that is a start point.
The next step is when Org. A will start extending these capabilities to RFID. This step is what Org.A expects to be the step when it starts seeing the results of the investment, The feedback mechanism along with Analytics for the storefront and POS about which products sell, where they sell, and why the sell â€“ based on the categorization of data and the taxonomy that will need to be built in today to help Org.A reap these benefits. Again, point to be noted is where the technological solution becomes a foolish investment and where the business need is justified. It is this need that justifies the understanding of the data models that will need to be built into the MDM solution to make it useful in distribution and not at a product level at the point of sale. â€“ many attributes, many linkages, cross-selling and up-selling needs, justifying the fact that â€“ MDM cannot be a BIG-BANG implementation.
The PIM Solution needed for Org. A
a. The brass-tacks: The PIM process needs a data audit to diagnose the current state of product data and to cleanse, extract, and enrich existing data before putting into use a unified product information master repository. Org.A is not planning to remove all the supply systems of data in the near future.
b. Prepare for GDS: Implementing data management services within Org. A is to prepare for global data synchronization, manage the challenges associated with conflicting product information, more efficiently manage business processes, and create, cleanse, and publish product content. The GDS solution being on top of the Master Data Management platform, which is designed to support data initiatives for organizations that view data as a corporate asset and for organizations wanting to create data-centric architecture provides a good start.
c. Based on ESA: the PIM solution needs to be designed to support the data model and the associated process model for different types of data, such as meta data, reference, transaction, operational, and analytic data. It needs to addresses the uniqueness of Org.A. Industry-specific business content to help them focus on the vertical industry solutions for retail and CPG so that it aligns with the ESA roadmap being designed for Org.A with SAP NetWeaver.
e. Product packaging hierarchy maintenance Org. A is constantly packaging its products in different configurations based on the trading partnersâ€™ demands or for seasonal variations by building up the packaging hierarchy from the bottom up. The PIM solution needs to be designed to enable assortment maintenance as well as to add/delete/correct links among its products to create and maintain packaging hierarchies for productsâ€”such that an individual product could belong to one or more assortments at any point in time, either for seasonal variant reasons or for normal packaging reasons. Relationship dependent data maintenance whether ranging a product nationally or for specific locations, Org. A needs a solution such that is designed to model and maintain information such as transportation parameters and/or pricing information at a group level or at an individual location level.
d. No changes to underlying systems: Product life cycle maintenance needs to address the product information issue by creating an enterprise-wide repository of product content, incorporating GTINs into internal data without changing underlying systems. The application has to have the necessary workflows for managing the life cycle of the product such as introducing a new product, changing and/or correcting an existing product, as well as discontinuing a product temporarily or permanently from the supply chain. This would also involve re-categorizing a product to a different merchandising group, associating the same product to more than one product hierarchy and/or internal hierarchy, and cross-referencing these products to internal item numbers coming from one or more business systems.
f. Data Synchronization & data pools : Furthermore, it needs to be designed to model and maintain business workflows around the complexities of trading-partner-specific price management. Data synchronization – when it comes to internal synchronization of item, party, and price data inside of an enterprise or external synchronization to its trading partners through GDS, the solution needs to be designed to work with leading data pools in the respective Geo (US for Org. A) as well as country-specific data pools that are owned by EAN member organizations by conforming to EAN.UCC prescribed standards, and protocols.
g. An Integrated Solution Integration: The PIM solution needs to interact with and the internal enterprise systems and external data pools. The solution needs to be designed to help Org.A orchestrate an integration strategy on internal bi-directional synchronization, assuming distributed master data management among different applications. The design and focus of this synchronization capability needs to work on top of an existing integration infrastructure and to add value in the business domain and process layer to avoid having to rip and replace existing systems. The scenario with which the Solution Architect brings in XI.
i. Supply chain model maintenance: Viewing a product life cycle in the retail industry includes sourcing and business planning such as merchandising and replenishment in buying and marketing group as well as order management, logistics, and distribution in the supply chain planning group. For Org. A, a product would first go through engineering, then through the planning group leading to Operations for streamlining demand management, supply planning, supplier-network planning, inventory optimization, manufacturing, and fulfillment optimization business processes. Org. A needs a solution that helps it manage and maintain master data of the products it carriesâ€”not only from a pricing and packaging standpoint but also for other planning business processes point of view. This needs for Org.A will be in the next phase to ensure compliance by associating the same products to other key data elements of a supply chain model and supporting data management workflows such as introducing planning items, introducing new stores, supply or vendor calendar maintenance, store assignment for an item, etc.
h. The Online store-front: Org.Aâ€™s business partners need to be a part of the global GDS network to publish/subscribe only national brands through GDS and prefer to have private-label items sent directly as the creation of a small trading network or a c-chain, or to have public information through the network and the remaining information they like to share directly owing to the sensitivity of the information, the PIM solution needs to let Org. A manage and segment business partners based on what they are capable of and based on what they are comfortable withâ€”resulting in the creation of small online hubs or what would be needed to enable master data collaboration across the board.
j. Master Data Organization: A key issue in Org. A today is how to organize the master data. The problem is not new and has been around for a number of years but due to the increased complexity, it has to be planned out better. Unlike MDM 3.0, MDM 5.5, as xCAT, was originally developed to cover master data management within the boundaries of an organization, typically focusing on only the SAP-related master data (A2A/enterprise master data management). With A2i, the outcome of this move can be seen as the release of SAP MDM, SAP MDM Extended and SAP MDM Global Data Synchronization this year as three separate products. Hopefully, all these releases will be merged soon and the result will be a tool that harmonizes the full scope of master data within and across organizations. With the resurrection of B2B interactions, technologies and concepts like the service ESA, RFID, CAF, and industry initiatives like global data synchronization will require not only open standards and integration technology but also harmonized master data across systems.
k. The importance of GDS: It is important to know that Global Data Synchronization (GDS) is the foundation upon which the full benefits of electronic collaboration can be achieved and scaled. GDS is also a pre-requisite for Electronic Product Code (EPC) based on radio frequency identification (RFID). By continuously synchronizing/harmonizing the master data between Org.Aâ€™s systems and trading partnerâ€™s systems, Org.A can ensure that master data is the same in all systems. This can enable global trade, increase data accuracy among trading partners, and drive costs out from the supply chain. The solution needs to address both product information management problems behind the firewall of an enterprise, and addresses the need to synchronize product information with trading partners through an established Global Data Synchronization Network (GDS).
GDS is the starting point, not the end-goal :
GDS is the existence of an infrastructure that provides and facilitates a seamless flow of product information throughout the supply chain and ensures that all business entities within the supply chain use a common product description and classification to establish a consistent process. This also allows for workflow to ensure systems remain synchronised as products continue to change to:
Strategic and Tactical Goals for Org.A:
a. Establish Common industry standards
b. Single Item registry
c. Item synchronization for industry
d. Collaborative transaction management with MDM
e. Collaborative Supply chain management
f. Collaborative sales and promotion planning
g. Collaborative insight and product development
RFID is the next step with GDS and MDM for Org.A and its business partners (Org. B, Org. C and Org. D) to improve velocity and accuracy in their supply chains, while also looking for value improvements through reduced out of stock conditions. High-value product manufacturers as Org. A, are looking for business solutions to reduce the impact of unwanted losses. The product paradigm is out. (Please refer storyboard for â€œCreating a Comprehensive Collaborative Platform with SAP NetWeaverâ€
The road ahead with any solution is not simple and standalone. For laying down an ESA roadmap, it is essential that not only the orchestration between various applications be understood well, the overall landscape be out into perspective. To create a comprehensive collaborative platform, digital supply chain participants need a central data repository to obtain, exchange, and update product information, a roadmap with MDM maybe. Maybe the product may not get you to the end goal today, but itâ€™s a start in the right direction. The new age digital marketplaces and exchanges will rely on dataâ€”data that would range from the RFID transmitted product information at the dock doors of receiving to the alerts that notify of a pending raw material shortage on the manufacturing floor with a common registry that would overlay an industry vertical for industry specific master data. The end-to-end infrastructure needs to be created on the SAP NetWeaver platform as a road ahead with ESA. The are many facets to the above, only a part I have blogged. It leads to the world of linked up systems with XI, using BI and finally leveraging Analytics and warrants the need for creating xAPPs to create small c-Chains to increase value chain efficiencies..
And MDM 5.5 is only a step in that direction. And Org.A is going ahead with it.