I was reading a book authored by my friend Steve Bell today. In his book
-
Lean Enterprise Systems
he raised an issue that resonates with me. He cited a study in the International Journal of Logistics from which he concludes “in many organizations 99% of the information processing activity is wasteful…” as a result of the “improper use of IT.” His comments resonated with me due to the fact that PLM systems can be viewed as product information “meta” data vaults or “file” vaults or a combination thereof.
The question of what information belongs where plagues corporations and the enterprise systems that they use. Which system is the master and what system is the master of what data. Some simple rules to live by are related to how the “change” of that information impacts the resulting product. Some examples are:
Changing warehouse and bin locations - does not change the actual product so should not be controlled with PLM workflows
Changing suppliers – “may” change the output product depending upon whether the supplier is a distributor of standard stock items or whether the supplier is actually a contract manufacturer who uses production methods that rely on a “recipe” to produce the output – so the vendor must be qualified and the recipe would need validating.
Changing coatings – qualifies as a form, fit, function change and must be treated as revision controled – yet may be managed at a metadata level not in vaulted files, thus is a change control issue for PLM workflows.
Changing lifecycle status – crosses a boundary zone – defines purchasing decisions, yet some companies will treat this as revision controlled (board changes from prototype revision to production revision. But it changes the design change rules followed by a company.
Changing buyer designations – again this is procurement information that is not to be controlled by the PLM system – yet impacts product change decision processes in terms of when changes occur – who should be reviewing the changes.
So the challenge is to define what data is “owned” by which systems, and what data is “consumed” by which systems. The resulting systems integration requirements can be very significant – and need to be thought out very carefully. And perhaps even ask the question is it integration that is truly needed or is it that the data is needed to be merged for specific repeatable processes – but let each system own its own data and use the right tools to access and view the right data. The tools exist…
Copyright 2007 – LHirr, All rights reserved
