PLM Philosophies Collide?

Yes, I think there’s an interesting divide within the PLM market place.. There are one or two big PLM products (with roots in CAD data management) which are fantastic at BOMs and Product Structure but less so when it comes to process & workflow.. Other PLM products (typically without the CAD data management roots) are fantastic at process but not as strong when it comes to manipulating complex product structures. It seems to me right now you cannot have the best of both worlds. Typical end users still often think about BOMs first, process second. And they pick the best tool for BOMs. When they then come to add process, they are disappointed.. There’s a trade-off. But people are not as aware of this trade off as they should be..

According to my view, BOM world and Workflow world are two sides of the same coin. They are actually the questions and also the answers themselves. What I mean to say is, BOM per se cannot exist without a process in it to get into the next stage. And the workflow per se cannot move forward without containing anything in it. So, both BOM and workflow complement each other and churn out a solution or a conclusion. According to me, future of PLM and will be that these 2 philosophies do not collide but need to complement and appreciate each other to come out with a futuristic PLM solution. Again it depends people, their mindset and how well they appreciate this concept or philosophy. There can be and will be lot of iterations of improvement in BOM and Workflow in terms of getting them stabilized, but, they both are husband and wife. They should not be divorced.

Graham, you are right! People are obviously starting from BOM side. This is what hurt them more, in my view. That’s why we are still bad in delivery of “collaborative solutions” and collaboration is a “dirty” marketing word and not something that associated with productivity. I believe both problems need to be addressed together. Thanks for your comment! Best, Oleg

Funny, I have more trouble rationalizing the BOM oriented view of PLM with the “source code control for CAD files” view of it.
They are, of course, intimately related (in some scenarios BOMs can be abstracted from the design) but not usually in simple ways. This, of course, leads to the need for complex Workflow, BPM and other types of EAI. The challenges here are not fundamentally different than they are in other enterprise software domains except that design data is astonishingly more complex than the simple relational DB data that comprise most other enterprise systems (ERP-financials, CRM, SCM).

Milt, thanks for point on this issue. You are right! I found Design and Bill of Material relationships are very complex, and they are reflected in many design decisions and processes. The complexity of design data is reflected in complexities of PLM systems. Best, Oleg

Oleg,

My philosophy is that Data and Process are two aspects of the same thing. Both equally important.
This is true for all enterprise applications. It just happens that PLM data is more complicated than ERP or CRM, hence the complexity of software required to handle it.

The trick is how to have both Data and Process aspects, embedded in an Application – work for the User.
And how to make all three – Data, Process and Application – easy to customize and quick to change, or – agile.

In existing PLM software it indeed looks like Process was added on top of Data, using a complex monolithic application(s), and therefore no agility, expensive to own, and unhappy customers.