Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

Customer and Supplier are NOT Master Data Entities!

This post was prompted when I received some feedback after I ran a webinar on MDM.  The feedback highlights some of the structures and thinking surrounding some MDM ‘solutions’ that, contrary to what they are sold as doing, actually contribute to MDM fragmentation.

Have a read of the feedback and my response and let me know what you think.

“John, It was a nice presentation and very different thought process from the traditional thinking of MDM implementation although I am not convinced on some of theSAP MDM Logo, Master Data Managementconcepts around modelling. I have been using SAP MDM for past 8 years and SAP standards data models are restricted by entities like customer, vendor etc. and never created as a single model for party.

 

THIS ARTICLE HAS BEEN UPDATED AND MOVED TO http://jo-international.com/customer-and-supplier-are-not-master-data-entities/

 

Share the Love

If you liked this post, please share it with colleagues and friends who are committed to improving  Master Data Management in their enterprise by clicking a social media button below.

To follow me on Twitter or Facebook, click on a floating icon at the bottom right corner of this window so that we can stay connected!

Work With Me

If you would to work with me and prevent these MDM Fatal Errors occurring in your enterprise then  email me at john@jo-international.com or Skype me on johnowensnz. I look forward to connecting with you.

Tags:

4 Responses to “Customer and Supplier are NOT Master Data Entities!”

  1. Jim Burtt January 15, 2014 5:57 pm #

    Hi John,

    While your approach to parties is theoretically sound, I have never encountered any company that fully implemented it. Nor have I found any software developers who go beyond the traditional customer, vendor, and employee definitions, largely because most of them deal with a distinct subset of those roles.

    I think you are far ahead of your time. However, I agree with Brian that there must be substantial business justification for people to swim upstream, design their master data correctly, and propagate it to all their systems.

    I have been fighting the good fight for several years with regard to capturing not only the traditional bill-to customer and ship-to-customer roles, but also other parties associated with a sales deal such as end-user, contractual party, reseller, and referral party. Doing so helps depict the structure of complex deals, and it captures information which may be vital to the business, e.g. for upselling and cross-selling purposes. Converting the customer master into a party master has been a slog because there is very little awareness of parties or master data in the business world. Moreover, software vendors only want to implement the minimum mandatory fields necessary to support basic transactions, lending little support for optional fields that support analytical purposes.

    The insurance industry is a great example of where a single entity may play several roles. I have witnessed tremendous need for designing systems to support parties rather than customers. While I can cite examples of customers who are also vendors and employees who are also vendors, the business justification for extending parties to include the P2P and H2R parts of the world has not been compelling.

    I hope to hear much more about companies making progress toward adopting party terminology in the future.

    Best regards,
    Jim

    • John Owens January 15, 2014 8:05 pm #

      Hi Jim

      Thank for you comments. My approach to Parties is not just theoretically sound, it is essential in order to remove this fragmentation from enterprises, as it exposes very many of them to significant commercial risk.

      Some enterprises have already set off down this path by initiating Master Data Management projects dealing with Party. Others have set off and immediately got lost by running ‘Single Customer View’ projects! The irony of the title is painful!

      The real kicker is that many of the suppliers of software that created this rift between the roles of Customer, Supplier, etc. in the first place are now selling MDM ‘solutions’ that will, for a price, remove the fragmentation that their software created in the first place!

      One major way to change what is happening out there is to change the conversations that are taking place both in the workplace and online. Whenever we see an article misusing these terms we must leave a comment pointing out to the author that Customer is not a Master Data Entity!

      Again, thank for the comments.
      John

  2. Brian Jones January 10, 2014 6:44 pm #

    John,

    I think there is a middle ground between the viewpoints of “everything’s an entity” and “everything’s a role.” The goal of modeling in an MDM context should be accurately describing the business purpose of a person / organization (party) and its functions (roles and relationships) within the business. But the reality is accomplishing this while maintaining MDM applications that are cost-effective, flexible enough to change with the business needs, and provide data that is highly trusted by the users.

    So I agree with a role-centric approach, but only to the extent that roles of persons / organizations truly overlap in a business context. Some entities are definitely related and should be modeled as such. Insurance is a great example of an industry where roles overlap more than most and those overlaps have clear value. For example, an insurance company would want to know if an expert witness whose opinion was sought on multiple claims was a beneficiary on other claims and how those claims were resolved.

    But even in insurance, not every relationship has business significance. And many industries do not experience the same level of return on interconnected relationships as insurance. For example, I may be a customer of an airline and I may work for one of their suppliers, but is there business value in that relationship? And is that business value worth the cost of discovering, validating, and maintaining those relationships as roles?

    The subtyping used in the sample model on your website is a good approach–and one supported by Kalido’s Business Information Modeler, which is the heart of our MDM solution. Subtyping related parties allows the common elements, as well as the differences between entities, to be understood effectively which makes validating them cost effective. The Kalido approach to MDM is to use subtyping for roles that are related in a meaningful business context and to make separate entities for roles that just aren’t related to the others in a way that derives business value.

    More information on Kalido’s Business Information Modeler and how it can rapidly build MDM applications that support models along the lines described in your blog and on your website can be found at: http://www.kalido.com/business-information-modeling.htm

    • John Owens January 10, 2014 11:26 pm #

      Hi Brian

      Thanks for your comments.

      On the one hand, you are right that there needs to be business value in identifying a relationship to a party. On the other hand, this is a discussion that only arises due to years of bad, silo systems design. This discussion would never arise if systems had been properly designed to link every commercial transaction (sale, purchase, etc.) to Party as opposed to the pseudo entities of customer, supplier, etc.

      I have had a quick look at Kalido via the link that you supplied. It looks like a nice interface. It would add huge power and data integrity to the tool if you added a Business Function modeler to the front end. This would avoid the need to pull entities and attributes out of thin air as the Business Functions would define all of these and their use across the enterprise.

      Again, thanks for the feedback.

      Kind regards
      John

Leave a Reply