The specific schema used to communicate data among different software tools is beyond the scope of this article. But one thing is common to all tools: eventually a human must use them and therefore, the data within the tools must be human consumable. This data can be irrespective of product structure, hierarchy, data models, or any other tool specific definitions. In the end, data is data, and that data can be structured and linked in any format necessary for human understanding.
The data could be structured in an as-designed format like an Engineering Bill of Material (EBOM). Or it could be structured based on the methodology used to manufacture the product (MBOM). It could also be structured in the format for make/buy decisions or decomposed and allocated for requirements. Finally, we could also consider data in the form of configuration rules or pricing information which may be structured against features or functions.
Regardless of how the data is structured, if the parameters are linked to the correct objects — parts, assemblies, items, features, or functions, for example — then they should be able to be translated among any number of different systems. The key is to not limit one’s thinking to legacy data structures.
Remember, data is data, therefore parameters could be linked to conceptual objects as fluid as the wind or noise (fitting for a wind turbine example).
These parameters can be used by pre-sales activities (CRM or CPQ), quickly generating valid configurations thereby reducing the need for manual labor to look up reference tables. And while tech sheets and other marketing collateral may be fine to send to a customer, a company should want its sales force to have the latest and greatest information at their fingertips. Reading product specs from a catalog is not as good as getting the data live from a tool such as CLM.
The parameters, such as torque specs, temperature limits, operating conditions, or any other relevant parameter whether physical or conceptual, could also be used during the commissioning, or site installation, of a product.
This provides the installation technicians the ability to verify all performance parameters during system startup. Imagine a complex product like a wind turbine. Knowing that every component is acting within specified parameters upon initial startup is paramount to safety and functionality.
Where do parameters like that live: PLM, ERP, Excel, or in an engineer’s notebook?
The parameters could also be used by maintenance and field support. Replacing a component, especially if the new component is an upgrade, can alter the settings or performance of other components to achieve the same result.
Therefore, knowing what parameters may need to be adjusted to compensate for the new component is critical for equipment service and maintenance. These dependencies between parameters can be linked by rules, thus avoiding manual errors or forgetting to adjust a parameter. Automating the parameters through rules also ensures secure logging and tracking of the changes rather than relying on a service technician’s notebook.