Manufacturing analytics build · Power BI on routings, shift logs and downtime
The plan existed. The actuals existed. Nobody held them next to each other.
A precision engineering manufacturer running 274 machines across ten work centre types. Routed work orders move through operations 10 to 110, each with a planned time and an actual one. KoderXpert joined routings, shift logs, downtime events and QC records into one production model and delivered three linked Power BI views.
Data modelling, DAX and dashboard build by KoderXpert Technologies Pvt. Ltd.
Power BI & data analytics · Ahmedabad & Gandhinagar, India
- Client
- Precision engineering, name withheld
- Domain
- Production & shop floor analytics
- Source
- Work orders, routings, shift logs, downtime, QC
- Platform
- Microsoft Power BI
- Headline result
- Overruns visible on the day, not the delivery date
01 · Overview
Everything was recorded. Nothing was compared.
- A CNC led machine shop with 274 machines across ten work centre types, from grinding and drilling to honing, pressing and manual quality processes.
- Planned cycle times sat in the routing. Actual times sat in shift logs. The variance between them, the number that predicts a late delivery, was computed by nobody, routinely, while there was still time to act.
- KoderXpert unified the shop floor records on shared work centre, part, shift and order dimensions and built three linked views: a command page, shift execution detail and a delayed orders exception page.
02 · The challenge
Everything was recorded. Nothing was compared, until the order was already late.
Each failure below is the same failure: complete records at operation grain, and no view that rolled them up without losing the operation that caused the problem.
Plan and actual lived apart
Planned cycle times sat in the routing and actual times sat in shift logs. Nothing routinely put the two on the same axis at work centre level.
The cost → the variance was found on the delivery dateOrder status was a phone call
Whether a job was pending, running, on hold or rejected was known to the person standing next to it, and to almost nobody else.
The cost → planning ran on hearsayDowntime was logged, not analysed
Missing parts, power failure, breakdown and servicing were recorded as events, never totalled, never ranked, so everything was logged equally and nothing was attacked.
The cost → the biggest loss was never prioritisedEight overlapping order states
Planned, unplanned, pending, scheduled, running, hold, rejected and completed each needed a rule that survives contact with a shop floor rather than a tidy definition.
The cost → no shared picture of the order bookOperation grain, order decisions
One order becomes eleven operations across several work centres and shifts. Rolling that up without losing the failing operation is the core modelling problem.
The cost → shortfalls got blamed on the orderSupervisors will not use a slow report
If an answer takes longer than walking to the machine, the dashboard is decoration, however correct it is.
The cost → a correct report nobody openeda production dashboard earns its place when a supervisor changes a decision
03 · Before vs after
Same records. One page instead of a walk to the machine.
Left is what production reporting looked like before. Right is what three linked views replaced it with.
- ✗Planned times in the routing, actual times in shift logs, never compared
- ✗Order status established by phone call
- ✗Downtime recorded as events, never ranked by loss
- ✗Shortfalls blamed on the order rather than traced to an operation
- ✗Delays discovered when a customer asked
- ✗Reports slower than walking to the machine
- ✓Planned against actual hours for every work centre, colour coded
- ✓Eight order states live on one panel
- ✓Downtime ranked by cause, hours lost and orders affected
- ✓Every part followed operation by operation, shift by shift
- ✓Scheduled against actual end time, ranked by how late
- ✓Filter first, button driven, fast enough to beat walking
drag the orange handle, or use the arrow keys ✨
04 · Goals
What the build had to achieve
Six goals agreed on the floor, not in a meeting room, each phrased so a supervisor could tell whether it had been met.
Expose plan versus actual variance. Per work centre, colour coded, so an overrun announces itself and needs no interpretation.
One view of every order state. Planned through completed on a single command panel, so the shape of the order book is readable without opening a report.
Make downtime attackable. Ranked by cause rather than buried in a log, so the biggest loss gets addressed first.
Track execution shift by shift. Output, work in progress and remaining quantity, per shift and per unit, attributable to the shift that produced it.
Surface delays while they matter. Scheduled against actual end time with a delay duration, as a worklist rather than an audit.
Fast enough for the floor. Answers in seconds, filtered by shift, date, part and work centre, or supervisors go back to walking.
05 · What we delivered
Six blocks that turn a routing into a decision
Each block answers one named failure from section 02, and each was checked against the floor before sign off.
Planning stats, eight states at once
Planned, unplanned, pending, scheduled, running, hold, rejected and completed, each as a live count. The shape of the order book without opening a single report.
no more status callsPlan versus actual per work centre
The centrepiece. Planned hours beside actual hours for every work centre, colour coded so an overrun announces itself. GC04 was planned at 1.63 hours and took 7.08.
no analysis requiredDowntime distribution by cause
Missing parts, power failure, servicing and breakdown, ranked. A downtime log becomes a shortlist of things to fix.
the biggest loss, firstWork centre mix and machine count
274 machines across ten types, CNC dominant, the context that makes any utilisation figure mean something.
utilisation, in contextQC outcome panel
Good, scrap and defect counts alongside production, so quality is read in the same glance as throughput rather than in a separate review.
quality beside outputShift and operation traceability
Every work order broken to the operation: quantity to produce, produced, work in progress and remaining, by shift and by unit.
pinned to the OP that caused itPlanned hours against actual
one bar tells you nothing, two tell you where the week went
Ten work centres, planned hours first. Wait a moment or press Actual and the same axis redraws with what the machines really took. GC04 was given 1.63 hours and used 7.08. Click any bar to read that work centre.
Routing times as planned. Every one of these looks reasonable on its own.
Catching the variance at the work centre is the cheapest place to catch it06 · Functional deep dive
How the variance actually gets computed
Four modelling decisions that decide whether the number on the screen survives contact with the shop floor.
Two grains, one roll up
Data arrives at operation grain and decisions are made at order grain. Aggregating without losing the failing operation is the whole problem.
- Operations carried as their own fact, with the order as a dimension
- Variance computed per operation, then summarised per work centre
- The worst operation preserved in the roll up rather than averaged away
Plan versus actual as a verdict, not a column
A table with two columns tells nobody anything. The visual has to say at a glance which work centre is bleeding hours.
- Variance expressed as a ratio and as an absolute, both available
- Conditional formatting thresholds agreed with production, not guessed
- Colour carries the verdict; the number carries the detail
Eight order states with rules that hold
Planned, unplanned, pending, scheduled, running, hold, rejected and completed overlap in practice, so each needed a rule that resolves an order to exactly one state.
- Precedence order agreed with planning and documented
- Each state carried as its own measure for the command panel
- States reconciled so the eight counts sum to the order book
Shift structure that is not tidy
First shift, rotations and multiple units mean output has to be attributed to the shift that produced it rather than to the day the order closed.
- Shift dimension keyed on unit and rotation, not on date alone
- Working duration derived from shift start and end, not assumed
- Output, WIP and remaining quantity all attributable per shift
Downtime, ranked instead of logged
everything was recorded, nothing was ranked
The same downtime events, sorted three ways. Event count is what the log gives you. Sort by hours lost and the order changes, because a short frequent stoppage and a long rare one are different problems. Sort by orders affected to see which cause is costing deliveries.
Ranked by how often it happens, which is what a downtime log naturally gives you.
A log becomes a shortlist of things to fix07 · How we built it
Six stages from routing to command view
It started on the floor rather than in the data, and that order is why supervisors use it.
Shop floor walkthrough week one
Followed a real work order from routing to despatch before designing anything, so the model matched how work actually moves rather than how the schema describes it.
Data modelling week two
Work orders, routings, shift logs, downtime and QC unified on shared work centre, part, shift and order dimensions.
DAX development about ten days
Variance, order state and delay measures built to hold at both operation and order grain without double counting the order across its operations.
Command view design one week
One page carrying the eight numbers a production manager checks first, laid out for a thirty second read rather than a study.
Drill through build four days
Shift wise and delayed order pages wired to the main view with navigation buttons, so a manager moves from symptom to detail without hunting.
Validation, training and tuning final week
Planned and actual hours reconciled back to routings and shift records, then formatting thresholds and filters tuned against real floor usage.
08 · Engineering notes
What keeps it fast enough to use
A shop floor dashboard competes with walking to the machine. These are the decisions that let it win.
Measures that hold at two grains
Every variance measure was unit checked at operation level and again at order level, because a measure that is right at one grain and wrong at the other is worse than no measure.
- Order counts use distinct counts over the order dimension
- Hours summed at operation grain and rolled up explicitly
- Divide guards so a work centre with no actuals reads blank
Conditional formatting instead of charts
A supervisor has thirty seconds. A red row is read instantly; a variance chart is studied later, which on a shop floor means never.
- Thresholds set with production and stored as parameters
- Colour used for the verdict only, never for decoration
- Row density tuned so a full work centre list fits one screen
Filter first design
The floor asks narrow questions: this shift, this part, this work centre. The layout assumes that rather than treating filters as an afterthought.
- Every page filtered by shift, date, purchase order, part and work centre
- Filter state carried across the three pages
- Default view scoped to the current shift
Validation against the routings
Planned and actual hours were reconciled back to routings and shift records before sign off, each within tolerance or explained.
- Reconciliation view kept in the report rather than in a spreadsheet
- Checked on every refresh, so drift surfaces as a variance
- QC counts tied back to the quality records
The delay worklist
a delay is not a number, it is a job you can still chase
Every open order plotted by how far it has overrun against how large it is. The worst is picked out when you arrive. Filter by priority to see whether the slippage is concentrated in the work that matters, and click any point to read the order.
Ten open orders. Height is how late, width is how much is riding on it.
Scheduled end against actual, ranked by how late09 · The impact
What changed on the floor
All of it from records the shop already kept, at the grain it already kept them.
- Overruns surface while they can still be fixed, not on the delivery date
- Downtime became a shortlist, so the biggest loss is attacked first
- Shortfalls trace to the operation that caused them rather than to the order
- Delays became a worklist a planner opens first every morning
the variance was always there, now it is caught in time
10 · The stack
What this platform runs on
Six layers, each handed over at the end of the engagement.
A machine running four times its planned cycle will blow the schedule, consume the capacity booked for the next job, and surface as a customer complaint two weeks later. Catching the variance at the work centre is the cheapest place to catch it.
11 · FAQ
Questions manufacturers ask before commissioning a build like this
No, and it is the usual case. The two are joined on shared work centre, part and shift dimensions rather than on a single system key, so they can arrive from an ERP and a shop floor system independently. What has to agree is the dimension mapping, which we settle at the start and hand over documented.
Operations are carried as their own fact with the order as a dimension, so the variance is computed per operation and then summarised. The roll up preserves the worst operation rather than averaging it away, which is what lets a shortfall be pinned to the OP that caused it.
Because of who reads it. A supervisor has thirty seconds between jobs. A red row is acted on immediately; a chart gets studied later, which on a shop floor means never. The thresholds are agreed with production and stored as parameters so they can be tuned without a rebuild.
Usually yes, through a read only connection or a scheduled extract, and nothing is written back. We have built the same reporting layer over Odoo, SAP and custom shop floor systems. Where a machine data source exists, downtime and utilisation can come from it rather than from manual logs.
Typically refreshed per shift, which matches how the floor works. Where a client wants nearer to live, an incremental refresh on the execution tables can run several times a shift. A live connection is possible but rarely worth the load it puts on a production system.
That surfaces immediately, and it is worth surfacing. The first draft shows the reason list as it actually is, including duplicates and blanks. Cleaning that list is usually a short exercise with the supervisors, and the ranking gets sharper as the source improves.
Yes. Unplanned is one of the eight states, with a precedence rule so an order resolves to exactly one state, and rework is carried so it can be read against QC scrap and defect counts rather than inflating good output.
Only if you will act on it. OEE is a useful summary but it hides which of availability, performance or quality moved. We build the three components first and add the composite once the underlying measures are trusted, because a disputed OEE discredits everything beside it.
Six weeks was the shape of this one, including a floor walkthrough before any design. A single unit with clean routings can be faster. Multiple plants, machine data integration or a long history to migrate will extend it, and we scope that against your data.
Production managers open the command view, supervisors and planners open shift execution, and planners chasing deliveries open the delayed orders page first every morning. Three pages rather than one dashboard because the audiences ask different questions.
The reporting layer reads standard tables and holds its logic in versioned views, so a version change is usually a view level fix rather than a rebuild. Nothing is customised inside the ERP, which is the point.
Because we model the shop floor as well as the visuals, and we start by following a work order rather than by reading a schema. We work across ERP, finance and operational data for clients in manufacturing, retail, healthcare and financial services. See our data analytics services or talk to a consultant.
Recording every hour. Do you know which ones you lost?
Tell us what your routings, shift logs and downtime records already hold and what the floor keeps asking for. We will map the model, the measures and the views around those questions.
Read next: where an insurer's book was actually losing money
Manufacturing analytics build · Power BI on routings, shift logs and downtime
The plan existed. The actuals existed. Nobody held them next to each other.
A precision engineering manufacturer running 274 machines across ten work centre types. Routed work orders move through operations 10 to 110, each with a planned time and an actual one. KoderXpert joined routings, shift logs, downtime events and QC records into one production model and delivered three linked Power BI views.
Data modelling, DAX and dashboard build by KoderXpert Technologies Pvt. Ltd.
Power BI & data analytics · Ahmedabad & Gandhinagar, India
- Client
- Precision engineering, name withheld
- Domain
- Production & shop floor analytics
- Source
- Work orders, routings, shift logs, downtime, QC
- Platform
- Microsoft Power BI
- Headline result
- Overruns visible on the day, not the delivery date
01 · Overview
Everything was recorded. Nothing was compared.
- A CNC led machine shop with 274 machines across ten work centre types, from grinding and drilling to honing, pressing and manual quality processes.
- Planned cycle times sat in the routing. Actual times sat in shift logs. The variance between them, the number that predicts a late delivery, was computed by nobody, routinely, while there was still time to act.
- KoderXpert unified the shop floor records on shared work centre, part, shift and order dimensions and built three linked views: a command page, shift execution detail and a delayed orders exception page.
02 · The challenge
Everything was recorded. Nothing was compared, until the order was already late.
Each failure below is the same failure: complete records at operation grain, and no view that rolled them up without losing the operation that caused the problem.
Plan and actual lived apart
Planned cycle times sat in the routing and actual times sat in shift logs. Nothing routinely put the two on the same axis at work centre level.
The cost → the variance was found on the delivery dateOrder status was a phone call
Whether a job was pending, running, on hold or rejected was known to the person standing next to it, and to almost nobody else.
The cost → planning ran on hearsayDowntime was logged, not analysed
Missing parts, power failure, breakdown and servicing were recorded as events, never totalled, never ranked, so everything was logged equally and nothing was attacked.
The cost → the biggest loss was never prioritisedEight overlapping order states
Planned, unplanned, pending, scheduled, running, hold, rejected and completed each needed a rule that survives contact with a shop floor rather than a tidy definition.
The cost → no shared picture of the order bookOperation grain, order decisions
One order becomes eleven operations across several work centres and shifts. Rolling that up without losing the failing operation is the core modelling problem.
The cost → shortfalls got blamed on the orderSupervisors will not use a slow report
If an answer takes longer than walking to the machine, the dashboard is decoration, however correct it is.
The cost → a correct report nobody openeda production dashboard earns its place when a supervisor changes a decision
03 · Before vs after
Same records. One page instead of a walk to the machine.
Left is what production reporting looked like before. Right is what three linked views replaced it with.
- ✗Planned times in the routing, actual times in shift logs, never compared
- ✗Order status established by phone call
- ✗Downtime recorded as events, never ranked by loss
- ✗Shortfalls blamed on the order rather than traced to an operation
- ✗Delays discovered when a customer asked
- ✗Reports slower than walking to the machine
- ✓Planned against actual hours for every work centre, colour coded
- ✓Eight order states live on one panel
- ✓Downtime ranked by cause, hours lost and orders affected
- ✓Every part followed operation by operation, shift by shift
- ✓Scheduled against actual end time, ranked by how late
- ✓Filter first, button driven, fast enough to beat walking
drag the orange handle, or use the arrow keys ✨
04 · Goals
What the build had to achieve
Six goals agreed on the floor, not in a meeting room, each phrased so a supervisor could tell whether it had been met.
Expose plan versus actual variance. Per work centre, colour coded, so an overrun announces itself and needs no interpretation.
One view of every order state. Planned through completed on a single command panel, so the shape of the order book is readable without opening a report.
Make downtime attackable. Ranked by cause rather than buried in a log, so the biggest loss gets addressed first.
Track execution shift by shift. Output, work in progress and remaining quantity, per shift and per unit, attributable to the shift that produced it.
Surface delays while they matter. Scheduled against actual end time with a delay duration, as a worklist rather than an audit.
Fast enough for the floor. Answers in seconds, filtered by shift, date, part and work centre, or supervisors go back to walking.
05 · What we delivered
Six blocks that turn a routing into a decision
Each block answers one named failure from section 02, and each was checked against the floor before sign off.
Planning stats, eight states at once
Planned, unplanned, pending, scheduled, running, hold, rejected and completed, each as a live count. The shape of the order book without opening a single report.
no more status callsPlan versus actual per work centre
The centrepiece. Planned hours beside actual hours for every work centre, colour coded so an overrun announces itself. GC04 was planned at 1.63 hours and took 7.08.
no analysis requiredDowntime distribution by cause
Missing parts, power failure, servicing and breakdown, ranked. A downtime log becomes a shortlist of things to fix.
the biggest loss, firstWork centre mix and machine count
274 machines across ten types, CNC dominant, the context that makes any utilisation figure mean something.
utilisation, in contextQC outcome panel
Good, scrap and defect counts alongside production, so quality is read in the same glance as throughput rather than in a separate review.
quality beside outputShift and operation traceability
Every work order broken to the operation: quantity to produce, produced, work in progress and remaining, by shift and by unit.
pinned to the OP that caused itPlanned hours against actual
one bar tells you nothing, two tell you where the week went
Ten work centres, planned hours first. Wait a moment or press Actual and the same axis redraws with what the machines really took. GC04 was given 1.63 hours and used 7.08. Click any bar to read that work centre.
Routing times as planned. Every one of these looks reasonable on its own.
Catching the variance at the work centre is the cheapest place to catch it06 · Functional deep dive
How the variance actually gets computed
Four modelling decisions that decide whether the number on the screen survives contact with the shop floor.
Two grains, one roll up
Data arrives at operation grain and decisions are made at order grain. Aggregating without losing the failing operation is the whole problem.
- Operations carried as their own fact, with the order as a dimension
- Variance computed per operation, then summarised per work centre
- The worst operation preserved in the roll up rather than averaged away
Plan versus actual as a verdict, not a column
A table with two columns tells nobody anything. The visual has to say at a glance which work centre is bleeding hours.
- Variance expressed as a ratio and as an absolute, both available
- Conditional formatting thresholds agreed with production, not guessed
- Colour carries the verdict; the number carries the detail
Eight order states with rules that hold
Planned, unplanned, pending, scheduled, running, hold, rejected and completed overlap in practice, so each needed a rule that resolves an order to exactly one state.
- Precedence order agreed with planning and documented
- Each state carried as its own measure for the command panel
- States reconciled so the eight counts sum to the order book
Shift structure that is not tidy
First shift, rotations and multiple units mean output has to be attributed to the shift that produced it rather than to the day the order closed.
- Shift dimension keyed on unit and rotation, not on date alone
- Working duration derived from shift start and end, not assumed
- Output, WIP and remaining quantity all attributable per shift
Downtime, ranked instead of logged
everything was recorded, nothing was ranked
The same downtime events, sorted three ways. Event count is what the log gives you. Sort by hours lost and the order changes, because a short frequent stoppage and a long rare one are different problems. Sort by orders affected to see which cause is costing deliveries.
Ranked by how often it happens, which is what a downtime log naturally gives you.
A log becomes a shortlist of things to fix07 · How we built it
Six stages from routing to command view
It started on the floor rather than in the data, and that order is why supervisors use it.
Shop floor walkthrough week one
Followed a real work order from routing to despatch before designing anything, so the model matched how work actually moves rather than how the schema describes it.
Data modelling week two
Work orders, routings, shift logs, downtime and QC unified on shared work centre, part, shift and order dimensions.
DAX development about ten days
Variance, order state and delay measures built to hold at both operation and order grain without double counting the order across its operations.
Command view design one week
One page carrying the eight numbers a production manager checks first, laid out for a thirty second read rather than a study.
Drill through build four days
Shift wise and delayed order pages wired to the main view with navigation buttons, so a manager moves from symptom to detail without hunting.
Validation, training and tuning final week
Planned and actual hours reconciled back to routings and shift records, then formatting thresholds and filters tuned against real floor usage.
08 · Engineering notes
What keeps it fast enough to use
A shop floor dashboard competes with walking to the machine. These are the decisions that let it win.
Measures that hold at two grains
Every variance measure was unit checked at operation level and again at order level, because a measure that is right at one grain and wrong at the other is worse than no measure.
- Order counts use distinct counts over the order dimension
- Hours summed at operation grain and rolled up explicitly
- Divide guards so a work centre with no actuals reads blank
Conditional formatting instead of charts
A supervisor has thirty seconds. A red row is read instantly; a variance chart is studied later, which on a shop floor means never.
- Thresholds set with production and stored as parameters
- Colour used for the verdict only, never for decoration
- Row density tuned so a full work centre list fits one screen
Filter first design
The floor asks narrow questions: this shift, this part, this work centre. The layout assumes that rather than treating filters as an afterthought.
- Every page filtered by shift, date, purchase order, part and work centre
- Filter state carried across the three pages
- Default view scoped to the current shift
Validation against the routings
Planned and actual hours were reconciled back to routings and shift records before sign off, each within tolerance or explained.
- Reconciliation view kept in the report rather than in a spreadsheet
- Checked on every refresh, so drift surfaces as a variance
- QC counts tied back to the quality records
The delay worklist
a delay is not a number, it is a job you can still chase
Every open order plotted by how far it has overrun against how large it is. The worst is picked out when you arrive. Filter by priority to see whether the slippage is concentrated in the work that matters, and click any point to read the order.
Ten open orders. Height is how late, width is how much is riding on it.
Scheduled end against actual, ranked by how late09 · The impact
What changed on the floor
All of it from records the shop already kept, at the grain it already kept them.
- Overruns surface while they can still be fixed, not on the delivery date
- Downtime became a shortlist, so the biggest loss is attacked first
- Shortfalls trace to the operation that caused them rather than to the order
- Delays became a worklist a planner opens first every morning
the variance was always there, now it is caught in time
10 · The stack
What this platform runs on
Six layers, each handed over at the end of the engagement.
A machine running four times its planned cycle will blow the schedule, consume the capacity booked for the next job, and surface as a customer complaint two weeks later. Catching the variance at the work centre is the cheapest place to catch it.
11 · FAQ
Questions manufacturers ask before commissioning a build like this
No, and it is the usual case. The two are joined on shared work centre, part and shift dimensions rather than on a single system key, so they can arrive from an ERP and a shop floor system independently. What has to agree is the dimension mapping, which we settle at the start and hand over documented.
Operations are carried as their own fact with the order as a dimension, so the variance is computed per operation and then summarised. The roll up preserves the worst operation rather than averaging it away, which is what lets a shortfall be pinned to the OP that caused it.
Because of who reads it. A supervisor has thirty seconds between jobs. A red row is acted on immediately; a chart gets studied later, which on a shop floor means never. The thresholds are agreed with production and stored as parameters so they can be tuned without a rebuild.
Usually yes, through a read only connection or a scheduled extract, and nothing is written back. We have built the same reporting layer over Odoo, SAP and custom shop floor systems. Where a machine data source exists, downtime and utilisation can come from it rather than from manual logs.
Typically refreshed per shift, which matches how the floor works. Where a client wants nearer to live, an incremental refresh on the execution tables can run several times a shift. A live connection is possible but rarely worth the load it puts on a production system.
That surfaces immediately, and it is worth surfacing. The first draft shows the reason list as it actually is, including duplicates and blanks. Cleaning that list is usually a short exercise with the supervisors, and the ranking gets sharper as the source improves.
Yes. Unplanned is one of the eight states, with a precedence rule so an order resolves to exactly one state, and rework is carried so it can be read against QC scrap and defect counts rather than inflating good output.
Only if you will act on it. OEE is a useful summary but it hides which of availability, performance or quality moved. We build the three components first and add the composite once the underlying measures are trusted, because a disputed OEE discredits everything beside it.
Six weeks was the shape of this one, including a floor walkthrough before any design. A single unit with clean routings can be faster. Multiple plants, machine data integration or a long history to migrate will extend it, and we scope that against your data.
Production managers open the command view, supervisors and planners open shift execution, and planners chasing deliveries open the delayed orders page first every morning. Three pages rather than one dashboard because the audiences ask different questions.
The reporting layer reads standard tables and holds its logic in versioned views, so a version change is usually a view level fix rather than a rebuild. Nothing is customised inside the ERP, which is the point.
Because we model the shop floor as well as the visuals, and we start by following a work order rather than by reading a schema. We work across ERP, finance and operational data for clients in manufacturing, retail, healthcare and financial services. See our data analytics services or talk to a consultant.
Recording every hour. Do you know which ones you lost?
Tell us what your routings, shift logs and downtime records already hold and what the floor keeps asking for. We will map the model, the measures and the views around those questions.
Read next: where an insurer's book was actually losing money
