PLM vs. BPM or What do you think about IBM PDIF?

PLM vs. BPM or What do you think about IBM PDIF?

ibm-pdifIn one of my previous posts, I raised the question if PLM needs to develop its own process tools. Looking at the few announcements made by IBM and Siemens PLM, I asked myself the following question again:  Where is PLM going regarding the implementation of Business Process Management (BPM) and SOA related frameworks? For the moment, I have more questions than answer, but my basic assumptions follow:

  1. From the PLM standpoint, business processes (or collaborative business processes) are a significant portion of what enterprise PLM does.
  2. There are about 100 companies in the world that are doing something more or less associated with Business Process Management (analysts normally talk about 10-20 top players).
  3. Pure BPM players are rarely involved into PLM implementations; PLM companies normally provide workflow and process functionality by themselves.

Comparing PLM and BPM process capabilities, I have concluded that:

  1. PLM provides a very good product-oriented workflow, but is relatively weak in enterprise functions and administration, and other middleware components.
  2. The BPM offering is always more agile and more generic compared to PLM business processes.
  3. BPM normally provides connectivity adapters… and for PLM products too.

The very interesting piece of IBM PDIF framework is related to IBM Web Sphere Process Server and additional process-oriented middleware components. I wonder what combination of PLM software from Siemens PLM will support the process components of PDIF and how they will work together. Similar frameworks are available with other big enterprise stakeholders such as Microsoft, SAP, and Oracle. How can their respectful products provide similar functionality?

Speaking broadly about PLM and BPM, I found the following questions interesting.

  1. Will PLM follow the traditional path and continue to develop BPM components to make their PLM Process technologies stronger?
  2. Will PLM vendors be interested in the acquisition of one of the available BPM pure players to get more “process stuff” on board?
  3. Will PLM adjust more to the BPM capabilities of large enterprise and platform vendors?

I look forward to your comments and opinions.


Share This Post

  • The most expensive process that exists in a manufacturing company is their engineering change control process. We are talking about changes to documentation and bills of materials. This is the sweet spot of PLM and should be a part of any PLM software…

  • Scott, Thank you for your comment! Absolutely agree with you. ECC is actually sweet spot, but this is very hard spot to implement it successfully. So, from my view, almost all PDM/PLM products have it, but there is space for innovation here. Cheers, Oleg.

  • I concur with Scott that ECO and the control process regarding change around around W.I., BOM and BoPs are critical. But the real value add is synchronizing those with manufacturing. That will require synchronization with Level 3 systems / MOM platforms.

  • Jordan, I think MOM is important, but really can come as add-on. However for all ECO is ultimate requirements… Thanks for your comments and welcome to discuss more on plmtwine! Cheers, Oleg.

  • Jags

    I think the problem lies in the fact that implementations at both ends i.e. BPM and PLM end are expensive and lengthy. Though, we may concur the fact that BPM is required but for a product company after they implement PLM, business process alignment with respect of product is taken care of. Yes, it is not done exhaustively but then such cases are missing in the organisation today.
    People see BPM as process optimization and DMAIC implementation whereas PLM is seen mostly focused on reducing time to market. Both strategies are linked yest different in implementation.

  • Jags, thank you for the comment! You are right, both PLM and BPM are trying to find a vertical niche and not to overlap. Organizations won’t be able to justify both solutions in place. Best, Oleg