Skip to content

Pillarstone

Nine plants, nine production systems, one model

Pillarstone casts precision components at nine plants in the UK, Poland and Norway, each running its own fork of the same manufacturing execution system. We consolidated them onto one production model without forcing nine shop floors to work the same way.

Client
Pillarstone
Sector
Manufacturing
Run
11 months · Nov 2023 – Sep 2024
Filed
2024-12-09
Capability
Systems integration · Data engineering · Cloud migration
Stack
Python 3.12 · FastAPI · PostgreSQL 16 · Apache Kafka · MQTT · dbt · Kubernetes · AWS · Grafana

Impact

  • 9 → 1

    Plant-local MES forks replaced by one production model

  • 3 hours

    Group production close, down from six working days

  • 4.1%

    Scrap rate across all nine plants, down from 6.8%

Challenge

Manufacturing
11 months · Nov 2023 – Sep 2024

The nine forks had drifted for over a decade, and so had their definitions: a "unit produced" was counted at a different point on the line at every plant, which made group reporting an argument rather than a number. Closing production across the group took six working days of manual Excel consolidation, so the board reviewed a picture of the previous month in the middle of the current one. Two plants had upgraded their MES version and could no longer exchange files with the other seven. Any solution that required every plant to adopt one process would have stalled — the Norwegian plant’s traceability requirements are genuinely different from the Polish plant’s.

Solution

We separated the model from the process. One canonical production model defines what an order, a batch, a scrap event and a machine hour mean at group level; per-plant adapters translate local practice into it, so plants kept their own working methods and stopped arguing about definitions. MQTT collectors on 340 machines publish counts directly rather than relying on end-of-shift keying, buffering seventy-two hours locally so a network drop never loses a shift. dbt models the semantic layer, so a metric is defined once and every report derives from that definition. We rolled out plant by plant, smallest first, and left each plant with a named local owner trained on the adapter before moving on.

Plates

  • Diagram showing nine plant sites feeding through individual adapters into a single canonical production model, with the model then serving group reporting, the semantic layer and plant-level dashboards.
    Plate 01Adapters absorb local practice so the model stays one model.
  • Shop-floor terminal mounted beside a casting line showing the current order, live unit count, scrap entries by reason code, and an offline indicator confirming seventy-two hours of local buffering.
    Plate 02The offline indicator earned more trust than any dashboard.
  • Group production close report comparing output, scrap rate and machine utilisation across all nine plants for the month, with each plant’s figures traced back to its source adapter.
    Plate 03Six working days of consolidation became a three-hour run.

Testimony

Twenty-six years of scheme data, four character encodings, and a benefit rule set that lived entirely in the head of an administrator who retired in April. They wrote it down, tested it against 40,000 member records, and got it wrong twice before they got it right. Both times we heard it from them first.

Chidi Okafor · Director of Scheme Technology, Pillarstone4 out of 5