What's the Biggest Challenge in Transitioning to PLM?

Yes, this is a pop quiz.

Alright. Quick, now, think about your answer.

Got it?

OK, now, hold on to it. Remember it. Stick it in a safe place in your head. 

Alright. Ready to hear mine? Let's see if we agree. 

On the edge of your seat? OK, Here it is.

The transition from a drawing-centric approach to a part-centric approach.

Wait… don't leave quite yet. C'mon... come back and sit down and hear me out. There you go. 

Now, granted, this isn't the biggest bleeding edge topic. I know. I know. It's not all that exciting either. But in all seriousness, this is a problem. A big one, actually, that often gets lost in all the talk about the cloud, automating processes, product analytics and whatnot. But just like those teenage years, its something everyone has to go through. Let me explain.

Life with PDM

Before an organization pursues PLM, life is pretty simple with PDM. Designers and engineers check-out and check-in CAD files: parts, assemblies, drawings and whatnot. Essentially, they're worried about the tangible representations they deal with everyday and often not much else.

Outside of engineering, however, life is actually far simpler. Everyone pretty much references the engineering drawing as the master definition of the product, even though there might be parts and assemblies sitting in a PDM system… that they likely never see. But for those outside engineering, this 'status quo' goes far beyond what's happening digitally. There are deeply embedded cultural practices and procedures, as well as expectations, around using the engineering drawing as the master. So make no mistake, this isn't just about data access.

Watch that First Step, It's a Doozy

So once an organization starts to switch over to PLM, that's when this little surprise pops up.

You see, in PLM systems, the CAD models and deliverables aren't the only representations of a part. There are specification documents, quality documentation, service documentation and so on and so on. A PLM part is the digital catch-all to which all those representations are attached.

Sounds simple, right? Well, unfortunately, transitioning from CAD data management to PLM part management brings to light some trouble some issues. Consider these questions:

  • Should the drawing number match the part number? Many organizations follow this practice. But if you change the title block, do you up the revision of the drawing number? The part number? Both?
  • If you change the color of paint used on a part, does that up the revision of the CAD file? Should it up the revision of the PLM part?
  • What happens when you update a CAD part file, but not the engineering drawing, that was already included in a technical data package sent to a supplier? Do you send them a whole new technical data package? Do you send them just the new CAD part file?
  • How does your change process looks with respect to form, fit and function modifications? A surface finish might change, but does that up rev the CAD part? Is it a whole new part number? If so, what representations now represent both part numbers?

So as you can see, it's not a 'flip-the-switch' technology adoption question. It's a cultural, procedural and practices larger question.

What's the Value?

Now that's the million dollar question. What value is there to the organization in switching from a drawing-centric to a part-centric approach?

Unfortunately, I don't see a ton of value right off the bat.

However, that doesn't mean that there isn't any long term. Essentially, the question cuts right to the core of enterprise PDM. If you want to have all of the representations and documentation associated with a part in a single digital location, you have to do something like this. You have to have an abstracted representation of the part to which everything is connected. You need a digital catch all for the part.

So, in my mind, I see little added-value. I think in that context, the question becomes; how do you minimize the time spent on this non-added value activity? How do you automate it? How do you take care of it for the user? Therein lies the a major challenge for PLM providers.

Summary and Questions

Alright folks. Let's recap.

  • Life with a PDM system lets engineering focus on just managing CAD files. Other organizations simply work off the engineering drawing.
  • With a PLM system, there is a central representation of the part where all other representations, such as CAD files, specifications and documentation is attached.
  • Switching from one to the other raises many questions about the policies and procedures that govern such relationships. Furthermore, there are serious cultural challenges to instituting change as well.
  • This step is a fundamental one in transitioning from CAD data management to enterprise data management. Manually connecting these things together provides minimal added value. As such, PLM providers need to automate it as much as possible.

Now, what say you? Have you gone through this transition? What were your experiences? What helped the organization make it through? What mistakes were made along the way?

Take care. Talk soon. And thanks for reading.