The process constraint

Functional — runs in your browser

Illustrative values entered in your browser. No real records.

What it shows

Shows, on an editable claims process, that the output of a workflow is set by the stage with the lowest capacity. The default calculation is deterministic: it finds the constraint, the system throughput and the queue that builds up in front of it, then compares automating an arbitrary stage with automating the constraint. An optional mode adds variability in arrivals and processing times and shows the average queue that forms in front of nearly full stages too.

The demonstration

Process map and constraint Calculation updated
Process stages illustrative values

Capacity (cases/day) = staff × minutes available per person per day ÷ minutes per case.

    Flow and horizon illustrative values
    Productive time, breaks excluded.
    10
    Calculation mode
    Scenario: automating one stage
    Automation multiplies the capacity of the chosen stage by the chosen factor.

    Result computed in the page

    System throughput, before and after

    Process map

        The model's formulas, the current parameters and the results, generated in your browser.

        How it works

        Each stage has a computed capacity: capacity = staff × minutes available per person per day ÷ minutes per case. Cases enter the first stage at the chosen rate. Each stage passes on at most its capacity: outflow = min(inflow, capacity).

        System throughput is the outflow of the last stage, that is min(arrival, minimum capacity). The stage with the minimum capacity is the process constraint when arrival exceeds it; otherwise output is limited by demand and no queues form. In front of any stage that receives more than it can process, the queue grows every day by inflow − capacity. After N days, the queue is N × (inflow − capacity). The model assumes a constant daily flow and empty queues on day 0.

        Automating a stage that is not the constraint raises its capacity but does not change throughput: the flow is still limited by the same stage. Automating the constraint raises throughput only up to the capacity of the next-lowest stage or up to the arrival rate. From that point, the constraint moves. The default mode is deterministic: the same values give the same result, with no random component. The optional variability mode adds a coefficient of variation for arrivals and one for processing time and approximates the average queue in front of each stage with Kingman's formula (Sakasegawa's version for several staff), so a stage running close to capacity shows a queue even when it receives less than it can process.

        Virtual Soft applies the same reasoning in process analysis. It identifies the constraint first, then proposes interventions on it and measures the gain through system throughput before and after.

        What is real and what is simulated

        Real, computed in the page:

        • the capacity of each stage, from staff, available minutes and minutes per case;
        • the constraint, including the case where several stages share the same minimum capacity;
        • system throughput, the inflow and outflow of each stage, utilisation and the queues after the chosen number of days;
        • the before and after comparison for the automation scenario and the queue chart;
        • in the variability mode, the average queue and average wait per stage;
        • the downloadable technical sheet.

        Simulated:

        • the claims process and the default values (staff, minutes per case, new cases per day, available minutes) are illustrative, not taken from an insurer;
        • the default model assumes a constant daily flow; the variability mode uses a steady-state approximation with illustrative coefficients of variation; absences and rework between stages are not modelled;
        • automation is reduced to a capacity factor; the cost and duration of implementation are not modelled.

        Last verified: