When a major customer escalates a delivery failure, the first response in most plants is to isolate the incident. Logistics scrambles to find the specific shipment. Quality opens an 8D. The team identifies a proximate cause, implements a containment action, and closes the record. Six weeks later, the same customer escalates the same failure for a different reason. This is the cycle that burns organisational trust and erodes margins without triggering systemic change.
The problem is not a lack of effort. It is a lack of visibility. ISO 9001 and IATF 16949 systems document standard work, but they do not capture what actually happens on the floor when variables shift. The real process, complete with its workarounds and delays, lives in your transactional systems. Every timestamp in your ERP, MES, and QMS represents a decision, a handoff, or a bottleneck.
I have audited automotive plants that reported 98% on-time delivery to management while customers complained about chronic delays. The complaints looked isolated, but aggregating the ERP event logs proved otherwise. A single material shortage, an engineering query, or a missing document creates a cascade that standard reporting flattens into a pass-or-fail metric. It does not show you the divergence.
Anatomy of an Escalation: The Post-Mortem Method
Consider a real scenario from an automotive supplier. A tier-one customer issued a formal warning letter for repeated late deliveries of a stamped assembly. The supplier's internal metrics showed these orders clearing final inspection on schedule. Conventional root cause analysis would examine the specific late shipments. A process mining approach walks the failure backwards through the entire event chain.
The investigation stops looking at the late shipments and starts examining the normal ones. By extracting a year of order-to-cash events from the ERP, the mining software reconstructed every possible path. The documented flowchart showed a single linear progression from order entry to dispatch. The data revealed twenty-three distinct operational variants. The escalation was not caused by an anomaly. It was caused by the structural inability to handle normal variation.
Post-mortem analysis means you examine the deviations before the failure. If you only investigate what went wrong, you only find the tip of the iceberg. By tracing the customer escalation back to the order entry timestamp, you expose the hidden network of workarounds, informal approvals, and missing data points that dictate true process performance.
Documented Flow vs. ERP Reality
The ISO flowchart assumes
- Linear progression from order entry to dispatch
- All required documentation is present at packing
- Quality checks happen once, at a defined gate
- On-time delivery is measured from dispatch date
The event logs prove
- Dozens of variants with loops and informal detours
- Hidden rework cycles caused by missing certificates
- Process halts when undocumented staff are unavailable
- True performance is measured against customer request date
The Three Structural Breakdowns
Walking the complaint backwards exposed three specific structural failures driving the escalation. First, the software revealed a hidden rework loop. In twelve percent of cases, orders physically left the dispatch area and returned to quality control. The product itself was compliant, but the material certificate was missing.
This rework loop averaged 2.3 days per occurrence. It remained entirely invisible in management reports because the internal on-time delivery metric was measured from the final dispatch date, not the original customer request date. The system registered the shipment as on-time because the metric was designed to pass. The metric itself was a structural defect.
Second, the logs exposed an undocumented step. In thirty-one percent of cases, logistics initiated an informal consultation with engineering before packaging. This consultation averaged 47 minutes. When the designated engineer was unavailable on Friday afternoons, the process simply stopped until Monday. Nobody had codified this dependency. It existed entirely as a verbal workaround that became standard practice.
Variant Concentration and Customer Impact
The third structural breakdown involved variant concentration. The post-mortem proved that the aggregate delay was not distributed evenly. Two specific customer accounts experienced a thirty-four percent rework rate, three times the plant average. Their orders triggered the missing-certificate loop disproportionately because their specific documentation requirements were never built into the ERP routing.
Operators had learned these customer-specific rules verbally. During shift rotations, the knowledge evaporated. New operators packaged the parts to the general standard, triggering the quality hold. The event logs captured this failure pattern thousands of times. No human reviewing 8D reports could mentally aggregate 14,000 individual events to spot the correlation between specific customer profiles and the documentation defect.
This is the value of a data-driven post-mortem. Process mining does not replace the Gemba walk. It tells you exactly where to look when you get there. By filtering the event logs for the two affected customers, the software isolated the exact process step where the deviation originated, turning weeks of manual investigation into a focused, hours-long audit.
The Mechanics of a Data-Driven Post-Mortem
Executing this analysis requires understanding the data structure. An event log is not a summary report. It is a sequential record of system events. Every time a status changes in an ERP, MES, or QMS, the system generates a data point. To reconstruct the process, you need four minimum fields: a Case ID, an Activity description, a Timestamp, and a Resource identifier.
Without precise Timestamps, you cannot determine sequence or duration. Without accurate Resource data, you cannot perform variant analysis across shifts or operators. The success of a process mining investigation depends entirely on the integrity of these underlying fields. If users manually overwrite timestamps or log bulk updates at the end of a shift, the resulting map will be precise but factually wrong.
Different discovery algorithms serve different analytical needs. The Alpha Miner produces straightforward maps but requires complete, clean data. The Inductive Miner handles noise and incomplete logs effectively. The Heuristic Miner relies on frequency analysis to uncover hidden relationships. For a post-mortem, you need an algorithm robust enough to handle the messy reality of manual ERP entries without discarding the anomalies.
The Five-Stage Complaint Post-Mortem
- 0101. Data ExtractionPull a year of event logs for the affected product family and customer.
- 0202. Data CleansingRemove duplicate system entries and align cross-system timestamps.
- 0303. Process DiscoveryRun the algorithm to generate the actual operational map, including all variants.
- 0404. Conformance CheckingOverlay the discovered map against the ISO documented procedure to locate deviations.
- 0505. Root Cause ConfirmationTrace the specific variant paths that lead to the escalated customer complaint.
Conformance Checking and Systemic Risk
Conformance checking is where process mining transitions from operational analysis to quality assurance. ISO 9001 and AS9100 require documented procedures for nonconformity management. The audit confirms the procedure exists and is accessible. The audit cannot confirm whether the organisation actually follows it.
I have reviewed quality systems where 8D reports were formally closed in the ERP without any logged verification of the implemented corrective action. The documentation looked perfect for the external auditor. The event logs proved the corrective actions were never checked. Mining the logs exposes this systemic compliance risk immediately, shifting quality management from assuming compliance to proving it.
Process mining shows you exactly what is happening on the floor. It does not tell you why. You still need to walk to the Gemba for that.
Conformance checking forces the organisation to confront its actual execution. If the mining software shows that fifty percent of nonconformity dispositions bypass the documented material review board sequence, you have a systemic risk. You address it by fixing the process or fixing the documentation. You do not address it by generating another summary report.
Avoiding the Weaponisation Trap
The data generated by a post-mortem is powerful, and misusing it destroys the value of the tool. The most dangerous deployment failure is weaponisation. If management uses process mining data to track and punish individual operator performance, trust evaporates instantly. Operators will find ways to bypass the system, and the data quality will degrade to the point of uselessness.
Process mining must be positioned as a structural diagnostic tool, not a performance management weapon. When the software showed that the Friday engineering consultation stopped production, the solution was not to discipline the logistics team. The solution was to codify the packaging requirement into the ERP routing so the informal consultation was no longer necessary. You fix the system, not the person.
Start the investigation with a targeted pilot. Choose a single high-impact process, like complaint handling or supplier approval, and use a tool like Disco for rapid visualisation. Secure management buy-in by demonstrating the financial impact of the hidden rework loop. Once the pilot proves the structural value, invest in an enterprise platform to scale the post-mortem capability across the organisation.