PLM and ERP – 10 steps on how to do it

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?

• 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?

The PLMuERP Handbook from PLMIG gives a good indication of which topics to address in this step.

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

Crucial processes are the:

• Engineering Change process
• The Part release process
• EBOM to MBOM

If other information than one-way transfer of BOM information is to be managed there will be additional processes that must be covered.

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

PLM vs ERP – the everlasting trench war or the best PLM ROI?

PLM vs ERP discussions have a tendency to end in trench war between the ERP people and the PLM people. If not open hostility, there is little understanding of your opponent. It does not have to be like this. PLM and ERP can live together and make the total outcome better if PLM and ERP has found their roles and co-operate.

 In this blog I am talking about PLM and ERP tools. Not the PLM concept covering many applications and the whole lifecycle.

This is one of the everlasting PLM topics. There are a lot of blogs about this topic. And more will come as this topic will exist as long as PLM and ERP tools exist. Here are some of them: Beyond PLM, The Virtual Dutchman, Engineering (Engineering) and Engineering.com.

Why is PLM vs ERP a challenge?

Traditionally PDM and MRP had clear roles. PDM takes care of the parts and BOM from engineering and MRP takes care of purchasing and production planning. This picture is not that clear anymore. PLM and ERP have overlapping functionality and processes. Both try to handle “all product information”. PLM stretches into the ERP domain with for example sourcing functionality and ERP stretches into the PLM domain with for example CAD integrations.

Another reason is that PLM and ERP are typically owned by different organizations. ERP is owned by the finance-people and PLM is owned by the technology-people. There is difference in culture, focus, language and they often have a hard time understanding each other.

One oversimplified difference is that with ERP you optimize what you have (existing and physical products), with PLM you optimize what you do not have (new products, intellectual property).

How to approach this

The challenge is identifying a clear and not overlapping role for the PLM system and ERP system in your company. The first step is getting the PLM and ERP people into the same room and get them to understand each other. And to see this from a bigger picture. What is best for our company? Can we achieve something better by co-operating and perhaps “giving away” something to the other side?

There are clear benefits if you can get PLM and ERP to work together. Less time entering information again, better quality of data, faster change processes etc. Get out of the trenches and look at the information flow, processes and business needs. Do this without prejudice about where and how to solve it. When you understand what your business needs you can look at a logical flow. Which tools have the best functionality and which roles are supposed to do the work? Don´t make people have to work in both systems and switch back and forth.

Use a top- down approach: What is best for the company; not “how can I build as much functionality into my tool as possible”.

Several of the companies where we have run PLM-ERP workshops with this approach have responded: This is the first time both camps say they understand each other and are agreeing that together they can really improve things.

A typical scenario

There is no single correct answer on what the PLM-ERP set-up should be. The most common solution though is this:

• The parts and EBOM are born and approved in PLM
• The EBOM is transferred to ERP when it is approved
• The EBOM is re-transferred when it is changed and approved again
• MBOM is created in ERP based on the EBOM
• The change process includes manufacturing planning (at least manually)

The next level could be feedback from ERP. E.g. Cost, stock, change implemented, preferred suppliers etc.

Some companies create and give names to parts in the ERP system and others create the MBOM in the PLM system. However, most companies with a working PLM-ERP integration follows the set-up above.

The challenge is anyway the business process, information flow and business rules. Not on the technology side.

Typical PLM-ERP integration tasks

When you start looking on a PLM-ERP integration there are some task you have to do. Here is a typical list:

1. Objective & Ambition – What do you want to achieve? What is the business pain?
2. Processes – Which processes will be covered/changed?
3. Information Flow – What information will be handled and how should it flow?
4. Business Rules – What are the rules ensuring data and process consistency?
5. Data Model – How is the data related to each other? Are the data the same in PLM and ERP?
6. Transfer Mechanisms – What is triggering the transfer? What is transferred?
7. Data mapping – How do PLM and ERP data map?
8. Data ownership – Which tool owns which data at which step in the process?
9. Integration Technology – What integration technology should you use?
10. Technical Implementation – Programming/configuring the solution

The first 8 are business topics, only the last 2 are technology topics. The challenge is on the first 8. If you do those correctly you will find the 2 last ones to be manageable.

Conclusion

PLM - ERP integration is one of the really big benefits you can get from a PLM investment. It will ensure good quality of data and you will reduce the manual effort in data entering.

There is no single right answer to how this integration should be. There are overlapping processes and functionality. Get out of the trenches and find out what is best for your company.

Tore Brathaug
www.infuseit.com