PLM…ERP…MES…MRP: Acronym Soup
IT acronyms are funny. Not everyone knows exactly what they mean, but they get used often enough that people understand the general context – and that’s good enough, mostly. Take ERP for instance. ERP stands for Enterprise Resource Planning. ERP is distinct from MES, MRP, HCM, and other related systems and processes, but most business people hear ERP and think “our accounting & manufacturing stuff”. Similar things happen when people talk about PLM. There’s nothing wrong generalizing about ERP, PLM, etc. when it isn’t the topic at hand. But when you starting talking about PLM in detail, it pays to be more specific with terminology.
Here’s what I mean. To me, PLM (Product Lifecycle Management) is not software. PLM is a set of processes for managing a product’s information from concept through disposal or end of life. PLM has existed since the first human-made tools. Once that cavewoman tied a rock to a stick handle to make a hammer, she had a design, a BOM, and a manufacturing process. None of it was documented, but there was product information. When her hammer broke (product end of life), she made a new and improved one (engineering change). So PLM has literally been around since the Stone Age.
Big Leaps Forward
PLM techniques have gotten much better since then. There were big leaps forward when product information started being documented on paper instead of passed among members of the Neanderthal’s tribe (talk about tribal knowledge). And the quality of engineering documentation has steadily improved over time with drafting standards, specifications, bills of materials, etc. Along came the computer, and things really accelerated. This is where PLM software comes in. In my view, PLM software is any computer program that helps automate or manage product information.
Now… what is PLM?
PLM is a collection of processes, and PLM software is a category of computer programs to help with supporting PLM processes in an organization. I’d like to subdivide a bit further though. Within the term PLM software, there are PLM applications and PLM systems. In my view, PLM applications are programs that can be used effectively by a single person to generate a result, whereas PLM systems require multiple people interacting to achieve the desired goal. So you can do product design with a PLM application (like CAD), but you would probably do engineering change management with a PLM system because this process requires routing information around to multiple people for input/decisions. One more useful term is a PLM software suite – I define this as multiple PLM applications and/or systems designed to deliver enhanced capabilities when used together. To offer some practical examples, AutoCAD is a PLM application, Aras Innovator is a PLM system, and the Dassault 3DEXPERIENCE family of products is a PLM software suite (CATIA, DELMIA, ENOVIA, etc.).
Why does this even matter though? From my perspective, this is important to how you should think about PLM in your business. Too many people believe that buying PLM software will magically fix some product-related problem or challenge – it won’t. Improving PLM is all about improving and automating PLM processes, sometimes with software tools. That’s why we do what we do at Razorleaf. We focus on bridging the gap between PLM technologies and business problems. There are times when our clients need a (new) PLM system or application, or sometimes they need to apply software tools that they already have, and other times clients just need to work on their business processes. We’re here to help in any of these situations, and that’s why we focus on PLM – not the software, but the overall process.
This post is part of a four-part blog post series and white paper titled “Achievable PLM”. Stay tuned for Part 2: PLM Software Can’t Fix Process Problems (Except When It Can)