Joel Orr Commentary: PDM? PLM? What?

Dr. Joel Orr
VP & Chief Visionary
Cyon Research Corporation
[email protected]
www.joelorr.com

I was invited by a large defense contractor to speak at their annual "PDM Summit." Leading PLM vendors participated, as did two other consulting firms.

• It's very important and very difficult to keep track of all the disparate data that goes into product design-too many formats, media, update cycles, quality standards, and more.
• PDM is being subsumed into PLM (product lifecycle management). You can't have PLM without PDM-even though the leading PLM vendors refuse to nail down a definition of what it is and isn't.
• A couple of years ago, the CEO of one of the largest PLM companies said in my hearing, "PDM is an IT solution to an engineering problem." Most engineers don't like PDM, don't see what's in it for them, and resist PDM implementations. And replacing the "D" with an "L" doesn't fix that problem.
• There is often poor alignment between the career goals and considerations of individuals in user organizations charged with making technology-acquisition and -implementation decisions, and the needs and goals of the organization. "If I buy this new technology and put it to work, and it works well, my personal gains are modest. But if it works poorly, or not at all, I might get fired," is not an atypical line of thought. So the risk/reward ratio for the individual is out of balance with the needs of the organization.
• Very few companies are addressing this problem squarely. "Fail forward" is a great slogan, but even some who put it in their mission statement don't implement it wholeheartedly. The price of failure is very high in most companies, so people avoid risk. This has to change, if progress is to be made.

Another problem of PDM that is not remedied in the broader context of PLM: It supports only a limited view of what is actually going on.

Although there is general acceptance of the fact that geometry alone does not sufficiently define parts and assemblies-we need lots of non-geometric data along with it-the current approach to defining and managing parts and assemblies has little contextual information, and limited historical information. Basically, it keeps track of the part or assembly, some of its characteristics, and its revision level.

In other words, items in the PDM system do not "know about" other items. They also do not "know" why the last revision was made, or what exactly that revision was. Often they do not "know" who made that revision.

Requirements live and die on their own. They are not tied in to the product design process that is ostensibly meeting them. So there is no automated procedure for exploring quality-does the design properly respond to the requirements?

"Knowledge" has been characterized as a network of nodes and relationships. Present PDM systems preserve node information-but far too little about relationships.

So even though we all know we need to preserve organizational knowledge, we generally believe that knowledge management will come along as a separate and independent imposition on our corporate workflow. Someday. After I retire, I hope.

That's not going to happen.

Knowledge has to be captured at the point of decision. Unless you have a system that compels users, in a friendly way, to do so, it's gone forever. It cannot be collected ex post facto.

One of the big challenges to knowledge capture is that automation vendors resist standardizing terminology and language. Most large companies employ systems from more than one vendor, and waste inordinate amounts of time and money on interoperability and other forms of reconciliation of system particulars.

XML is only a small part of the solution to that problem. We need semantic reconciliation, at the level of ontologies, so that everyone knows what they are talking about.

The rapid growth of global collaboration and outsourcing highlights the deficiencies in our current ways of doing things. Organizations that get these points right are sure to win out over those who don't.

We live in interesting times.

Joel Orr has been consulting, writing, and speaking about engineering software for more than three decades. Visit his website at www.joelorr.com.