In PLM vs ERP we looked at how hard PLM-ERP discussions and integrations can be and why it is so. Here is a 10-step approach for how to get a typical PLM - ERP integration in place.
A very important assumption here is that we have got PLM and ERP, IT and Business people into the same room and they understand each other. The driving force is the business and what they need to do their job efficiently. These 4 groups must be involved in most of the activities.
Note also that the steps are in a logical order, but clearly not sequential. All steps will be iterated several times and an agile approach is recommended.
1. Objective & Ambition
The single most complex and yet important task is to agree on what we want to achieve (business needs and benefits) and what ambition level we shall have. This will require process walk-throughs where the overall business process is covered and all stakeholders give their input. It is important to understand and agree on a high level:
What does the business need?
2. Information Architecture (Data Model)
Now we know the high level needs from the business. The next step is to agree on a more detail level what information we are talking about. An integration requires very good quality of the data. It is not enough that the data on both sides are almost the same. They have to match 100%.
This is also an exercise to ensure that the PLM, ERP, IT and Business people understands and agrees.
Build a data model showing the data elements (objects) and how they are related (relationships) that focuses on the data that is to be shared between PLM and ERP. Ensure that the Part, The Item, The Material or whatever you call it is understood and defined in the same way across all PLM, ERP, IT and Business people and in the PLM and ERP solution. Continue and do the same with the metadata.
Too often this is not the case when you look into the details. Use real examples and look into the IT tools, follow the processes to build a common information architecture you can agree on.
3. Information Flow
Now you know what information to manage. The next step is to detail where it flows. Where is the information created, updated and used on the PLM side and on the ERP side? Is the information only enriched as it goes through the processes or can it be changed? Are there exceptions to the information flow? Is there a clear transfer point in the process?
4. Business Rules
This step is of course not done isolated. It is done together with the others steps and gradually understood, detailed and defined. The purpose of this activity to look at certain rules that has to be followed and/or built into the integration to ensure data and process consistency.
Some simple examples can be: Transfer bottom-up and transfer only released data. When a new revision is released: Transfer again. There are typically also more advanced business rules that has to be applied to support the way you are working and using the information. E.g. you might convert data in the transfer based on several parameters, you might transfer to different ERP systems based on certain criteria, etc.
5. Processes
The processes has of course been addressed all the way. This is though the step to detail and finalize the information related processes. What are the processes that do at least one of the following:
6. Transfer Mechanisms
The next step is to decide what triggers the transfer of information. You must decide the information carrier and what triggers the transfer. There is something in your data model that groups the information you want to transfer in one go. It can be a Part with its children or it can be an ECO and its released Parts that shall be transferred from PLM to ERP. Or it can the Part itself with cost information to be transferred from ERP to PLM.
There is also a point in your process when the information is in such a state that it can and should be transferred. The data is mature, it is deemed correct and it will not change. If it changes it will be transferred again.
7. Data mapping
Part of data mapping is done together with the data model mentioned above. This is for the remaining details. Different tools and to some extent different processes have different terminology for the same thing. This is the detailed activity of mapping all data fields in PLM and ERP that are to be transferred.
8. Data ownership
Data ownership and Master Data is linked. You must decide what data is originated where and owned by whom at what point in the lifecycle. Data ownership might change as the process moves forward. That is ok as long as there is consistency and you always can trust the data you are using.
9. Integration Technology
Usually this point is mostly influenced by the existing methods, tools and guidelines already present in your company. Modern PLM and ERP tools are quite open and flexible when it comes to integration – Maybe not as much as we would wish though. You want to avoid building point to point integrations and focus instead on some kind of integration engine that gives you more future flexibility. Usually you don’t start from scratch. Some building blocks are probably available from the PLM or ERP supplier or from the integration engine.
10. Technical Implementation
If you have done the previous 9 steps thoroughly it should be quite straightforward doing the technical implementation. You now know what you want and how you want to achieve it. You need someone who knows PLM, someone who knows ERP and someone who knows the integration technology. And most important: You need someone with the knowledge and understanding gained in the first 8 steps to follow the implementation.
Summary
PLM can be ERP best friends. They complement each other and make each other stronger. Sometimes they argue, but it is always possible to get to an agreement.
The data, processes, principles and mechanisms to ensure that you get the data you need in a consistent manner is the challenging part of a PLM-ERP integration. As long as you know what you want you will be able to implement it.
A challenge is that PLM and ERP overlaps more and more and it might be difficult to find and define the integration points in the process. The picture below from PLM Technology Guide illustrates this well.
Tore Brathaug
www.infuseit.com
A very important assumption here is that we have got PLM and ERP, IT and Business people into the same room and they understand each other. The driving force is the business and what they need to do their job efficiently. These 4 groups must be involved in most of the activities.
Note also that the steps are in a logical order, but clearly not sequential. All steps will be iterated several times and an agile approach is recommended.
1. Objective & Ambition
The single most complex and yet important task is to agree on what we want to achieve (business needs and benefits) and what ambition level we shall have. This will require process walk-throughs where the overall business process is covered and all stakeholders give their input. It is important to understand and agree on a high level:
What does the business need?
- What processes goes across PLM and ERP?
- What information should flow in these processes?
- What users are impacted?
- What type of information is needed across the systems?
- Is it a one-way or two-way transfer?
- How often must the information be transferred?
- Is there a clear owner of the information or does it change over time?
2. Information Architecture (Data Model)
Now we know the high level needs from the business. The next step is to agree on a more detail level what information we are talking about. An integration requires very good quality of the data. It is not enough that the data on both sides are almost the same. They have to match 100%.
This is also an exercise to ensure that the PLM, ERP, IT and Business people understands and agrees.
Build a data model showing the data elements (objects) and how they are related (relationships) that focuses on the data that is to be shared between PLM and ERP. Ensure that the Part, The Item, The Material or whatever you call it is understood and defined in the same way across all PLM, ERP, IT and Business people and in the PLM and ERP solution. Continue and do the same with the metadata.
Too often this is not the case when you look into the details. Use real examples and look into the IT tools, follow the processes to build a common information architecture you can agree on.
3. Information Flow
Now you know what information to manage. The next step is to detail where it flows. Where is the information created, updated and used on the PLM side and on the ERP side? Is the information only enriched as it goes through the processes or can it be changed? Are there exceptions to the information flow? Is there a clear transfer point in the process?
4. Business Rules
This step is of course not done isolated. It is done together with the others steps and gradually understood, detailed and defined. The purpose of this activity to look at certain rules that has to be followed and/or built into the integration to ensure data and process consistency.
Some simple examples can be: Transfer bottom-up and transfer only released data. When a new revision is released: Transfer again. There are typically also more advanced business rules that has to be applied to support the way you are working and using the information. E.g. you might convert data in the transfer based on several parameters, you might transfer to different ERP systems based on certain criteria, etc.
5. Processes
The processes has of course been addressed all the way. This is though the step to detail and finalize the information related processes. What are the processes that do at least one of the following:
- Goes across PLM and ERP
- Trigger transfer of data
- Ensures consistency
- Engineering Change process
- The Part release process
- EBOM to MBOM
6. Transfer Mechanisms
The next step is to decide what triggers the transfer of information. You must decide the information carrier and what triggers the transfer. There is something in your data model that groups the information you want to transfer in one go. It can be a Part with its children or it can be an ECO and its released Parts that shall be transferred from PLM to ERP. Or it can the Part itself with cost information to be transferred from ERP to PLM.
There is also a point in your process when the information is in such a state that it can and should be transferred. The data is mature, it is deemed correct and it will not change. If it changes it will be transferred again.
7. Data mapping
Part of data mapping is done together with the data model mentioned above. This is for the remaining details. Different tools and to some extent different processes have different terminology for the same thing. This is the detailed activity of mapping all data fields in PLM and ERP that are to be transferred.
8. Data ownership
Data ownership and Master Data is linked. You must decide what data is originated where and owned by whom at what point in the lifecycle. Data ownership might change as the process moves forward. That is ok as long as there is consistency and you always can trust the data you are using.
9. Integration Technology
Usually this point is mostly influenced by the existing methods, tools and guidelines already present in your company. Modern PLM and ERP tools are quite open and flexible when it comes to integration – Maybe not as much as we would wish though. You want to avoid building point to point integrations and focus instead on some kind of integration engine that gives you more future flexibility. Usually you don’t start from scratch. Some building blocks are probably available from the PLM or ERP supplier or from the integration engine.
10. Technical Implementation
If you have done the previous 9 steps thoroughly it should be quite straightforward doing the technical implementation. You now know what you want and how you want to achieve it. You need someone who knows PLM, someone who knows ERP and someone who knows the integration technology. And most important: You need someone with the knowledge and understanding gained in the first 8 steps to follow the implementation.
Summary
The data, processes, principles and mechanisms to ensure that you get the data you need in a consistent manner is the challenging part of a PLM-ERP integration. As long as you know what you want you will be able to implement it.
A challenge is that PLM and ERP overlaps more and more and it might be difficult to find and define the integration points in the process. The picture below from PLM Technology Guide illustrates this well.
www.infuseit.com
