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

Can a true PLM initiative be decentralized?

In a previous blog I was looking for the PLM expert. The conclusion was that implementing PLM is a team effort (which is perhaps not a surprise), as a PLM implementation includes process, tool and organizational aspects. The executing team should possess knowledge within the customers’ business, the targeted domain, and available technology. Strengthened by having a reference group working in the day-to-day business and the support of management.

But we didn’t address the question on which level this “body of expertise” should act. Where should this organization reside, and what mandate should it have?

In short: what would the impact be of having a centralized or decentralized ownership of PLM?

A Decentralized PLM Ownership

From a process and method point-of-view you could probably find reasons to actually move the responsibility from the corporate level and allow local flexibility:

• Risk management through diversification, which would allow business units to try out things which could then benefit others in the organization
• Ownership of your own working methods would potentially allow easier change management
• Less compromises in the way you work and the tools you use in your daily work would probably generate less friction
• Closer to the immediate challenges will allow the organization to be more agile and finding solutions to emerging threats, opportunities and trends

Okay, so there might be good things with decentralized processes and methods. But let’s have a look at what a decentralized PLM (both process and tool) does to some of the (old) core values of P L M:

• Manage Information - Manage data and processes
• Find Information - Search, where used/referenced, process status
• Share Information - Real-time collaboration. Information attached to workflow

Doesn’t a “local” PLM system contradict with those values? I assume it has to do with your definition of local. If it is a site with 5000 employees does it have to be integrated with the rest of the company? It all depends on the business.

But let’s flip the coin completely and look at some more challenges you might find in an environment which has a decentralized PLM ownership:

• No one will be responsible for thinking horizontally and aligning the company across departments and across functions/disciplines
• Each department is measured and rewarded by their own results, blocking a strategic change as this requires an investment
• Hard to have job-rotation and change staff as the processes, working methods and tools differ
• More costly to have an effective tool support as it’s not consolidated
• Less efficiency further down the chain or even loss of opportunities and inability to execute on initiatives completely. In many cases the lack of a common way of doing things is hurtfully exposed once you have a need of unified processes and information at one end while having a diversified way of working and/or structuring and storing information at the other. It works as long as you don’t think of others … Typical initiatives and areas which will put their demands on what and the way information is delivered are: business analytics, procurement, manufacturing, e-commerce, and aftermarket.
• In many cases (to my experience) a decentralized ownership means more “let’s just make it work” which means that the experienced employees will have a way of dealing with things but the new ones will have to “find their way”. Is that really making things smooth and efficient?

Decentralized Processes and Methods but Consolidated PLM Tool(s)

Providing that you believe in decentralized processes and methods but also in the need for a consolidated application support for effective distribution of information you might avoid some of the bullets above. And looking at the core PLM values stated above; “only” the process part might not be accomplished.

The concept of self-organizing teams is not new. It is a great part of the agile software development movement. Isn’t this what we would talk about when we put PLM in a decentralized process environment but with consolidated tools and information, having common PLM tool(s) orchestrate these “teams” to deliver information and use tools in an uniting way?

In such an environment process support might be hard to implement within the commonly used tools, which might not always be a bad thing. Having processes tightly implemented into the IT tools assume a deterministic look at the world, but as we all know the world and the way we work is an ever changing parameter. So this could actually trigger a healthy look at how you architect and build your tool support as it will require modularization and flexibility.

The trap which you might fall into is that the consolidating system will become the “scapegoat” as it will have to unite and be a compromise from an end-user point of view. Also, many regulated businesses don’t have this option. To unite under one proven and compliant process is a matter of necessity and survival for these companies.

Decentralized PDM and Consolidated PLM

A trend we see at large companies is that they move away from one enterprise PLM solution covering everything. We see several examples of local PDM solutions allowing local flexibility feeding an enterprise PLM which has information and processes harmonized, but on a higher and more generic level.

Processes and ”how to do things” (methods or practices if you will) are not the same, and to be able to deliver and consolidate information in a coherent and consistent way “the way you do things” might very well have to be aligned as well. An example of an area which requires this thinking is CAD / CAM. In other words it’s important to understand if you have these type dependency so that you act accordingly in your decentralized PDM environment.

Using a PDM tool closer to the authoring tools will often result in better connection and less translation issues and richer details as a result. But keeping the innovation loops within PDM and consolidate in PLM cements the functional silo as it delays the point in which a cross functional view can be “visualized”.

Conclusion

As I can see it you actually don’t need to centralize everything under the PLM “umbrella”. This is of course a bit depending on your type of business.

Processes and methods should be carefully implemented. You could reap a great deal of benefits by aligning and consolidating tools and information across the enterprise and still allow processes to be more autonomous in nature. One trick is to implement the processes on the right / high enough level (in the applications) which would allow people to work within it, while still keeping important flexibility and agility in the tool. It is important to keep a clear distinction between processes and methods so that you consciously decide what it is that you want the tool to support and what you keep outside it, as this will allow you to adjust the way you work to temporary situations and differences in business models, while still delivering and using commonly structured information and tools.

Are you convinced that one approach is better than the other? What’s your view on this?

Robert Wallerblad
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

Doing Things the Right Way?

In a previous blog, titled Doing the Right Thing, the question was if we would add value if we shifted focus from a processes centric approach when implementing a PLM tool. Today it's time to look at the other side of that coin - why would you want to focus on doing things the right way, or in other words being process centric? And to repeat - the main point here is not to dwell over the question if we need business processes or not, it’s about creating IT support for them in a PLM system, or not.

First of all let’s be frank; it's not necessarily the right way we are talking about, it's more a way; a way that has been chosen as the "right one". The criteria of being the right one could be many; what we know to be the best way at this point in time, a way prescribed by a standard or required to become compliant, or simply something that the stakeholder could agree upon.

So why would we want to implement processes into an IT tool?

• Compliance to different standards and regulations is a huge driving force. Being able to enforce and show auditors that you are following the directives prescribed by a authoring body is sometimes a good enough argument. Having change management, review processes, approval processes, follow-ups, document management, history records, etc supported by an IT tool makes life easier (even if your business isn't regulated), at least if you have the right IT support.
• Consolidate and unite companies/subsidiaries/sites/etc in their way of working it's quite often a requirement for initiatives such as joint manufacturing facilities, sourcing, procurement, eCommerce, PIM, or effective after-market support. But I would dare to say that in most cases it's more about securing the data rather than the processes. Call the cards, and you will probably find that besides the initiatives listed above the motive could be found among the softer aspects of implementing IT support for a process - unification across borders through enforcement, thereby creating the notion of one company.
• Complex development processes which require consolidation and exchange of information across multiple disciplines and organizations will also have a great benefit of harmonizing data and processes using a system to support their tasks.
• Scalable "know how" as it's captured in the tool allowing it to guide people in their work. Phase-in of new employees will thereby be easier if there is process support guiding and enforcing the user in the way they should work.
• Improve and enforce quality as you get control and are able to guide users through the companies working procedures
• Automatisation of process steps will become much easier as we have a repetitive flow of events

So as you can see; there is no "That is the question" in Hamlets monolog. It all depends. There are basically advantages of both approaches. And that is how it is; depending on your needs (some could perhaps be more justified than others ;) you could see the advantages of getting a PLM system to support your processes. But don't take it as something that you have to do! If you start using the approach from the previous post as a "reflex standpoint" - don't tie down your IT system with intricate rules to support an ever-changing process, then I bet you will get a better Total Cost of Ownership (TCO) at the end and a happier customer (the end user).

Robert Wallerblad

www.infuseit.com

Doing the Right Thing?



This post is inspired by a definition found in the comments which followed Oleg's post and a discussion with a friend of mine who is PLM responsible at a small car manufacturing company.

First, let's apply the definition of processes and practices, that Michael Grieves use:

“Processes are well defined routines that give organizations the outcomes they desire. However, a great deal of what companies do, such as innovation, is driven by a desired end result, which is what practices are all about. “

You could also rephrase this to "processes are about doing things the right way”; dictating how work should be done. Focusing on the what instead, we would allow decisions by knowledged workers and IT automation determine much of the how.   

To generalize, traditional PLM implementations are focused on data capturing and processes (according to the above definition). Capturing data in a common repository enables transparency, access and being able to connect the dots (data) in new ways. Usually, we then cover the data with a process layer, targeted for effective and repetitive management of that data. 

But what if we would focus on supporting “doing the right thing” instead? What would that mean? For me, that would mean focusing our effort on data, functions to manipulate, communicate and collaborate around it. Another critical role for a PLM tool would be to have capabilities to analyze that data, helping workers make informed decisions which would allow them to “do the right thing”.  

Are we on to something? What about "best practice" processes? Could we say that we can deliver value without them? Can we do this without being banged in the head by sales and marketing saying that we can't sell without a out of the box process support?

What if we state that "best practices" are on data level, basically how we choose to model the reality in a smart way? But to not become a consolidating integration hub, we would have to have tools to manage that data accordingly. With decoupled features we then address "best practices" of managing data without "tying it down" with processes.

To not "just" become a good data management tool we would need to wrap the whole thing with communication and analytic capabilities allowing the user to collaborate and making “the right” decisions.

What would we have then?

- A replacement to mail, excel and other data silos, which was exactly the thing that my friend at the car company was asking for; a tool which would allow him to still have the required flexibility but with transparency and the synergy of previously disconnected data sets. This would give him the means to reach the desired result in a perhaps unstructured way but secured via data and supported through communication and visual analytics. Wouldn't that add value? Wouldn’t that create an innovation pull as we then focus on "doing the right thing" rather than paving complicated cow paths?

Robert Wallerblad

www.infuseit.com