Data Management & PLM


11 March 2014 | Team EACPDS


I find that people tend to blur the lines between ERP, MRP, and PLM. The purpose of this blog is to summarize the high-level intent of most ERP, MRP and PLM systems.

ERP — Enterprise Resource Planning:
One of the biggest driving factors for the need for an enterprise-class ERP system revolves around finance/accounting. Anything that is related to income or expenses must be tracked in extreme detail. To properly manage finances, many other aspects of the business need to be tracked and controlled in a transactional manner. Everything from human resources, sales, returns, shipping, inventory, and so on. To ensure all information remains accurate very strict rules and processes are set up. There are a vast amount of ways ERP systems can help a company manage their business. Many companies find benefit and are almost required to have some sort of ERP system. These systems help them manage their business in today’s market full of government regulations and reporting requirements.

MRP — Material or Manufacturing Resource Planning
Both of these have a very high level of detail around material tracking. Material Planning tends to focus more on the cost of material and its location at any point in time. This can include everything from shipping, lead times, actual cost, to material movement throughout the manufacturing process and the cost associated with it. Manufacturing Planning also has a detailed tracking of material. However, these systems tend to focus more on the manufacturing process. One specific thing they tend to track is work cell details. Some examples of this tracking are the material going into and out of a work cell, the resources required for the work cell to operate, tooling required at each work cell, and in some case detailed work instructions for each process required at the work cell, and much more.  These systems still have a very tight process that must be followed for control of the manufacturing or assembly process. Variations to the process are not typically permitted unless it is a defined; pre-approved process variation.

PLM — Product Lifecycle Management:
Good examples of these systems tend to have a completely different mindset from ERP or MRP systems. PLM is all about the management of the process behind the product, from conception to sunset, as well as the history and collaboration that goes along with it. The focus tends to be on a more dynamic and flexible way to allow people to focus on the development of a product, not on transactional functions related to it. Most PLM systems also typically have a PDM (product documents management) system inside of them. PDM is used to control the history of the intellectual documentation needed to design and manufacture a product. Everything from CAD (computer aided drafting) files to general production specification documents. PDM ensures this data stays as accurate as possible through versioning and access control based on the state of the object in the overall design process. Better PLM systems also have Program, Project and Change Management processes built in. PLM then combines all this functionality into an overall product lifecycle management process.

Many larger ERP systems offer modules to do MRP, PLM and even PDM. In many cases, these add-ons just do not have the detailed functionality needed or the flexibility required to accomplish what the customer is looking for. For instance, I personally have participated in the development of an MRP system. While the ERP system we used had a type of MRP module, it did not track the details or allow the flexibility we needed at the work cell level to control our assembly process.

I have seen many examples of larger companies also using a major ERP system to do PLM. These same companies then find out these systems are just too limited in both functionality and flexibility to allow engineers to develop and design new products freely. Another area ERP tends to fall short of the companies expectation is with PDM. Often the problem is with the lack of integrated control of the CAD files. Due to this limitation, it makes the interaction between engineers and the ERP system tedious and time-consuming.

I personally feel these ERP systems tend to fall short in these areas is due to their focus on transactional functions and very tight controls. Based on their origins around finance, this type of control is completely and understandably needed. Because of this, there is little to no development around the flexibility needed for free-flowing processes often required in the product development environment.

Some best examples of a complete implementation of ERP, MRP and PLM I have seen are companies that have utilized the best of each system based on their business needs. They then utilized integration methods so appropriate data is shared between all systems. Some of the most painful examples I have seen are companies trying to change and force their internal business processes into the envelope provided by an OOTB ERP system. Or worst yet, paid a very large amount of money to recreate the wheel and customize their top level ERP system to do what they need.

In the end, all of these systems have a place in today’s business. They each have strong points and weaknesses. Just be cautious of any company that claims they can do it all. Remember the quote; “Jack of all trades, master of none.” Why not get a team of “masters” and have them work together.