MDM Business Scenarios

This is the kind of post I would like to see more of on SDN, business scenarios presented as a demonstration point that we are, in many cases, no longer selling just application products or tools but rather business process strategies. In many ways I hate the term “business process” because I just think we have used it to death, but I have to also admit that for what the vast majority of businesses are dealing with in their day-to-day operations there is no better term than business process. MDM is an incredibly important product for SAP because it cuts to the core of what we do as a company, manage master data, but it is also representative of a competitive flash point in that SAP’s MDM product encapsulates a fundamentally different strategy for dealing with master data than Oracle’s data hubs. Therefore, if you are buying into what we are offering you are implicitly buying into our strategy for managing your master data.

I asked Kosin Huang, who works for me and has done extensive work in this MDM area to comment on the differences in ideology. Here are her comments:

SAP’s MDM approach is to primarily synchronize and harmonize data, letting BPP or SAP solution modules retain their individual master data persistence. This is different from Oracle’s DH approach, which dictates DHs as the only master data storage. It does not allow EBS modules to retain master data persistence. In this way, Oracle had ambitions to control all master data in an organization, regardless of what systems they had, SAP or otherwise. This centralized hub and spoke model however, is highly inflexible and has its weaknesses. Oracle realized this and recently changed its product plans to shift all DH technology to the Siebel platform. This move improves upon Oracle’s DH offering because Siebel lends a federated or distributed master data management approach, where any installation can be a master and any installation can be a slave. This approach is more similar to SAP’s as it allows flexibility in adapting data management to whatever business process flow the customer wants.

If the customer wants its CRM system to be the single source of creation for customer master and the one that retains all customer records, then that is easily enabled. The rules for data mapping, data distribution, and data validation for source and destination systems are easily defined as processes for managing data. The customer would not have to continually ping the hub for master data any time updates or changes need to be made. While these are Oracle’s future DH plans, currently the DH product is still based on old Oracle technology. Oracle will likely maintain the old DH product as it develops the new Siebel-based product.

Another really good blog to read on MDM topics is Andy Hayler.

SAP Developer Network Blogs:

In the part 1 of this series, I have given emphasis on differentiating between global and local data definitions for a Master Data Process. The new process should follow certain norms as ‘best business practice’ as well certain features that are made available by latest MDM tools.

Technorati Tags: , ,

8 thoughts on MDM Business Scenarios

  1. “In this way, Oracle had ambitions to control all master data in an organization, regardless of what systems they had, SAP or otherwise.”

    This is simply not accurate. Oracle Data Hubs provide a mechanism for synchronization of master data and are built for that use case. We may disagree on what product does it better- Oracle or SAP’s – but there is a hardly a hub-and-spoke vs. whatever debate here. The Oracle Data Hubs are based on the latest Oracle technology and even if the technology were ‘old’- that issue is orthogonal to the architecture.

    (The views expressed here are my personal opinions.)

  2. While is it true that Data Hubs allow synchronization of master data, is it NOT TRUE that part of the Fusion plan is (or at least was) to make Data Hubs the command and control center of data for Fusion apps? Is it NOT TRUE that EBS modules lose master data persistence? Because that is what I am saying here. At the last Openworld, Oracle said that “all modules of the eBusiness Suite will discard their own database schema for master data and access the appropriate data hubs directly”…if that isn’t a centralized “hub” like model, I don’t know what is. Now, the direction Oracle is taking constantly shifts so heck, this hub and spoke debate really isn’t a debate because we’re really talking about the Siebel product now. That’s the product that has legs. That’s the product that has sold successfully. That’s the product that merits an acquisition.

    …But just the mere fact that Oracle has made an executive decision to abandon its Data Hub product in favor of Siebel’s speaks volumes about which technology is better. It’ll be interesting to hear what the new plans for DHs are at the next OOW in October…I will bet there is a downplay of Data Hubs in favor of UCM and probably a decision to discard the “HUB” moniker in “Data Hubs.”

  3. “While is it true that Data Hubs allow synchronization of master data, is it NOT TRUE that part of the Fusion plan is (or at least was) to make Data Hubs the command and control center of data for Fusion apps? Is it NOT TRUE that EBS modules lose master data persistence?”

    No, it is not. And no, it is not. And capitalization won’t make it so either. But I am glad you like Oracle|Siebel UCM- the company paid a lot of money for it. :)

    (These are my personal opinions. The careful reader is advised to visit Oracle’s official website to read Oracle’s strategy and vision.)

  4. In reading Oracle’s official website to understand its strategy and vision, Larry himself has explained how Data Hubs work:

    “We’ve created a live repository of information – be it product information, customer information… It’s a way to get some of that information in one place by creating a single place of record.”

    With the customer data hub, all the data you need to make intelligent decisions is stored in a single database whether you’re in a single global instance of the Oracle E-Business Suite or you have a data hub at the centre of lots of separate systems.”

    As a business, I would not necessarily want to create a single place of record for all of my data in Data Hubs…I’d want to retain my financial record in my ERP or my customer record in my CRM. Larry also alludes to a centralized “Hub” database approach — in his words: “data is stored in a single database…at the centre of separate systems.”

  5. Actually, I have a typo…I meant to say the first quote is Chuck Phillips’ and the second quote is Larry’s. So they both agree…

  6. I think it is unrealistic for any large enterprise to expect to store all its master data in a single place. Apart from anything else, most large companies have multiple applications: they have SAP perhaps, but also some Peoplesoft and a bit of Siebel, and, well actually quite a few other things as well. Maybe there are some exceptions out there, but not in the large companies I have worked with. Hence while Oracle or SAP would love to push the other out of large accounts, this simply isn’t going to happen in most cases. For this reason what makes sense is a neutral master data store that catalogues where master data is held in an enterprise, and can map the multiple versions together. Ideally such a repository will have the ability to deal with the semantics of the multipel sources in a meaningful fashion. It is counter-productive for an ERP vendor’s MDM offering to be too proprietary, since customers need a solution that can deal with master data from Oracle, SAP and the whole host of other applications that constitute the real application landscape in a large corporation. CIOs may like a view of the world that show all their apps on one simple Powerpoint, but that is a fantasy in most large companies.

    When I was working as principal technology consultant at Shell this kind of mud slinging between vendors was typical but not useful. Big companies have SAP and Oracle, and IBM and Microsoft (and a bunch of others). They could not switch over to one vendor stack even if they wanted to, as the cost would be prohibitive. What customers need is solutions that work well together.

  7. We did some surveying of Oracle’s advertising campaign against us, overwhelmingly what we heard from CIOs and IT line of business people is that the Oracle campaign reinforced a negative message of the company (them, not SAP). What they want is for Oracle and SAP to work together for the benefit of customers, while at the same time continuing to compete with one another. I don’t imagine this is all that different from car mfg’ers coming together to support a new fuel standard, or to share safety innovations.

  8. Trying to get every company to adhere to one vendor stack, I agree is purposeless, especially in the age of SOA and composite applications where the business process orchestration layer on top enables a company to ignore what’s below, whether it’s SAP or Oracle. But this evolution has only begun and I think MDM is a critical part of it. How will you create services without accurate data? Enterprises will require MDM to maintain a single version of the truth of master data in order to flexibly compose services.

    In concept, of course MDM is about reconciling data admist a hetereogenous environment. But in product execution, vendors have left much to be desired. SAP, Oracle, IBM and formerly Siebel alike all struggled with finding the right approach to MDM. I think it is still evolving. Oracle’s idea to include the entire EBS schema in its DH product is a generation one vendor mistake. SAP had started down that road and realized its inflexibility and quickly turned around. Why should a customer be whetted to using the EBS data model, or for that matter, that of R/3? Customers want flexibility and I think the vendor that can supply it will be a step ahead in MDM and SOA.

Comments are closed