A common seen user requirement for Master Data Management (MDM) solutions is an ability to copy the content of the attributes of an existing entity when creating a new entity. For example when creating a new product you may find it nice to copy all the field values from an existing similar product to the new product and then just change what is different for the new product. Just like using copy and paste in excel or other so called productivity tools.
We all know the dangers of copy and paste and there are plenty of horror stories out there of the harsh consequences like when copying and pasting in a job application and forgetting to change the name of the targeted employer. You know: “I have always dreamed about working for IBM” when applying at Oracle.
The exact same bad things may happen when doing copy and paste when working with master data. You may forget to change exactly that one important piece of information because you miss guidance on the copied data within your system of entry.
Using an inheritance approach is a better way. This approach is for product master data based on having a mature hierarchy management in place. When creating a new product you place your product in the hierarchy where it will inherit the attributes common for products on the same branch of the hierarchy and leave it for you to fill in the exact attributes that is specific for the new product. If a new product requires a new branch in the hierarchy, you are forced to think about the common attributes for this branch through.
For party (customer, supplier and other business partner) master data you may inherit from the outside world taking advantage of fetching what is already digitalized, which includes names, addresses and other contact data, and leaving for you to fill in the party master data that is specific to your way of doing business.
Liliendahl on Data Quality 
Hi Herik,
traditionally, most PIMs work as described. Personally, I find it a very creative yet disciplined mechanism to resolve a lots of interesting business problems.
At the same time, there seems to be an alternative way to think about that. In fact, one may argue that defining a family of products by specifying core attributes (like defining a class in an OO language) is closer to the way retailers and manufacturers think. For example, the family “Watch” would specify the core attributes of a watch e.g. type = analogic, digital, smart, wrist=leather, etc. Any watch created in the system will then be associated with this family (a concrete item can be part of one family or be an orphan) and will inherit those core attributes.
Obviously there will be hierarchies to classify these products but the association to hierarchies would be a way to add/remove new features to the product. In the example above, a marketing classification could be “Spring Campaign 2016” with a node SmartWatch where the marketing team has defined these additional features: free shipping, money back, a new description. Inheritance is implemented for features too. These features are also in relation to the channel where the product will be distributed.
This needs further elaboration but the implications are far more reaching than my summary let’s on.
In many PIMs this can be achieved with workarounds but it is not native i.e. it may be perceived as complex by a business audience.
Hope to find time to articulate it properly – maybe with two pair of hands 😉
Thanks Michele for elaborating on this one. I agree, most PIM systems takes the lead on this functionality compared to more traditional MDM solutions.