Look Under the Hood of PDM Systems

Written by Jonathan Scott

Let’s dig a little deeper in this final post on PDM engines (look here for the previous post). I think there are two reasons why it is helpful to have an engine-centric perspective on Product Data Management: to understand when you should/shouldn’t use PDM, and to fuel creative uses of PDM. Those may seem a little counter to each other, but let’s see how they’re related.

One of the questions I regularly hear is, “when should I use PDM and when should I use ERP?” I won’t settle this great debate here, but by thinking about PDM (or any software, really) as a collection of inter-related engines, you can get a sense of the system’s core competencies and where its sweet spot really lies.

For PDM, it is good at records management and lifecycle. For ERP, it is good at transactions and accounting (not just financial accounting, but cross-functional accounting of statuses and levels). You can see PDM’s strengths and weaknesses when you look at its constituent engines.

As a case-in-point, when I hear the previously mentioned question, the discussion frequently turns to Bill of Materials (BOM) management (and where BOMs should be managed). My general thinking goes like this:
“PDM is great at managing revision-specific, configurable, multi-level component structures, and often ERP is not. ERP is great at planning/scheduling the resources to manufacture a product step-by-step per the structure and prerequisites of a BOM, and often PDM is not. Use each tool for what it is good for; create BOMs in PDM, and use them in ERP.”

This conclusion is fueled by my analysis of PDM systems as a collection of engines – and what those engines are uniquely suited to do. So that’s one value of looking at PDM as a collection of engines; knowing when to use and when not to use PDM for something.

The second reason why this “engine” approach is valuable relates to finding creative uses for PDM. If you’re comparing PDM to a logical alternative (like CRM, ERP, groupware, etc.), compare the engines toe-to-toe and that will help you understand relative strengths. But if you have a software need where there is no established genre of software, thinking of PDM as a collection of engines may help you come up with a creative (and cost-effective) solution.

Take one Razorleaf client for instance – they needed a system to manage the fulfillment of sample requests made by their sales force. The business problem was that no one could track the status of sample requests, and no one knew when/if a sample would be delivered. So they wanted a database-based application with forms, maturity logic, and routing that could be used via the Web, and could communicate using email as well. That was it in a nutshell (no mention of PDM), and when the proposals came back, prices were all over the map based on the technology stack that vendors proposed. You can guess the end of the story – they chose to write a custom application on top of PDM because it already included most of the logic engines that their application needed: lifecycle, security, and workflow. Most of the other vendors proposed writing the application from scratch on top of a database, and naturally their proposals were double and triple the PDM-based option.

So what should your PDM engines be doing for you that they aren’t doing today? Remember that its valuable software and you already own it. Are you getting the most out of it?

Tags: BOM, core, core competencies, Databases, engine, engineering, ERP, lifecycle, manufacturing, mapping, PDM, technology