For my org
Use cases / Manufacturing
Real work, anonymised
Every stop understood. Every fix checked. Every week measured.
This comes from real work with a manufacturer. On their line, the answer to "what happened?" was spread across separate systems and the people on the floor. Those systems were connected as work surfaces, and we, as a service partner, built custom reporting and data layers in Microsoft 365 and Dynamics 365 and some small automations in a week - all aimed at a 2% target uplift in Overall Equipment Effectiveness (OEE).
The company, the site, the machines and the product are left out, and anything that could identify them is generalised. The film and the worked examples are illustrations.
- ConnectThe systems behind the line, each as a permissioned work surface.
- BuildCustom data layers in Microsoft 365 and Dynamics 365, built as a service partner in a week.
- AutomateSmall, checked jobs, such as handovers, incident drafts and weekly loss summaries.
- AssureTimestamps, gaps and downtime codes checked before anyone relies on the numbers.
The starting point
The evidence was there. It was just spread out.
A stop is not an explanation. Each kind of source holds part of the story, and none of them answers the question a leader actually asks: what changed, what did the team do and what should happen next?
Machine events
ShowsWhat a system registered, and when.
Can't showWhy. A recorded alarm is not a confirmed cause.
Production and downtime
ShowsThe effect on pace, output and lost minutes.
Can't showWhich event started the slide.
Maintenance records
ShowsThe work done and the history behind it.
Can't showWhether the last fix actually held.
Manuals and procedures
ShowsThe approved method at a given revision.
Can't showWhat happened on this shift.
Quality records
ShowsExceptions, rejects and what was held back.
Can't showWhat on the line led up to them.
Shift notes and people
ShowsWhat was seen, what was tried and what was handed on.
Can't showThe exact order. An account still needs checking against the event history.
- Time goes on rebuilding the storyTeams reconstruct timelines, reconcile accounts and search for the right procedure.
- The next shift starts blindThey inherit a warning without knowing whether the last recovery held.
- Effort follows the loudest alarmReviews rank the final fault code and miss the slowdown or failed restarts that came first.
Connect the surfaces
The systems stayed where they were. Pals reached across them.
Each source connects as a work surface: approved by its owner, limited to what each role may see and read-only wherever possible. Connecting a system is its owner's decision, one at a time.
Work surfaces
- Machine events and alarms
- Production and downtime
- Maintenance system
- Controlled documents
- Quality records
- Shift notes
Custom data layers
Answers by role
- Operator
- Technician
- Engineer
- Operations lead
A typical set of surfaces. Which ones connect depends on the line and what the manufacturer's IT, data and Quality owners approve.
The data layers
Built for the questions a dashboard can't answer.
We built custom data layers in Microsoft 365 and Dynamics 365, shaped around the machines and the definitions on that line.
- One timelineEvents from machine telemetry line up on one clock, so the order can be trusted.
- Snapshots, then detailSnapshots find the period worth studying. Raw events rebuild what happened in it.
- Compared with a good runA stable run on the same product shows which behaviour is really unusual.
- Plain languagePeople ask in the words they use on the floor, and Pals respond in kind.
Did the line become unstable before the 2 am stop?
- Observation
- From 01:12, running pace fell and the line left its running state four times. Each restart held for less time than the one before.
Event history, downtime log. - Interpretation
- The 02:03 fault looks like the end of this sequence rather than the start of it.
- Uncertainty
- There is no note on what was seen at 01:40, and one data feed has a gap.
- Next check
- Ask the shift lead about 01:40, then inspect using the approved instruction. This is not yet a root cause.
An illustration of how an answer is laid out, not a record from any plant.
1 week
to build the custom data layers and some small automations
The sprint
Built in a week.
We built the custom data layers and some small automations in a single focused week, turning data spread across separate systems into surfaces Pals can read and people can check.
How long this takes elsewhere depends on the systems and the data.
Why we recommend Partners
Surfaces ready for each client's needs.
Every plant's systems are different. A partner with a deep understanding of the client's environment can prepare the surfaces and data environments around what a client needs, so its Pals have the right data to work from.
Have a partner build itOne event, four views
Same evidence. The answer each role needs.
Operator
The present condition, the approved instruction and a clear point to escalate.
Technician
State changes in order, earlier interventions and the checks still open.
Engineer
Comparison across occurrences, competing explanations and a way to test a remedy.
Operations lead
How long and how often, the effect on OEE and who owns the next action.
If an engineer revises a finding after inspecting the equipment, the handover changes with it.
Automation and assurance
Small jobs done. Data the team can stand behind.
We built some small automations alongside the data layers, with data checks to back them up. These are the kinds of jobs they cover.
Small process automation
- The shift handover drafted from the records, for the lead to check
- Incident reports drafted, with facts kept apart from interpretation
- Each incident logged once, with no duplicates
- Repeat stops grouped and counted, so one condition is not ten incidents
- A weekly summary of the stops that matter, ready for the morning meeting
Each is small on its own. None changes a machine setting or a controlled document.
Data assurance
- Timestamps aligned across sources before any comparison
- Missing records and inconsistent downtime codes flagged early
- Every statement carries its source and time
- Recorded signals, people's accounts and hypotheses kept apart
- Corrections kept: the first assessment and what replaced it
If the data can't support a claim, the Pal says so, and that gap becomes the first thing to fix.
2%
target uplift in OEE
The target
A small number that is real money on a busy line.
2% was the target for this work. It was set against the manufacturer's own baseline and OEE calculation, fixed before measuring started, then compared like for like.
Availability
Fewer repeat stops, and recoveries that hold rather than quick restarts that fail again.
Performance
Slow running and unstable pace seen early, before they become a stop.
Quality
Good output and rejects watched throughout, so a gain elsewhere never moves the risk here.
| What is measured | The question it answers |
|---|---|
| Time to an accepted explanation or handover | Did the team reach a usable account sooner? |
| Time to sustained recovery | Did the recovery hold? |
| Repeat events per operating hour and minutes lost | Did the targeted loss change? |
| OEE and its drivers | Did a local gain reach the wider measure? |
| Safety events, quality exceptions and rejects | Was risk moved somewhere else? |
| Data completeness, source support and correction rate | Can the result, and the Pal's part in it, be trusted? |
Measure
An engineer picks the number. The Pal does the watching.
When a pattern looks suspicious, an engineer can ask the Pal to focus on the KPI or metric behind it. The Pal finds where that number lives in the connected surfaces, sets a baseline and observes the data over eight weeks, running a Six Sigma quality process on its own.
- Asked in plain wordsNo forms to fill in. The engineer says what looks wrong and which number to follow.
- Captured on scheduleHourly, daily or weekly, straight from the connected surfaces. A value that can't be captured shows as a gap, never a guess.
- Read every weekThe Pal says what moved, what it means and how sure it is, so a slow drift gets noticed.
- Watched from all sidesGuardrails such as rejects sit beside the main number, so a gain in one place can't hide a loss in another.
Focus on repeat stops per operating hour for the next eight weeks. Something looks off after changeovers.
- Week 4: what the Pal sees
- Repeat stops rose from 1.4 to 2.1 per operating hour over three weeks, mostly in the first hour after a changeover. Rejects stayed inside their guardrail.
- What it means
- The pattern follows changeovers, not the fault codes logged against the stops.
- How sure the Pal is
- Fairly sure. Two shifts have no notes, and the changeover log has a gap.
- For the engineer to decide
- Try a revised check after changeovers for the remaining four weeks? It can be rolled back at any point.
An illustration of a weekly read-out, not a record from any plant.
Six Sigma DMAIC, run by the Pal
Define
The PalWrites the charter: the problem, the goal, the scope and the metrics.
Measure
The PalCaptures the main number and its guardrails, and sets the baseline.
Analyse
The PalWrites the weekly read-out, keeping what the data shows apart from what it suggests.
Improve
The Pal proposes, the engineer approvesA change, its expected effect and how to roll it back. Nothing is tried until it is approved.
Control
The Pal suggests, the engineer decidesKeep the change, try again or roll it back. A kept gain stays on the Pal's watch.
The Pal only reads the connected systems to do this. It tracks the line, not the people on it, and any change to equipment, settings or procedures still goes through the site's normal approvals.
Who decides
Pals do the work. People make the call.
Pals do
- Retrieve and line up the evidence
- Explain the sequence and what is still unknown
- Watch a chosen KPI and report on it every week
- Draft handovers, reports and summaries for a person to check
The manufacturer's people decide
- Equipment controls, safety systems and validated processes stay as they are
- Product release and quality decisions stay with those authorised to make them
- A root cause is declared by qualified people, once the evidence supports it
- Which changes to try on a watched number, and whether to keep them
Bring one line and one recurring loss.
We'll look at whether it's worth testing together.
This page comes from real work, anonymised: the company, site, machines and product are left out and identifying details are generalised. The film and worked examples are illustrations, and the 2% OEE uplift is a target, not a reported or guaranteed result.