CASE STUDY · INDUSTRY 4.0 / MANUFACTURING SOFTWARE
Building a real-time production dashboard for a manufacturing plant.
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised manufacturing plant. Name withheld under confidentiality.
Machine connectors and a live OEE and downtime dashboard.
We connected the machines on the plant's main lines so that running state and counts came straight from the controllers. We built a dashboard showing availability, performance and quality, and OEE per line and per shift. When a machine stopped, a simple screen at the line asked the operator to pick a reason from a short list. The reason was stored with the stop, so downtime had a cause attached.
- 1Production data kept on paper and in spreadsheets.
- 2Operators wrote counts and stoppage notes on sheets at the end of the shift.
- 3Supervisors keyed them into spreadsheets later.
- 4Managers saw the previous day's output the next morning, and the downtime reasons were often guesses.
- 5Nobody could say with confidence which machine, shift or product lost the most time.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Operators found the reason-code list too long, and during busy periods many stops were left as "other"
The data looked complete but told us nothing. We cut the list to the dozen most common reasons, grouped the rest, and put the most frequent at the top. Supervisors reviewed unexplained stops at the end of each shift, and the plant manager asked about them in the daily meeting.
- PROBLEM 02The share of unexplained stops fell as people saw the data being used
- PROBLEM 03A second hurdle was the shift pattern
Some stops spanned a shift change, and the first version assigned the whole stop to the shift that ended it. Two supervisors saw numbers they could not explain and distrusted the screen. We split long events at shift boundaries and shared the rule in a one-page note on the dashboard itself.
- PROBLEM 04We then sat with supervisors from each shift and compared the screen with their own notes for a week
Once the two matched, use of the dashboard became routine.
03 · THE PROCESS
How we ran it.
We reviewed progress weekly with the plant manager and spent time on the floor every sprint. Early versions were printed and pinned up for feedback before the screens went live.
- 01Step 1
Weeks 1 to 2: line walks, machine and controller inventory, agreement on OEE definitions with the plant team.
- 02Step 2
Weeks 3 to 6: connectors built and tested on one line, dashboard prototype shown on the floor.
- 03Step 3
Weeks 7 to 10: reason-code screens introduced, second and third lines connected, shift reports automated.
- 04Step 4
Weeks 11 to 12: remaining lines, training for supervisors and handover.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Shift handover starts with the dashboard instead of a paper sheet.
- NOW 02
Supervisors act on downtime during the shift, not the day after.
- NOW 03
The plant has agreed OEE definitions that everyone uses, and improvement work is targeted at the biggest stop reasons.
- NOW 04
Adding a new line now follows a repeatable pattern.
OEE visible per shift
Reporting delay down from next day to real time
05 · WHAT WE BUILT
How it works.
- Small collectors read machine states and counters through the controllers' standard protocols in read-only mode.
- They publish to a central service that turns raw signals into events: run, stop, slow and reject.
- A calculation layer produces OEE with the plant's agreed definitions for planned stops and ideal cycle times.
- Dashboards read from that layer, not from machines directly, so a dashboard problem cannot affect a controller.
- The collectors sit in a separate network zone, with outbound-only connections and named user accounts for support.
- We added operating controls.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- Production data kept on paper and in spreadsheets. Operators wrote counts and stoppage notes on sheets at the end of the shift. Supervisors keyed them into spreadsheets later. Managers saw the previous day's output the next morning, and the downtime reasons were often guesses. Nobody could say with confidence which machine, shift or product lost the most time.
- What did Brandsmashers build?
- Machine connectors and a live OEE and downtime dashboard. We connected the machines on the plant's main lines so that running state and counts came straight from the controllers. We built a dashboard showing availability, performance and quality, and OEE per line and per shift. When a machine stopped, a simple screen at the line asked the operator to pick a reason from a short list. The reason was stored with the stop, so downtime had a cause attached.
- How was the work run?
- We reviewed progress weekly with the plant manager and spent time on the floor every sprint. Early versions were printed and pinned up for feedback before the screens went live.
- What were the results?
- OEE visible per shift; reporting delay down from next day to real time.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
