Home · Solutions · Operations & quality
Solution · Operations & qualityOutput, downtime and scrap for four plants, posted in Teams before the morning meeting
The daily production report without the 6 a.m. spreadsheet
Robots pull counts, downtime and confirmations from MES, SCADA and ERP after each shift; shift leaders comment on a Teams card; one report reaches the plant channel before the meeting.
Executive summary
Stop paying production controllers to retype MES numbers into a spreadsheet the meeting does not trust.
The morning meeting keeps its report and its rhythm; what changes is where the numbers come from.
The report is on the channel before the meeting every working day, with the same figures as the MES and the ERP, because it was built from them.
reporting database (Azure SQL Database or the group's SQL Server); Power BI semantic model and report; SharePoint shift log and monthly workbook
Business problem
Manufacturing reporting
Every manufacturer runs a daily production report: output per line, scrap, downtime with reasons, plan attainment. In most mid-sized groups it is assembled by hand from three sources that never quite agree: the MES or PLC counters, the shift leader's sheet and the ERP confirmations. Shift leaders write from memory at the end of a night shift; production controllers spend their first hour on copy-paste instead of on the plan; one group analyst knows why the consolidation macro fails on Mondays.
What breaks at scale is trust. Downtime arrives as "other" because the sheet's reason list differs from the MES; scrap is reported by the shift with an interest in the number; a figure challenged at the meeting is corrected afterwards in a file that has already gone out. Four plants end up with four definitions of OEE, and the group target becomes a negotiation.
How it works today
- PersonAt shift end the shift leader fills in the Excel shift sheet: output, scrap and downtime per line, reasons from memory
- WaitingSheets sit on the shared drive until the production controller arrives; night-shift sheets are the least complete
- PersonThe controller copies three sheets into the plant workbook, compares totals with MES counters and ERP confirmations, and corrects what does not match
- PersonFour plant workbooks go by email to the group analyst, who merges them and sends a PDF to the invitees
- Risk of errorThe number on the screen disagrees with the MES; reasons are missing or generic; nobody can tell a real problem from a counting error
- WaitingCorrections agreed at the meeting are made afterwards, by hand, only in the group file
Why the current process costs more than it appears
Nobody planned this work; it accumulated.
- Seventy-five minutes of a controller's morning per plant is the visible cost. Behind it sits the meeting: eight to twelve managers spending part of it on whether the data is right.
- Corrections made after distribution never reach every copy, so week-to-date figures drift and month-end statistics for finance are reconciled again.
- Downtime without a reason cannot be reduced. Forty minutes booked as "other" hides a tooling change, a material shortage or a breakdown.
- A group that cannot trust its daily numbers cannot set line-level targets, so OEE stays a monthly figure discussed in retrospect.
Cost of inaction
110 hours a month of planning-literate people stay on copy-paste, the meeting starts every day with a data check, and the improvement programme keeps working from reasons reconstructed the next morning.
The larger cost is invisible: line-level OEE targets and fair comparisons between plants are decisions the group cannot take while its numbers are in dispute.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A European furniture manufacturer: four plants in Poland and Germany, 22 lines, about 1,800 employees; an MES on 14 lines, SCADA counters on 6, manual counts on 2; a mid-market ERP; Microsoft 365 E3 and Power BI Pro.
88 plant-days a month (4 plants × 22 working days); about 1,300 line-shift records a month; one report per plant and one for the group every working day.
Excel shift sheets; about 75 minutes of a controller's morning per plant to consolidate them against the MES and the ERP; then a group analyst's PDF.
Roughly 110 hours a month of controllers' time across the group, plus the analyst's hour; a late report that disagrees with the MES on most days.
Robots collect counts, downtime and confirmations from MES, SCADA and ERP after every shift, compute OEE, scrap and plan deviation by fixed rules, ask shift leaders for missing reasons on a Teams card and post the summary in each plant channel before the meeting.
In the modelled case the 110 hours a month go back to planning work, the report reaches the channel before the meeting with the same figures as the MES and the ERP, and every stop above the threshold carries a reason code or a visible gap. These are modelled figures, not a client result.
Proposed solution
The morning meeting keeps its report and its rhythm; what changes is where the numbers come from. A reporting robot does what the controllers do today, but from the sources instead of the sheets. After every shift an Orchestrator time trigger starts the collection job: MES counts, run time and downtime events through SQL views, SCADA historian counters for the six lines without MES, ERP confirmations and plan. OEE, scrap and plan deviation are calculated per line and shift with fixed, versioned rules, identical for all four plants.
The shift leader's part shrinks to what only the shift leader knows: a Workflows flow in Microsoft Teams sends an Adaptive Card with the numbers filled in and a reason code and comment field for each stop above the threshold. Answers land in a SharePoint list, the shift log; a missing answer goes into the report as a gap, not as a number. Before the meeting the report robot merges everything, writes the reporting database, refreshes the Power BI semantic model through the REST API and posts a summary card in each plant channel; a monthly workbook on SharePoint keeps Excel as an output, not the source. No AI is involved: the inputs are system data, the rules are the plants' own, and judgement stays with the people.
UiPath Orchestrator time triggers and audit; UiPath Robots with Database and Excel Online activities; UiPath Integration Service connectors for Microsoft Teams and Microsoft OneDrive & SharePoint; Workflows in Microsoft Teams (Power Automate) with Adaptive Cards and wait-for-response; Power BI refresh through the REST API and the report tab in Teams
Collection jobs, calculation rules and reason-code mapping; the Adaptive Card and the shift log; the reporting database, Power BI semantic model and report; the summary card, the monthly workbook and the controllers' runbook
SQL views on the MES and the SCADA historian, prepared with the plant's automation engineer; ERP confirmations through a database view or API
How the automated process works
- AutomationMinutes after each shift ends, an Orchestrator time trigger starts the collection job: MES counts, run time and downtime events, SCADA counters, ERP confirmations and plan
- AutomationThe robot calculates availability, performance and quality per line and shift and flags deviations by the plant's rules: OEE below target, scrap above threshold, unplanned downtime over the limit, MES and ERP quantities that disagree
- AutomationThe shift record goes to a SharePoint list; the new item starts the Workflows flow, which sends the shift leader an Adaptive Card in Teams with the numbers, the flagged stops and fields for reasons, comments and manual counts
- PersonThe shift leader completes the card before leaving; the answer is written back with a timestamp; after the agreed window the flow closes the card and marks the record "no comment received"
- AutomationBefore the meeting the report robot merges comments and records, writes the reporting database, triggers the Power BI refresh, updates the monthly workbook and posts the summary card in each plant channel
- SystemIf a source is unreachable, Orchestrator retries; if it still fails, the report goes out with that source marked as missing and the controller is alerted in Teams
Human-in-the-loop model
Automation handles
- Collection from MES, SCADA and ERP after every shift
- OEE, scrap and plan-deviation arithmetic with fixed, versioned rules
- The request for reasons, the consolidation, the Power BI refresh, the summary and gap detection
People decide
- Shift leaders assign the reason code to each flagged stop and add the context only they have
- Plant managers decide what to do about the flagged lines, on numbers everyone shares
- Controllers own thresholds, cycle-time standards and reason-code mapping, changed through a controlled release
Before and after
Systems and integrations
Everything below runs on licences and systems you already hold, or would need anyway.
Inputs
- MES counts, run time and downtime events
- SCADA historian counters
- ERP confirmations and plan
- planners' line plan in Excel on SharePoint
- shift leaders' answers from the Teams card
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- Workflows in Microsoft Teams (Power Automate)
Target systems
- reporting database (Azure SQL Database or the group's SQL Server)
- Power BI semantic model and report
- SharePoint shift log and monthly workbook
- Microsoft Teams plant channels
Human touchpoints: Adaptive Card in Teams for shift leaders; summary card in the plant channel; Power BI report tab; controller alerts in Teams
Technologies used
time triggers after each shift, collection and calculation jobs, retries, logs, audit
Aread MES, SCADA historian and ERP confirmations through SQL views; write the reporting database
Ashift-log list items, plan and monthly workbooks in Excel Online, summary cards in the plant channels
AAdaptive Card to the shift leader with wait-for-response, started by the new list item
Asemantic model over the reporting database, report tab in the plant channel, refresh through the REST API with a service principal
Acounts, downtime events, confirmations and plan, through SQL views or the ERP's API
CIllustrative economic model
A model, not a promise.
Only the controllers' consolidation time is counted; the analyst's hour, the meeting time and the post-meeting corrections are left out, so the figure is conservative. Seventy-five minutes per plant-day reflects three shift sheets reconciled against the MES and the ERP; €30 is a fully loaded hourly cost for a controller or planner in Central Europe. Capacity released, not headcount removed; all figures are illustrative and none is measured at a client.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- The report is on the channel before the meeting every working day, with the same figures as the MES and the ERP, because it was built from them
- Around 110 hours a month of controllers' time in the modelled group return to planning work
- Downtime carries a reason code from the shift that lost the time, so the improvement programme works from a complete Pareto rather than from "other"
- One definition of OEE, scrap and unplanned downtime across the four plants; a line steadily below target is flagged on day one, not at month end
The management view
- The morning meeting starts from the exception list instead of a debate about which file is right
- Week-to-date and month-to-date views come from the same records as the daily ones; month-end statistics for finance need no second reconciliation
- Every figure has a trail: source system, extraction time, rule version, the shift leader's comment and its timestamp
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- Robots read production systems through dedicated accounts with read rights on the agreed views only; the reporting database is the only target they write to
- Database and API secrets sit in Orchestrator's credential store, backed by Azure Key Vault where the group uses it; the Power BI refresh runs under a service principal scoped to one workspace
- Your Microsoft 365 tenant and your own database hold the production data throughout; the Orchestrator behind it sits in the EU region of UiPath Automation Cloud or on your own Automation Suite
- Thresholds and reason-code mappings are versioned and changed only with the process owner's sign-off; shift leaders' answers are stored with identity and timestamp
Why now
OEE targets are moving into group-level annual plans; a target set on four spreadsheets with four definitions is a negotiation, and the consolidation behind it costs the modelled €3,300 a month before any meeting time is counted
Planners and production controllers are scarce in the plants we see; their first hour on copy-paste is the least defensible use of the ones you have
The pieces are standard: Orchestrator time triggers, Integration Service connectors, Adaptive Cards with wait-for-response and the Power BI refresh API; and since Microsoft retired the old Teams connectors in May 2026, plants that pushed MES alerts through incoming webhooks need the Workflows route anyway
Relevant executive roles
One daily picture of four plants, built from the systems; the operations review is about flagged lines, not data
The meeting starts from what went wrong and why, with reason codes from the shift that lost the time
Cost-per-unit and month-end statistics come from the same records as the daily report
A governed integration with MES, SCADA and ERP replaces macros, shared-drive workbooks and email chains
Common questions and objections
The MES reports the lines it is connected to, in one plant, with its own logic. The morning report needs all four plants, the lines without MES, the ERP confirmations and the shift leaders' reasons in one place. The robot treats the MES as its best source, not as a competitor.
The card arrives with the numbers in it and asks only what the systems cannot know: the reason for the 40-minute stop the MES recorded. A minute on a phone answers it, and a missing answer shows as a gap instead of vanishing into a total.
The report goes out on time with that source marked as missing and the controller alerted. Counts that disagree with the ERP are flagged, never averaged; in the first weeks this feedback is usually the most valuable output.
When this is not the right solution
- One plant with an MES that covers every line and a shift report the meeting trusts: a Power BI report on the MES database is enough
- Counts and downtime are captured only on paper; capturing the data at the line comes first, consolidation after
- The plants do not agree on what counts as scrap or unplanned downtime and nobody owns the definitions; automation would only make the disagreement visible faster
A question for the next management meeting
Which number does our morning meeting believe, the MES, the ERP or the spreadsheet, and how many hours a month do we spend making the three agree?
Implementation approach
The first week looks the same at every client: we look at the data.
We deliver
- Discovery in one plant: sources per line, the current sheets and the definitions of OEE, scrap and unplanned downtime
- Collection jobs, calculation rules and reason-code mapping, versioned and documented
- The Adaptive Card flow, the shift log, the reporting database, the Power BI semantic model and report, the summary cards
- Parallel run against the manual report in the pilot plant, the controllers' runbook, then rollout plant by plant with hypercare
We need from you
- Read access to MES, SCADA historian and ERP tables or views, arranged with your automation and IT teams
- A process owner in operations, one controller per plant, and three months of shift sheets with the matching MES and ERP data
- A Power BI workspace, a service principal for the refresh and the plant channels in Teams
Stages
Discovery
Sources, definitions, thresholds and the current report in the pilot plant
Design and build
Data model, rules, card flow, reporting database, Power BI model and report in your tenant
Validation
Parallel run against the manual report for two to four weeks; acceptance by the plant manager
Rollout
Plant by plant with hypercare; then threshold tuning, new lines, week and month views
Quick win. Effort depends on how many distinct sources the lines have, whether the MES and the ERP expose usable views, and how far the plants' definitions agree.
The 6 a.m. meeting starts by arguing about whose number is right.
Send us one week of shift sheets from one plant with the MES export and the ERP confirmations for the same days. We return a written assessment of where the three disagree and which lines can be reported without a person.
Start with one plant and one weekThe neighbouring process usually has the same problem
The board pack should not depend on which analyst merged which spreadsheet on which day.
View solution Supply chainInventory that agrees: WMS and ERP reconciled every nightStop discovering at the cycle count, or when an order cannot ship, that the WMS and the ERP disagree.
View solution Operations & qualityNon-conformances and CAPA handled in TeamsContainment, root cause, supplier 8D and effectiveness checks live in one spreadsheet and three mailboxes.
View solutionIndustries we deliver this in most oftenManufacturing & industry