Introduction
For corporate customers who deploy GainSeeker at multiple facilities, multi-plant rollup allows individual plant managers to monitor and maintain quality metrics solely for their own facility while corporate-level quality managers can compare and contrast performance across plants. Depending on the variation in products produced at different plants, managers might only compare key performance indicators such as cumulative scrap or giveaway or they might directly compare a single product. At the corporate level, access to this multi-plant data can be a key enabler of supply chain optimization efforts.
What are the basic expectations of a multi-plant rollup:
- Corporate offices want to make accurate comparisons of quality metrics between different plants.
- Plant managers want to drill into their data set in order to perform root-cause analysis.
- IT wants to minimize the number of moving parts during a system rollout and reduce the need for ongoing maintenance.
- Everyone wants a single source of truth regarding quality information across a corporate environment.
System design considerations
A successful multi-plant rollup design and deployment requires coordination between Quality and IT departments. Either department may have a set of constraints that limit the scope of the system and should be identified during the design phase.
Common constraints that may affect the system design:
- Lack of reliable internet connections at individual plants.
- Existing deployments at individual plants.
- Variation in quality measurement standards between plants
Typical system configurations
Corporate-wide deployment with plant-wide views
Only a single GainSeeker system is deployed across the entire fleet, usually at either a corporate office or at a primary plant site. All production data is consolidated in a single database and by default any qualified GainSeeker user would be capable of viewing data from across the participating plants. A traceability field is used to identify which plant a dataset comes from. Certain elements such as data entry may still be partially or fully administered at the plant level. If plants should not be able to see data from other plants, database views can be created that allow plant level users to only see data that originated from their plant. If this is not a strict requirement, individual plants can apply default filters on their retrievals to achieve a similar result.
Plant-specific deployments with regular corporate sync
This configuration normally occurs when individual plants have significant investment in an existing GainSeeker system, with enough dependent systems that migrating to a centralized deployment is too burdensome. In this case, relevant data can be regularly exported from the plant level system and uploaded into a corporate server. The data can be exported automatically so it doesn’t need to be burdensome. This automation can be done with built-in SQL Server sync tools that manage the transfer at the database level. Or it can be automated using a GainSeeker export (python or otherwise) that pushes the data to the central system, which then reads the data in. With either method, automation minimizes the ongoing work and coordination needed. This gives plant-level administrators high levels of flexibility to shape their own systems, while still giving corporate managers access to relevant information. This does create additional ongoing work and coordination for both IT and Quality departments, so this configuration is not advised unless there are preexisting constraints that require it.