How to Measure Decision Latency Across Digitized Manufacturing Workflows

TL;DR

• This guide measures time from a factory event to a verified operational result. For the underlying concept, read the article on the manufacturing signal to action gap.

• Record seven timestamps for each case. Capture the event, evidence availability, evidence review, decision request, approval, action, and result verification.

• Separate total elapsed time from queue time and active work time so you can locate delays rather than merely report them.

• Build a baseline by workflow, site, shift, and decision owner. Review typical and unusually long cases with the owner on a recurring schedule.

• Use a shared semantic model when ERP, MES, or different plants label the same equipment, process step, or event differently.

What does decision latency measure beyond time to alert?

Decision latency runs from a confirmed factory event to a verified operational result. An alert marks detection, and an approval authorizes a response. Neither tells you when the response happened or whether it produced the intended outcome. Count the full interval when verification shows that the action did not produce the intended result. Otherwise, the measure excludes cases that warrant review.

The article on the manufacturing signal to action gap discusses the path to an authorized response. This guide measures that path through action and verification. For a quality hold, approval might authorize an inspection, but the case remains open until someone records the inspection result and confirms what happened to the affected material.

Dashboards can show an equipment alarm immediately while leaving later steps in separate records. A supervisor may review evidence in one system, approve a decision in another, and confirm the result in the MES. To answer how long resolution took, you need to connect those records to the same case and retain a timestamp for each step.

Which seven timestamps define decision latency?

Seven timestamps define six intervals between a factory event and a verified result. Give each case a stable ID across ERP, MES, and other source records. Record the event, evidence availability, completed evidence review, decision request, approval, completed action, and result verification. Record the responsible owner and source record for each event so you can trace handoffs and check the clock.

Consider an oven temperature deviation recorded at 09:00. MES makes the affected lot and temperature history available at 09:05. A quality lead finishes reviewing that evidence at 09:17 and requests approval to divert the lot at 09:20. The authorized owner approves at 09:42, the operator completes the diversion at 10:00, and quality verifies at 10:40 that MES records and a physical check both show the intended lot in quarantine.

The case took 100 minutes from event to verification. The six intervals were 5 minutes for evidence to become available, 12 minutes from availability to completed review, 3 minutes from review to request, 22 minutes from request to approval, 18 minutes from approval to completed action, and 40 minutes from completed action to verification. An alert timestamp alone would not show that approval and verification accounted for most of this case’s elapsed time.

The seven boundaries measure elapsed intervals, not the work performed within them. If one system logs review start and completion while another logs only completion, their active review times cannot be compared on the same basis. In this example, evidence availability starts the review interval, while review completion ends it. Neither boundary reveals how long the quality lead actively worked. If you need that split, also log when review began. Apply the same rule to action execution and verification rather than treating the time between approval and verified result as one undifferentiated stage.

How do you separate elapsed time, queue time, and active work time?

Total elapsed time runs from the factory event to the verified operational result. Queue time covers intervals when a case waits for an owner, evidence, approval, or a handoff. Active work time covers documented periods when someone reviews evidence, makes the decision, carries out the action, or checks the result. An alert timestamp alone cannot tell you how much of the full interval anyone spent working.

Two cases can each take eight hours but call for different fixes. If one spends seven hours waiting for approval and one hour in active work, you should examine the approval queue and decision rights. If another spends one hour waiting and seven hours in investigation and execution, faster routing will have limited effect. Record work start and stop times where the source systems support them. Otherwise, label the interval unclassified rather than assigning all time between status changes to the queue or to active work.

Keep unfinished cases visible without giving them a made-up verification time. Exclude them from completed-case duration calculations, and report their count and age separately as of the data pull. If open cases cluster in a particular queue, a completed-case average may understate the delay you need to investigate.

How should you handle missing or inconsistent timestamps?

If either boundary timestamp is missing, do not calculate that interval. Keep the case in a separate incomplete record count, and calculate a full case duration only when both the event and verification timestamps are valid. If the result has not yet been verified, mark the case as open rather than assigning it a close time. An invented timestamp creates false precision, so never interpolate one silently.

Check event order within each case before calculating durations. An approval recorded before its decision request needs investigation, not a negative duration. Compare both records with the originating ERP, MES, or approval log. Correct a confirmed extraction error using the source record, and retain an audit trail of the change. If you cannot resolve the sequence, flag the case and exclude the affected duration.

Standardize time zones before comparing records across systems or sites. Preserve each original timestamp and its offset, then convert a copy to one documented reference zone. Flag records whose zone or daylight saving offset cannot be established. Also record timestamp precision. If one system logs only to the hour, do not report minute-level waiting times for intervals involving that system.

Check repeated events against source records before deleting them. A second review may be genuine rework rather than a duplicate created during extraction. Remove a duplicate only when the case, activity, timestamp, and source record confirm the same event was extracted twice. Keep a second review or approval cycle when the audit trail shows it occurred. Track exclusions and corrections by source system so you can see whether apparent latency changes came from operations or cleaner data.

How do you map queues and handoffs in a decision workflow?

Map each decision case as a route through named owners, queues, and actions. For a quality hold, trace when MES records the hold, when quality receives the evidence, when an authorized owner receives the decision request, and when the approved action reaches the floor. Record who owns each handoff, when the case enters a queue, and when someone takes it up. A long interval between receipt and review points to waiting, while repeated returns to evidence review point to a different problem.

ERP and MES often use different IDs for the same production order. Joining those IDs directly can split one decision into separate traces. Map the order, work order, and quality record to a stable case key, then check a sample against the original audit trails. Flag uncertain matches. A bad join can invent a bottleneck or hide a handoff.

Keep rework and escalation in the route. A second evidence review may reflect a revised measurement or a request for more information, while an escalation may add another approval queue. Count those loops and inspect their causes. Remove a repeated event only when source-system evidence confirms it came from duplicate extraction.

A four hour average can reflect consistently slow reviews or mostly quick decisions with a few long escalations. Compare handoff durations alongside the full case duration, and count how often cases return or escalate. Those measures tell you whether to investigate a standing queue, a recurring evidence problem, or an exception path.

Which workflow, site, shift, and owner segments should you compare?

A plantwide average can hide delays concentrated in one workflow, site, shift, or decision owner. Compare cases within each of those groups before drawing conclusions. A quality hold that needs laboratory evidence and a schedule exception that needs a supervisor’s approval follow different paths, so their elapsed times should not share a single baseline.

Use the same case log and event through verification timestamps for every view. Add workflow, site, shift, and decision owner as case attributes rather than building separate clocks. Define whether shift means the shift when the event occurred or the shift responsible for the decision, and keep both fields if cases cross a shift boundary. Record owner changes as handoffs. Attribute each waiting interval to the queue or role responsible during that interval rather than assigning an entire case delay to its final owner.

Within each segment, report the case count, median, 90th percentile, and time spent in each measured interval. If most cases close promptly but a few wait through a weekend escalation, the upper end of the distribution will reveal a different problem than a consistently slow review step. Keep cases with unknown owners or shifts in a visible “unknown” group rather than assigning them by guesswork.

How do you establish a decision latency baseline?

Build each baseline from completed cases within a documented time window, starting with a defined workflow. Calculate event to verification time for each case, then report the count, median, and 90th percentile by site and shift. Compare owner level stage durations using the role responsible for each stage, and report open case counts and ages separately.

A median of 40 minutes and a 90th percentile of six hours point to a small group of slow cases, not a uniformly slow workflow. Inspect those cases by stage to see whether approval, action, or verification created the long tail. The plantwide average cannot show which stage caused it.

Your plant should document how it calculates percentiles and combines volumes across sites. A high volume workflow can dominate a pooled figure, while giving every site equal weight answers a different question. Neither choice supplies a universal baseline. Record the case inclusion rules, reporting window, and weighting method so the next period uses the same calculation.

How should a decision owner review latency and outcomes?

Assign each workflow a decision owner to review cases on a fixed cadence, such as every two weeks. Compare the current period with a baseline for the same workflow, site, and shift. Review the median and 90th-percentile time from event to verification, along with case counts and the age of open cases. Keep open cases separate from completed cases so unresolved work does not disappear from the numbers.

The owner should inspect stage durations and case traces before changing a workflow. If approval time falls but verification still takes two shifts, check whether the action waits for a maintenance window or whether the post-action check goes unrecorded. Compare waiting time with active work time, and look for rework or escalation in the cases with the longest delays.

Each review should compare the verified operational result with the baseline alongside the latency measures. For a quality hold, record whether the affected lots were correctly released or contained, then compare that result with the baseline under the same definition. The corrective-action validation guide explains how to check whether a completed fix worked using MES data and operator context. Log any workflow change, its owner, and its implementation date. At the next review, compare new cases with the baseline and note other changes that could explain the difference. A standing review gives the owner a basis for adjusting the workflow without treating one timed decision as representative.

When does a semantic model make decision latency comparable?

A shared semantic model becomes useful when two systems attach different meanings to the same order, asset, or event. Without a mapping, you may measure an ERP transaction against an MES operation and treat the difference as decision latency. The ISA-95 standard provides models for relating manufacturing operations information to enterprise information. Your data team still needs to map local equipment, process step, and event identifiers to consistent meanings. It does not define this guide’s decision-latency clock.

Consider a production order for 1,000 components. ERP records the order, while MES assigns work to a line and records when that work starts. MES may later record 972 good units and 28 defects before sending results back to ERP for settlement. An ERP order update and an MES operation completion both concern the same order, but they mark different steps. Treating either timestamp as the factory event without checking its meaning would distort the interval you report.

Equipment names need the same scrutiny. In one system, “Line 1” may identify a cost location. In MES, it may sit within a plant and area hierarchy that identifies specific workstations. A controller may record a stop for one machine on that line. Your model must connect those identifiers without treating a machine stop, a line stop, and an accounting record as equivalent events. A shared name does not make those records equivalent. The mapping must identify the asset and the kind of event each timestamp represents.

Your plant’s data or architecture team owns the mappings, event definitions, and changes to them across sites. The ISA-95 and shop-floor decisions guide shows how mapped equipment and order data can support a decision. Humble consumes contextualized data downstream. Neither Humble nor this measurement guide supplies or governs the semantic infrastructure underneath it.

How does Humble fit into a measured decision workflow?

Humble sits downstream of your ERP, MES, and other factory systems. In a scheduling exception, those systems can supply the order status, execution events, and constraints. Humble can use that contextualized information to present a proposed scheduling change with its supporting evidence and reasoning. Your plant sets approval rights and the limits on any action that can proceed.

To test Humble’s role, time the decision request, authorized approval, completed action, and verified result. A recommendation may arrive quickly yet sit in an approval queue. ERP and MES still hold the authoritative plan and execution records, while your data team owns equipment and event definitions. The ERP scheduling and AI decision-layer comparison helps determine when the existing scheduling workflow is enough.

Review a Decision Trace with Humble

Bring a production exception and its ERP or MES trace to a call with Humble. You can discuss how to measure the time from the factory event through approval, action, and a verified result, including delays at each handoff.

Check Whether Humble Fits Your Decision Workflow

If you are evaluating a governed decision layer for your ERP and MES workflows, take Humble’s 60 second fit test. Use a recurring decision with a measurable delay as your point of reference.

Subscribe to the Humble Manufacturing Newsletter

For more on measuring and improving manufacturing decisions, subscribe to the Humble newsletter.

FAQ

1. How does decision latency differ from time to alert? Time to alert ends when a system sends a notification. Decision latency runs from the factory event through evidence review, approval, action, and verification of the operational result.

2. What counts as verification? Verification requires a recorded check that the action produced the intended operational result within a defined observation window. An action marked complete does not verify that a defect rate fell or a production constraint cleared.

3. How should you start if timestamps are inconsistent? Start with one workflow and compare a sample of events with the ERP, MES, and approval audit trails. Normalize time zones and map related case IDs, then flag missing timestamps or events recorded in the wrong order rather than estimating them.

4. How often should you rebaseline? Set a review cadence that gives each workflow enough completed cases for a useful comparison, and create a new baseline when approval rules or workflow steps change. Keep the earlier baseline so the decision owner can distinguish a measured improvement from a change in what the clock includes.

How do you use decision latency to evaluate a workflow change?

Use the event to verification baseline to choose which stage to change. If alerts arrive in minutes but approvals wait until the next shift, examine the approval queue rather than alert speed. If approval is quick but the intended result is not verified, inspect action execution and the verification record.

To evaluate automation or a decision layer, compare similar cases before and after the change. Report stage durations, the count and age of unresolved cases, and verified operational outcomes under consistent definitions. A shorter approval interval establishes that approval became faster; it does not, by itself, establish that the workflow outcome improved.