Social Product Development

Thursday, January 28, 2010

PLM Process v. Data Management

Oleg Shilovitsky made some interesting points recently in his blog “What are we Losing by Going from CAD to PLM?” about how PLM may be losing its roots in its attempt to better court the IT department.

Oleg’s assertion was that PLM vendors and systems have gravitated toward “process” centric solutions, perhaps at the expense of core data management capabilities. This is particularly troubling, he reasons, because the design and engineering departments are the engines that produce huge volumes of critically important data. Poorly-managed and left to wither, engineering-generated content would take a back seat to a heightened PLM vendor-driven emphasis on process improvements. While the notion of process optimization may sounding appealing, it comes with the opportunity cost of dismissing the rich information embedded in CAD models for use in other functional domains. I agree with some of this thesis while respectfully disagreeing with the rest.

Certainly there’s no argument here about the value of the intellectual property created by engineering and design teams. I consider their contribution to be the lifeblood of a product organization. And while PLM may be continually evolving in its definition, I believe that having PLM rooted in a process-centric view is good. In fact, I think it makes better utility – downstream, upstream, sideways-stream—of 3D content and other product data. That’s not to say CAD data management falls by the wayside. It can’t. It’s an absolute necessity, but I do think this is a case where we can get to Shangri-La by having our cake and eating it too. Like the ice cream kind with the crunchy things in the middle.
Solutions like ProductView, Arbortext, 3D Via Composer, and Lifecycle Visualization all have a role to play in processing, utilizing, and supplementing the value of CAD data, for example, through visualization for design reviews, manufacturing work instructions, and technical documentation for user/service manuals. These use cases are predicated on robust CAD data management (ideally, complete, heterogeneous BOM management), but serve to advance really money-making operations (read: processes) for companies, like NPI, MPM, and service planning. Add in a layer of Web 2.0 capabilities to connect communities with product development, and even more is possible.

So, process OR management? I’ll take both please.

Agree or disagree?


  1. Hello Tom, Excellent analyzes. I'd take both too :). So, taking your ice-cream example, how to be sure you have "rock solid crunch" inside. You need to be sure data foundation is rock solid. And this is about basic PDM. So, my preference is 1- "data management"; 2- "process". I'm looking forward to other comments... Best, Oleg

  2. Agree. It is like the Body and the Soul

  3. I agree with Oleg's prioritization. In the software world where I work, a key first priority is to assure that our source code (data, intellectual property, captured knowledge, etc.) is safely retained, and that we can move backwards and forwards in time with that intellectual property. Without that ability, process is an expensive impediment to the real goal (create great, profitable products), rather than a benefit.

    Once the source code is well managed, then we can consider other improvements, including process improvements. Process improvements would be much less valuable without the core defense of source code control (in my software development world) or data management (in the mechanical engineering world).