Prologue:
The B2B bust never happened. It’s a return of ideas. MDM 5.5 could potentially bring the concept back to life. It is the strategic decision that SAP would take in the future with MDM that would prove to be the trigger for a B2B resurrection. There exists today a substantial gap between the promise and the reality of collaborative commerce unlike what was touted in the late 90s. Visionaries always wanted us to believe that we will all soon be connected to vast, virtual, paradigm-changing digital public marketplaces & start collaborating. Like the X-Files, these marketplaces were supposed to be “somewhere out there”, we were never supposed to know where or when. From these initial thoughts are derived a set of key capabilities and requirements which may be used in the evaluation of specific collaborative commerce implementation technologies.
And more importantly, understanding the space or having a single platform vendor address business needs, not just technological, and not looking at MDM 5.5 as a lone, disconnected product as is seen by many today. Well connected and making sense. Virtual collaboration that allows the business processes of a customer’s value chain partners who are linked through the Internet, and the knowledge that is available would be exchanged throughout the value chain for a specific industry vertical with universally accepted identification numbers. Virtual collaboration is a means to increase efficiency while maintaining or even reinforcing uniqueness, a solution that now seems to be within reach with the integration of MDM in the SAP NetWeaver platform. And thus, the improvement scope for an organization broadens from reducing costs to increasing revenues, accelerating time-to-market and enhancing customer satisfaction.
A new form of virtual interaction is added to our comprehensive platform model: collaboration. Naturally, this will increase the complexity of the partners’ interactions, which are now mostly limited to informational and transactional interactions with customers who are attempting this initiative with MDM 5.5 today. At first, collaborative interactions between organizations need to focus on the operational level - upon establishing virtual links between the business processes involved. With EP as the front-end and a little bit of flexibility with SP02 proves this. Let us call this the e-Integration stage. SP02 will at least assuage MDM 5.5 users with its display abilities through the enterprise portal. This may be followed by a second collaboration stage: e-Partnering, in which the value chain partners would extend their collaborative interactions to tactical and maybe, even strategic levels. For this, the interaction with BI 3.5 would make sense. The opportunities created by such virtual collaboration are immense, especially in the area of composites. Let us try to see how MDM 5.5 in conjunction with GDS and industry specific needs will shape the vertical nets of the future as an integral part of the netweaver stack and help us define a case for MDM to carve a road ahead with ESA for an organization that is exploring such a possibility towards collaborative commerce.
Blast from the past:
An eMarketplace could be a business destination, which provides a broad offering of products, services and content as well as a venue for business transactions electronically including exchanges and an eProcurement is purchasing of materials, mainly indirect materials or services through an electronic Exchange. MDM 5.5 would be a great solution for catalog management and syndication for the same. In the past, these used to be advanced excel based tools to create .cif files for catalog management.
Buying and Selling of direct materials, finished goods, services come under eMarketplaces. eMarketplaces most often include an exchange as part of their services. For example, a marketplace might offer catalogs, Negotiations, and an exchange in addition to a number of supply chain services. (A combined digital marketplace of Ariba Marketplace and Ariba Dynamic trade) The core engine for the same is an advanced catalog management engine – something like the MDM 5.5 solution.
Name calling: Exchanges, eHubs, iHubs, e-Markets, Trading Networks, e-MarketPlaces, NetMarkets etc. etc. etc.
Resurrection of the e-marketplaces?
Early adopters across the value chain had experimented with a variety of new business-to-business commerce models, technologies and application designs. At the same time, there was always a growing demand for new standards to facilitate the exchange of information, catalog content and transactions between buyers and sellers. While the methods have been numerous and complex, the underlying goal has remained the same: to bring buyers and sellers together with an automated flow of information and transactions, while still supporting individual business and contractual relationships between trading partners, but for small collaborative chains and inherent players as depicted in our storyboard. The essence of the B2B boom now gets carried forward, except now there is a promise of reality.
The Extended Enterprise Concept now gets stretched to become an Extended Collaborative Enterprise. And the case of logical composites become:
1. Design: Product conception and design for New Product Introduction (NPI)
2. Planning: Determine product mix and quantities based on demand forecast and manufacturing capacity
3. Sourcing and reverse auction: Identify and select suppliers and negotiate and establish purchase contracts with suppliers
4. Marketing & Sales: Market and create demand for new and existing products
5. Manufacturing & Inventory Management: Work with sourcing to maintain low inventory levels and manage an efficient just-in-time (JIT) process
All these have one element in common – master data. A virtually connected extended collaborative enterprise, which the original initial players could not manage owing to a myriad of technological platform with no master data management backbone.
The Matrix Evolution:
First-generation digital e-marketplaces with the sell-side as one supplier and many buyers and the second-generation ones with the Buy-side with one buyer and many suppliers had vendors like CommerceOne, Ariba (ex-tradex), FreeMarkets (now Ariba) and others commerce solutions had fallen short of this goal with the top down approach they had, compared to the bottom-up approach with SAP NetWeaver. They had limited their focus to either the buy-side or sell-side of the equation, without truly understanding how to bring buyers and sellers together into small collaborative chains. The other shortcoming was, despite the concept of Vertical marketplaces having taken shape then, the industry backing behind the key standard bodies was disparate. A stance SAP has changed completely.
This lopsided view of the commerce process resulted in one participant (the buyer or seller) inappropriately dictating proprietary solutions or standards to the other. And, in most cases, this strategy did not scale. The next-generation of commerce solutions saw the birth of eMarketplaces. They were specifically designed to enable multi-buyer/multi-seller interaction and collaboration. They provide a common trading hub, where multiple buyers and sellers could come together and conduct commerce without compromising individual processes and relationships among the participants which is best understood by the pictorial depiction of the evolution as below:
The Matrix Revolution: MDM could be the cup of life for e-marketplaces
E-marketplaces and Vertical exchanges never died, it was only a shakeout of the incompetent and a result of nascent technology . E-procurement systems, e-marketplaces and exchanged always rode on catalog management systems. With MDM 5.5 (xCat), it would have ideally provided the perfect catalog management solution to the same. For those who been through the B2B boom and bust, it would not be completely wrong to say that these concepts existed at that point in time, they set the foundation in place. Catalog syndication is not a new concept when we were consolidating MRO items and finished goods to be hosted on the exchanges, marketplaces and e-procurement solutions. Where the B2B bubble failed was the disjoint way in which these solutions with the backend ERP systems. Again, this is only ONE factor. Today, MDM 5.5 (some call it a regression from the MDM 3.0 solution), on the ABAP stack. MDM 5.5 is a standalone application, nothing to do with WAS – pure xCat application, does not hold much promise. But what is important is the vision that one may want to decipher that SAP may be taking with the same. One would presume that the next version (MDM 7.0?) would be on a WAS (Java +ABAP) stack, fully integrated with EP in the true sense using XI and BI (and beyond) for a complete solution.
Some solution architecture thoughts on MDM in your landscape:
(a) Acting as the online hub for catalog management, syndication across the landscape, the master being the source of truth, flexibility for an organization would be rendered to create online stores with ease through the enterprise portal – specific and business partner driven.
(b) Business partner-specific product catalogs published online to help organizations wired exchanges and e-marketplaces providing community specific information like pricing and specifications to create a network of coherent business partners where the data is harmonized within the organization and extended to the partner community.
(c) Synchronization of trading item catalogs with vertical-specific hubs like Transora or UCCNet data pools, using GDS to create a meta-directory of items facilitating the use of industry-specific standards. An Industry specific yellow pages for all materials to be synchronized and used for trading. (This would necessitate the need for XI and BI leading to Analytics and CAF)
(d) Extended Supplier extranets to facilitate reverse auctions, linked up with the e-marketplaces to be considered as xAPPs extended from what pure-play vendors set out towards. These composites need to switch between intranets and extranets to address various processes.
This is where composites need to seamlessly address processes to complete process loops over the extended value chain and this is the culmination of all our efforts with ESA.
MDM 5.5 – Old wine in a new bottle, and it tastes good!
Before we get into the MDM mould and explore some of the details it is important to understand a little on the background on the product evolution. The MDM product was available for the last few years and its last version was MDM 3.0 this product was ABAP based tool with decent capabilities in large scale data integration and consolidation between SAP systems. The problem with this application was that it was way too complicated for a quick implementation and lacked the feel-good factor on the front-end. SAP may have had to decide whether to invest more on development efforts or to buy off another application from a vendor that would be able to provide the missing capabilities. The quest for this tool led SAP towards A2I and their product called xCat(Of course, there would be other strategic thought processes).
Even though the xCat product was intended for product catalog management, it seems to have the potential - both from a conceptual and a technical standpoint – to fit snugly under the SAP NetWeaver umbrella. At first this product was called MDME (MDM Extension) but now it was announced as the MDM official tool by SAP. The MDM5.5 application can help in providing data Modeling , data consolidation, fast data extraction , and decent search capabilities, and it seems realatively simple for installation and implementation (both from infrastructure standpoint and end user experience). Add to this a good experience in business scenario handling for MDM, as it was captured during the years in the “old” MDM development team and the technology which enables one to do complex things with little effort.
Product Catalog Management, doesn’t it sound familiar?
A PCM product would help the catalog manager of a product company manage the different aspects of information about the product. It could be complex with a lot of information to be handled. Every product oriented company has to have its product catalog in order to use it both internally (for manufacturing, purchasing, etc) and externally (customers, suppliers, etc). Complexity could be owing to a product that can be built from several parts, of various configurations, and can be connected to other associated products. In most companies the product information comes from different places in the organization (manufacturing, purchasing, operations, etc) derived from that it is stored in different IT systems to help in:
a. Extracting product information from different source systems
b. Consolidating information and convert different terminology of the same product
c. Providing ways of organizing the information depending on the user group for specific information
d. Providing fast and intuitive search
e. Providing different ways of displaying the catalog – especially, quick publishing online via EP using Java APIs
The Online Laundromat - MDM
Here we need to answer what is Master Data, well if I will try to define it in a simple way I can say that Master Data is descriptive data regarding specific entity. The Master Data is fairly Static and it is not contains transactional information
So Master Data Management systems came to solve those issues, by providing tools for extracting master data from different IT systems, consolidating master data coming from different sources, central Management crosses IT systems and master Data Provisioning from and to the different IT systems in the organization. The PCM is just a private case of MDM with some extensions like printing catalogs or image management.To ensure that we progress towards the b2b vision, the MDM 5.5 comes in useful when you need to define a generic/flexible data model that is able to pull in data from different sources to have a consolidated source for all master data. Then comes the job of cleansing the data across organization (find duplicates , find similarities ,define transformation rules, etc) in the master server and finally create slaves to help use the data and uses personalized access to Master Data according to end user profile (progress is already up for review with SP2 and finally synchronize the Master Data with different systems holding equivalent information (something that may not be possible today) However, the speed of accessing the data with MDM 5.5 is nothing short of phenomenal, especially when it comes to large number of records.
The Plug Ins (QuarkXPress and Adobe InDesign) come in very handy in publishing catalogs are part of the PCM scenario’s supported by this tool, the Image Manager is for handling Images usually kept in products context and the Plug Ins are meant for publishing the product catalog in different ways. Customers without an MDM solution till date have been trying out all possibilities to handle this. Sample third party applications containing this data which needs to be integrated via the enterprise portal as part of a POC. Add to the the java APIs which can be used by organizations to create their own storefronts. Now, this is an area which has to be put in place by SAP very fast. Imagine customers with an MDM solution in place creating web applications in IBM Websphere or any other application server to create their on static web-stores. Of coursem this is a technological solution, but if falls completely out of sync with the bigger picture with SAP. It is debatable whether this approach is good or not.
The Management Console
The console is primarily intended for two roles – The MDM administrator which deals with connectivity, accessibility, security, etc and the other, The MDM modeler, for creation and maintenance of the object/data model as defined according to business needs.
An Stop-gap arrangement for XI – Bring on the Import Manager
With limited data sources to deal with, the Import Manger is today meant for importing data from several data-sources (can be relation DB, can be excel-sheet) in order to define and population of the data model. With this, one can define the rules for importing data into the model according to the source structure. To assist in aggregation of data from electronically format (the source), transforming the same using rules, rationalizing and normalizing the data to finally have a clean set of data without having to do any coding is where the punch lies.
Of course, it has always been a point of debate on the usage of XI 3.0 for the same. But if it is a one-time load (which is not the idea here), it makes no sense. It is like using a Cadillac for buying groceries. Once the entire landscape is in perspective with the master and the slaves defined, along with data upload and distribution strategies in place, XI starts making sense. It has to come in sooner or later as the landscape will move towards GDS (it the vertical is retail) with 1SYNC today, along with the mandate for the usage of BI and Solution Manager in the landscape. But it is the need today that should define the IT strategy. Maybe not stop-gap at all.
A Stepping stone towards ESA – The Syndication Manager
The Syndication Manager is the component that knows how to exchange data with other systems, meaning this tool will be the one that will handle the synchronization between the MDM storage and the source systems. The syndication manager will not do it alone but it will warrant the use of XI in order to provide a robust way for interacting with the myriad systems the client would have in the landscape. Then again, this is an area which will have explored in detail before an solution can be proposed.
Content Manager
The content manager is what the end user needs to maintain and work with Master Data. Also known as “the client”, it finds its use in fetching data in the most intuitive way across users working on the same data model. In reality, the workflow feature for adding, changing and flagging for deletion the master data is not something that The workflow to manage the master date stored in the MDM (add, change, flag for delete), supposedly to be with workflows (a .exe file available with SP02, which is currently being explored in-house) should really set the ball rolling.) may work. If it doesn’t provide the desired results, there are options to get this in place – create customized iViews for changing and deleting records, create a custom workflow engine integrated with EP to handle this or use webflow, or use a third party workflow engine. MDM being deployed on WAS would be very useful indeed from an integration standpoint.
The invisible men - MDM Java APIs
The MDM5.5 server exposes API both for java and Microsoft applications (.Net and previous) that enables your applications to use the data and functionality provided by it. Due to the fact that most of the MDM5.5 functionality is done in the server, every thing that you can do from one of the clients above you can do from your applications via the API. API for ABAP is being developed as we speak and will be available in the near future. Now, the point that needs to be kept in mind is – how does one, as a Solution Architect, influence the decision of having this on-line web-store within the boundaries of SAP Applications?
GDS and Vertical Nets:
The next step of the solution makes sense when we bring in the vertical industry specific nets into the picture. And this is the area when XI and BI start making sense in the big scheme of things. Leading one to believe that MDM 7.0 (Or whatever), would be an application deployed on WAS (Java and ABAP) soon and xCat would soon be a thing of the past. When we extend our solution as an on-line marketplace with or without SRM/EBP with MDM to publish catalogs on an online store with the Java APIs on an application on or not on WAS, it may not help an organization derive the true business benefits of collaborative commerce with what SAP has on the anvil. Extend this with GDS and the RFID concept and that is leads one to the concept of resurrecting B2B exchanges.
Epilogue:
This is something that may or may not happen in toto. But it is logically possible. And with the SAP NetWeaver platform in place, MDM 5.5 does become the backbone for these c-chains in the future. Conservative companies will be in a position to reach out to their business partners in a collaborative manner with minimal investment. The emergence of 1SYNC, the transition of Transora from a B2B marketplace running Ariba Marketplace, an e2open with Dynamic trace…..the new IT landscape layout and the orchestration of the various elements that would render the usefulness of ESA. Afterall, wasn’t SOA a core concept with the B2B boom? This is where ESA begins. More on this topic on my next blog
No comments:
Post a Comment