Key Requirements of a Manufacturing Big Data Solution
When a manufacturing enterprise adopts a Manufacturing Operations Management (MOM) system capable of managing the entire scope of operations, traceability is no longer something an enterprise strives to achieve, it is a byproduct.
Considered from the inverse perspective, total process, product and material traceability is the essential building block when pursuing operational excellence through the use of ‘Manufacturing Big Data’.
Having taken the decision to implement a big data solution as part of an operational excellence initiative, the next step of course is system selection. There are a few key capabilities and business approaches a manufacturer should demand of any MOM vendor to maximize success.
First consider the data model the system sits upon. It is not sufficient for potential vendors to simply state ‘yes we can store that data’ or ‘yes we can acquire that data’. It is important to examine two specific and critical data acquisition and data model issues.
First, how does the system go about acquiring data from the industrial automation layer of the factory including robots, conveyors, testers, inspectors, sensors, scanners process equipment etc..? Does the vendor build customized connectors for every data source, or does the system have a scalable and standards-based data acquisition engine for easy adaptation to the automation layer such that the adapters are productized, consistent and maintainable?
Second, determine if the system actually holds the CAD design data in its data model such that incoming variables are related to elements within the design itself. This is critical to manufacturing analytics and to data volume efficiency as the storing of the data against the CAD data reduces redundancy.
These questions should then lead to another related issue. Once the data is within the system, how is it made useful through alarms, control reactions, dashboards, and reporting? Is the data stored in a manner that is meaningful such that reports and dashboards can be made through a graphical user interface without requiring SQL or coding knowledge of the database? True drag-and-drop construction of real time dashboards and reports is only possible if the structure of the system is designed in such a manner that any incoming data, whether implemented today or four years from now on new machine types, are normalized and stored in a meaningful way. The question is a simple one. If a new machine is connected to the system to acquire its real-time data, is any SQL or coding required to change reporting?
The scope of the system must also be considered. To properly harness ‘big data for manufacturing’, every activity from the handoff of the CAD data from R&D to the process design and NPI activities, through materials management and then out from the start of manufacture to shipment must be part of the fundamental scope of the system’s coverage. Anything less will yield only a subset of the data needed.
The final consideration is not a technical one, but rather the business approach and model of the vendor. Is the vendor providing a ‘core’ of a system that then must be heavily customized to work in your environment? Or, does the vendor have vast stock capability that adapts through configuration to your process, minimizing customization and costs? This customize vs. configure question is the single greatest determining factor in the rollout speed and total cost of the project. A means to truly determine the extent of customization from a given vendor is to insist on a highly detailed statement of work that defines exactly what the system will and will not provide, and insist the vendor’s quote contains a fixed cost to achieve that functionality. To do otherwise invites endless customization and costs as you discover after the sale that the system, when you realize it, does not actually have the capabilities you believed it would have and customization is required.