Skip navigation


plm-erp.jpgERP and PLM both enable manufacturing companies to manage their design and production processes, but these tools are designed to work together, and aren’t an either/or solution. While PLM systems focus on the product record—the BOM, AML and revision history, ERP systems focus on the financial roadmap.


If you're doing outsourcing, manufacturing something that's remotely complicated, you will probably need both ERP and PLM. But what gets implemented first?


A Breakdown of PLM and ERP




PLM—the system of record for your product




  • Bill of materials (BOM)      management
  • Item management
  • Change management (ECR, ECO,      ECN)
  • Document management
  • Compliance management



ERP—the system of record for your financials




  • Purchasing
  • Accounting
  • Inventory management
  • Order management
  • Sales forecasting


As you can see, these tools manage different things, and knowing which business systems to use for which purpose is a pretty big part of implementing these systems correctly.



Because PLM is intended to manage the development of your product and ERP is intended to manage the resource planning of your finalized design, I think it makes the most sense to start with a PLM system. After all, it’s a waste to plan out the resources for a product design that is still undergoing revisions.


To organize and manage product data, product data should be initially  stored in a PLM system. Once the product design has developed to a point  where resources need to be managed to produce the design, an ERP system  that integrates with the existing PLM system is helpful. If you're managing your finances before looking at your product record, you may feel like you're focusing on the bottom line, but you're actually opening yourself up to scrap and rework. In contrast, if you implement a PLM  system beforehand, you can be confident the product  information is being accurately managed and the ERP system is working  with effective data.



What do you all think? Any success stories of implementing one before the other?


And for more info, check out our full white paper at

A good friend of mine . . .  who shall remain nameless . . . . just  got out of a "come to *****" meeting because a major change to an  important fixture in their product was missed. Not a good day to be him .  . .

It's scary to admit, but missing a poorly documented change can  happen to anyone (to a varying degree of severity). It all comes down to  your processes, and how tightly you're managing changes to your product  with ECO/ECRs.

Obviously, working at Arena has convinced me that you should just set things up in an electronic change management system and call it a day, but a lot of people still use excel, email,  notebooks, file cabinets, and a variety of other methods to manage  changes to the product, and depending on where you are in your process,  that could be perfectly fine.

No matter how you manage change in  terms of system, I think there are some common issues that you have to  deal with at one point or another.


1. Bottlenecks

2. Non-compliance (from other team members)

3. Scaling


I wrote another post that presented solutions to some of these change management challenges, but I'm wondering what other challenges are particularly ubiquitous, and what are some possible solutions.


So - - please - - - weigh in!


When it comes to change, what makes it hard to manage? Did I nail it with the three I listed, or are there better ones?

supply chain istock image.JPGA recent Chainlink survey revealed that 45% of companies devote less than $50,000 each year to  “assessing and auditing supplier and supply chain risk," which went right along with the 2011 Arena Solutions Manufacturing Outsourcing Strategies & Trends Survey, which revealed that there are major gaps when it comes to managing supply chain risk.


Although world events suggest that it is a perfect time to shore up your  supply chain, there are many reasons why implementing change in this  area is easier said than done.


For one thing, crisis hits so randomly, it's hard to know the best way to prepare. Is it enough to diversify across countries or do you need to diversify across continents? Should you have multiple sources for components, or focus on bringing core competencies in-house? It's hard to know, and with the initial investment required, doing nothing seems like a much safer choice.


Another reason manufacturers neglect supply chain risk management is  the constant pressure to cut costs. Manufacturers who lean-up the supply chain by cutting spare inventory or  “extra” talent, moving non-core services to lower cost providers or reducing suppliers are inviting extra risk, but improving their immediate numbers - making it a tough line to walk.


Finally, even if manufacturers want to invest in shoring up their supply  chains, many organizations have delegated supply chain risk management  so far down the chain that the authority tasked with the job lacks any  budget to invest in it. For about 80% of companies, according to the Chainlink survey,  supply chain resilience is only a priority at the executive level if  the executive is directly responsible for supply chain functions.  Although C-level executives get involved after a crisis—when, as one  survey respondent put it, it’s “all hands on deck”—in normal  circumstances supply chain risk management is handled by lower-level  managers.


To read the original full article on this topic, or more about supply chain risk management, visit the Arena Solutions blog.


Unfortunately, when faced with improving short term ROI versus  investing in supply chain security, manufacturers who are being asked to  do-more-with-less may very well decide to cut costs and hope for the  best. Do you think this is a wise strategy? Do manufacturers have a choice to do otherwise? And are there other reasons why investing in supply chain risk management might not be a top priority?

I always enjoy reading the musings of my company's CTO, Eric Larkin. I found his most recent post about open-design hardware particularly interesting.(Not to mention, I appreciated the throw-back  to the days of HeathKits.) Essentially, his latest post posed the  question: Will open-design hardware eventually replace the current  proprietary model of design?


If software can do it . . . .


I  see where Eric is coming from in suggesting this is possible. Linux and  other open-source tools have proved that you can improve software much  more quickly with a collaborative, open development process, and we've  gotten to the point where there are profitable businesses who only  publish open-source software.


There are a few cases where this  has worked for hardware as well. For instance, the M1911 pistol—the  classic “Colt 45”—has been produced world-wide using an open design for  decades. Similarly, the AK-47 submachine gun was designed in Russia, but  is now produced world-wide from readily available specifications. There  are also some standards-based commodities (like plumbing) that have  been created with an open-design.

While I can see (and like) the idea of an open-design hardware  community, I personally feel there are some barriers when it comes to  this sort of approach for hardware.


For example, one hallmark of  successful open-design tools is the ability to create a community of  developers who are continually improving that core design with a series  of successive patches that move the product forward successfully. This  works really well in software, as it is a matter of writing code, and  there aren’t physical investments that need to be made. In hardware,  that mechanism for packaging change is underdeveloped. It's all physical  product, so it is much more expensive to change - you can't just get in  and mess around.


Another challenge is that hardware has a much  stronger culture of protecting innovation with patents and trade  secrets, whereas software pretty much invented the pirate.


I  would love to see this trend actually work as a new way to encourage  innovation, and there are a lot of others who seem to be intrigued by  the idea. What do you think? Are there classes of hardware where it  makes sense to have—say, an open-design motor?