DMR and DHF
Hi There – I am looking for some input and lessons learned if folks have built within Agile PLM the following functionality:
1. DMR(Device Master Records -> Multi-level site BOM across all levels for a Finished Goods based on the effectivity date.
2. DHF – The corresponding Device History Record/File of all attributes changes for the components during the effectivity date.
Any information relating to DMR/DHF is greatly appreciated.
If I understand your DMR correctly I would need to go down the path of caution. We draw a fine line when it comes to the product definition and product manufacturing. Agile is great at product definition, this is where Eng imagines and evolves product throughout its lifecycle without constraints we see in in ERPs. When we talk about effectivity dates we impose these constraints. Effectivity dates are more efficiently tied to the manufacturing BoM or in the ERP. The ERP manages build to shipping. That is exactly where we should be managing the effectity dates based on our inventory, customer and build constraints. I would not recommend trying to manage this in PLM as it will drive you crazy.
Accordingly, again, if I understand your DHF you are more concerned about what got shipped and the configuration of that product to each customer. Again, PLM does not care as it wants to strictly manage the design and development cycles. Your ERP is where you will be managing what went into what and who got it.
Patrick – Thanks for your response. For us Agile is the System of Record and the Manufacturing BOM is maintained in Agile. It gets transmitted to ERP Systems based on the release event of the ECO via ACS. The challenge we are trying to address is building the DMR based on the effectively date.(In essence its basically a multi-level BOM explosion report along with any attributes updates for the given effectively date).
Yep, it’s going to be tough. For example, a change order changes two parts on a BoM that for all intentional purposes are ibterchangeable yet Planning and Sourcing decide they need a use up strategy and the stock doesn’t support a one time cut over so you end up with product made with an undocumented configuration. A deviant to say. Like I recommended, PLM should develop the BoM and not be directly tied to the MFG BoM. As you are experiencing it leads to problems. To overcome this your team needs to really step back and better define the process. Sounds like effectivity date management so that no change is released until your managing authority says so. That would move the problem more upstream but it will still exist. The fact of the matter is this. Eng develops…. that’s all. Mfg makes…. the two should never be tied. Eng could release rev 01, 02 and 03 while Mfg makes rev 01 and due to strategy shifts to 03 and completely bypasses rev 02. This scenario is quite common. I wish you the best of luck and hope there are some brilliant folks on here that know something I am missing that can help you out.
Agile is designed around configuration management with revisions. Like Patrick says, it is not effectivity driven. There is a BOM report based on effectivity but it will be burdensome to leave the everyday screens in Agile and keep going to that report.
As for DHF, I have seen two approaches. One is a tree of documents. Similar to a Parts BOM only with the documents that make up the DHR. One of the branches would be the DMR. The other approach is using the PPM module to capture the DHF. Again, one of the tasks would have the DMR as its content.
I have recently completed a SQL query to create a date-specific BOM report, if you think that would be helpful. This is for the BOM only. While I would love to also get attributes at said specified date, it gets pretty complicated to do so. First it depends on whether the attributes in question are change controlled or not. If not, you must rely solely on the item_history table as opposed to the redline_attribute table. In my case, the attributes of interest are indeed change controlled, but if the attribute did not have a change on the ECO just prior to the specified date, then what? Do you take the current value? That may not be what the value was at the time, because it may have been revised since then. So, it would become an exercise in going back, potentially through multiple ECOs, to figure out what the value was at the time. Long story short… we simply opted to keep ours a BOM report, and keep attributes out of it.