The Vuuch Voice

Jim Brown started a healthy debate about PLM and ERP in a post about SAP.  The discussion spilled over to the linked-in PLM CAD/CAM Group.

One point of debate has to do with iteration and state control.  Two camps formed around the idea that PLM is an application that supports a highly iterative process and ERP is a solution which does not support iteration (Camp 1 = PLM captures iteration and Camp 2 = ERP does not capture iterations).  Of course product development is iterative.  But it seems to me the data in ERP also goes through iterations since ERP records versions, configurations, inventory use up and effectivity dates.  It seems a bit circular to say design is iterative and therefore PLM is iterative which reminds me of Jesse Craig declaring my position as shortsighted and a blatant logical fallacy http://en.wikipedia.org/wiki/Affirming_a_disjunct.  Maybe Jesse was right.  I was motivated by stirring the pot.

To simplify let’s take a simple case of a single part that is being designed and managed in PLM.  The part goes through a series of versions due to iterations, some of which are captured on the designers desktop and some of which are captured when the file is checked in (as a result some files states are not captured).  Even in this single part example there are many drivers to the iterations.  For example the part needs to fit into/onto something, there are material requirements, vendor selection issues, quality control requirements/approaches and on and on…  Again to simplify let’s say the part is at some state of design and that during a team meeting a number of issues are captured that the team agrees to resolve.  Lets classify these issues into two groups where the first group requires the CAD designer to change the model and the second group will not. 

Focusing first on the issues that require model changes and imagining that in order to make the appropriate changes the CAD designer needs to go back and forth with a number of different people.  These people are basically helping the designer determine the appropriate geometric result.  Going out on a logical limb I will say that you can draw a direct parallel between those involved and the geometric result.  What I mean by this is that each person’s perspective can have a direct relationship to what gets modeled.  To further define this point we will imagine that the geometry in questions is a simple concave round:

• The designer might look at this as just a round. 
• The FEA person may see this as something that induces stress. 
• The industrial designer may see this as impacting the visual appeal of the component.
• The manufacturing engineer may look at this as something that drives up the price of the machined part. 

A round is never just a round.  In our case multiple perspectives drove the final outcome of the model.  If you continue this example, it is simple to see how maybe each of the people mentioned above came into the discussion with the designer one at a time and therefore the round went through a series of values and that none of these iterations were saved back into PLM.  As well I think it is safe to say PLM has no idea about who the designer engaged in order determine the finial value of the round.  After all the back and forth the designer checks the part back into PLM.  So what does PLM know, the state or the iteration?

Looking at now the second set of issues we will imagine these as having to do with vendor selection.  Let me first set the stage.  During the development of the part a vendor was selected from the approved vendor list and in parallel the targeted vendor failed a vendor audit.  The project manager gets an email from purchasing that the selected vendor will be removed from the approved vendor list and therefore cannot be targeted for his project.  The project manager now has a new item for his list of he must fix before releasing the part.  The project manager, manufacturing engineer, quality engineer and purchasing person sit down to discuss how to resolve this problem and as a result:

• The manufacturing engineer is tasked to visit the vendor and evaluate the cause for failure.
• Purchasing introduces a new potential supplier.
• The quality engineer is tasked with evaluating if the new potential supplier could provide the new part as a ship-to-stock item (there is a requirement for no incoming inspection).
• The project managers issues a purchase order to one of their prototype suppliers for a quantity of parts that will meet the first level of demand (these end up getting made before the final change and therefore need to be reworked in house in order to be used).

In this case we will say that all these people got together all at once in a team meeting where they decided who would do what.  In this case the team has set off in multiple directions most of which are some how related to ERP data.  The potential new supplier “at some point” would need to be entered into ERP, the status for the failed supplier would be altered in ERP and the PO for to the prototype supplier would be in ERP.  Would ERP know why the new supplier was added, or why the supplier status changed, or why the PO was issued and what of this information would be found in PLM?  What about the quality engineer and the investigation into the failure?  Where would this information be found?  I think it is safe to say that there is only one place you would find this information.  The project manager has all of this in his inbox and on his list of things that need to be resolved.  I think it is also safe to say that maybe a comment is added in ERP when the vendor is added, the status is changed and the PO is issued.  Even if this was done has ERP captured the iteration or the state?

Certainly in both cases the team used an iterative approach and as a result data/assets/deliverables went through a series of states.  But I would argue that in both cases neither the PLM or ERP systems captured anything other than the state change.  Reflecting on this post I would also challenge the terminology of iteration and state and declare that better terms might be CAUSE and RESULT.  Understanding why something changed (CAUSE) is very different than understanding the result of the change (RESULT/STATE).  This idea is a fundamental part of the regulations created in the 90′s for the medical device market http://en.wikipedia.org/wiki/DHF.  A driving force to these changes, from what I know, was the fact that patients were being injured even though the product that created the injury was a valid release (RESULT/STATE).  The resulting regulations have been setup under the notion that in order to evaluate the (STATE/RESULT) of a released product you must be able to evaluate what drove the result (CAUSE).  So in our case above you would need to prove how you came to the value of the round and what you did to validate that the value released would not impact the product in a negative way.  As well you would need to be able to show why the vendor went from one vendor to another and that this also had no negative impact on the product.  As you can imagine this is not as simple as knowing the state of any bit of data.

In conclusion I would STATE that PLM and ERP both deal with data that is ITERATIVE and both capture the STATES of their respective data but neither understand CAUSE.