Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos
Most organizations have evolved its business practices to suit their key business partners at either end of the supply chain (customers or vendors). To put it in other words, outbound logistics business processes are based around tier 1 customers. While we have the luxury of setting up our inbound processes, certain vendors (for whom we are primary customer), follow the same pattern i.e. they build their business process to suit our needs.  Over a period of time we build a strong bond in this relationship, from the business perspective. Certain customers/ vendors expand business association exceptionally, while others don't. The ever-changing relationship need to be maintained in our system and built into our processes.  So a multi-national organization prefers a vendor having presence in specific countries, for commercial reasons. This necessitates the maintenance of certain global data and quite a bit of local data about the supplier in our system.   Each ERP has its own standards for defining set of 'global' Vs 'local' data. This often is not sufficient for maintaining company specific requirements of data maintenance. Data as simple as contact details of different divisions of the customer / vendor (e.g. productions, sales, Quality, Purchase, accounting division), can not be maintained with one global value in the ERP & need a separate log at local level.  On the other hand, an organization might want to globalize certain fields in Material Master like MRP Lot Size, Rounding profile (which are location specific) and Delivery unit (which is Sales Organization specific). If the norm is set for this, data inconsistencies across various locations can be avoided by maintaining these values centrally.      Using MDM, we can easily make provision to maintain genuine global data centrally, accessible to all the parties (internal customers, business partners) involved. The other data has the option of either maintaining it locally or on MDM server. If we look forward to Central MDM, the location specific values can be build in MDM sub-table for material master or business partner repository, allowing us to have single source of data entry. Any data that need to have a common definition across locations can be maintained in MDM to syndicate unique value to different systems.  The decision to define a given data element as ‘global’ or ‘local’, depends on what is in the best interest of business, at the organizational level. Take the example of defining ‘Credit limit’ for your customers –  In an organization of moderate size, it is OK to define credit limit as a local field (i.e. at Sales org level) which can be closely monitored by local controlling authorities. However for another organization, spread over different geographies, it is imperative to have ‘credit limit’ as a global value, to be monitored systematically. This is more attractive when individual customers are also spread over different countries.  It makes much more sense for an organization with heterogeneous system landscapes, to have a consolidated record of their customers (each customer being uniquely identified across the organization using MDM) with ‘Credit limit’ value completely controlled by MDM. Of-course there is a need to interface such global values, in real-time to the order processing systems (SAP or non-SAP) for validation purpose, using MDM import & syndication.  We can segregate between local and global data to suit specific needs. The content and definition of the master data, maintained directly in ERP system, is primarily governed by the business processes defined, hence imposing limitation on the classification of the data and level at which to maintain a specific attributes.  In the next blog (part 2) of this series we will discuss specific examples of data duplication.