Master data has in the last few years gained a lot of traction especially in ERP and CRM domains. One definition of master data is:
“Master data represents the business objects which are agreed on and shared across the enterprise”
source: "ENTERPRISE MASTER DATA ARCHITECTURE: DESIGN DECISIONS AND OPTIONS", Boris Otto & Alexander Schmidt, Institute of Information Management, University of St. Gallen
“Master data represents the business objects which are agreed on and shared across the enterprise”
source: "ENTERPRISE MASTER DATA ARCHITECTURE: DESIGN DECISIONS AND OPTIONS", Boris Otto & Alexander Schmidt, Institute of Information Management, University of St. Gallen
This means that master data can aid the flow of information through corporate processes across domains, and in this context also be seen as vital to the integration between different domains, departments and disciplines. That is if the entities and attributes can be agreed upon.
However, when I’ve worked with engineering companies and looked at engineering master data it has been very important for them to not only agree and decide on the entities (types of information objects), but also to agree on information structures as master data.
This means that for some engineering companies it is important to harness their collective knowledge, and make it available in the way they work (otherwise known as corporate processes).
Examples could be to identify “best of breed” designs, product breakdown structures or project breakdown structures in order to facilitate re-use. This is especially true in companies that have a presence in many countries and also execute their projects with resources from many different parts of the organization with different cultures.
Actually some of the companies that are most eager to push for this kind of master data are the ones that traditionally do Engineer To Order (ETO), that is to say they produce “one-offs”. There seems to be a growing awareness, that even if the project itself is delivered completely ETO, it would be very beneficial and cost effective if smaller parts of it could be standardized (identified as master data and published as such in a catalog for use in other projects and other parts of the organization).
A few weeks ago I participated in the pre-conference workshop at PDT Europe 2015. The topic this year was master data management. One of the conclusions was that it was believed that the biggest difference between product master data management and “regular master data management” was the kind of data that needed to be managed, and that it invoked a need for change management, common data models and governance.
It was also agreed that this need grew with products that have long lifecycles and high rates of service.
So what about you and your organization when it comes to engineering master data? Do you have any experiences, views or thoughts to share?
Bjorn Fidjeland
The image used in this post is by Kineticimagery and purchased at dreamstime.com
However, when I’ve worked with engineering companies and looked at engineering master data it has been very important for them to not only agree and decide on the entities (types of information objects), but also to agree on information structures as master data.
This means that for some engineering companies it is important to harness their collective knowledge, and make it available in the way they work (otherwise known as corporate processes).
Examples could be to identify “best of breed” designs, product breakdown structures or project breakdown structures in order to facilitate re-use. This is especially true in companies that have a presence in many countries and also execute their projects with resources from many different parts of the organization with different cultures.
Actually some of the companies that are most eager to push for this kind of master data are the ones that traditionally do Engineer To Order (ETO), that is to say they produce “one-offs”. There seems to be a growing awareness, that even if the project itself is delivered completely ETO, it would be very beneficial and cost effective if smaller parts of it could be standardized (identified as master data and published as such in a catalog for use in other projects and other parts of the organization).
A few weeks ago I participated in the pre-conference workshop at PDT Europe 2015. The topic this year was master data management. One of the conclusions was that it was believed that the biggest difference between product master data management and “regular master data management” was the kind of data that needed to be managed, and that it invoked a need for change management, common data models and governance.
It was also agreed that this need grew with products that have long lifecycles and high rates of service.
So what about you and your organization when it comes to engineering master data? Do you have any experiences, views or thoughts to share?
Bjorn Fidjeland
The image used in this post is by Kineticimagery and purchased at dreamstime.com
RSS Feed
