amer.catic@projectvisit.org dagb@projectvisit.org +46 31 322 7207
PV Project Visit

Modelling Workflow Bottlenecks Through Simulation at Celean

Workflow bottlenecks rarely sit where managers expect them. The slowest desk, the most overworked team, or the longest queue often turns out to be a symptom rather than the cause. Inside a software firm, hospital, mine, or accounting practice, the real constraint hides one or two steps upstream, and it only becomes visible when work is animated as a moving system rather than frozen on an org chart.

The Chalmers Electronic Lean Research Team, working under its shorter banner Celean, treats this hidden constraint as a modelling problem. Drawing on partnerships with manufacturers such as Volvo and a steady stream of operational data from Swedish and European partners, the group builds digital replicas of knowledge work and runs them under stress. The aim is not a prettier process diagram but a system that can be watched choking and recovering, so interventions rest on evidence rather than guesswork.

For readers in Australia, the relevance is sharper than it might first appear. The country runs on FIFO rosters across Western Australia and Queensland, on hospital networks stretched across vast catchments from Cairns to Launceston, and on small software houses in Surry Hills and Richmond shipping features to global markets. Bottlenecks in any of these settings are rarely solved by hiring another body; they are solved by reshaping flow, and reshaping flow begins with a model worth trusting.

Why Bottlenecks Resist Simple Fixes

Most teams know where the visible pile-ups are. The tricky question is why those pile-ups keep re-forming after each attempt to clear them. Celean's researchers describe this as a symptom-versus-cause gap: an overworked reviewer looks like the problem, but the root cause may be a handoff that loses context, or a batched release that lands every Friday afternoon and swamps the same small group.

Australian workplaces illustrate the pattern well. A Sydney hospital network might add another registrar, only to discover the bottleneck has shifted to medical records. A Pilbara iron ore operation might add a third haul truck, only to find the crusher is already at capacity during the late arvo shift change. Even a Melbourne SaaS team can hire a second product manager and still miss launches because the real choke point is discovery work, not delivery.

The persistence of these failures points to a structural truth. Workflows are not chains of independent steps but coupled systems, where one decision alters the load on every other role downstream. Simulation is the discipline that makes those couplings visible and lets researchers experiment safely, without disrupting a live operation or gambling a release schedule on intuition.

The Simulation Mindset at Celean

At its core, the Celean approach is empirical. Rather than argue from first principles about which constraint theory predicts, the team instruments a real workflow, builds a discrete-event simulation from the data, and runs thousands of hours of virtual time in a compressed window. Each run perturbs arrival patterns, staffing levels, or policy settings, and the model reports where queues build, where utilisation climbs past 90 percent, and where rework loops multiply.

This is not abstract academic work. The team sits inside Chalmers University of Technology in Gothenburg and operates as a bridge between research and industry. Readers landing on the project site can read about its history, members, and partnerships on the about page, which sets out how the group is funded and how partners engage with its prototypes. From there it is a short step to the open-source tools and published papers that explain the methodology.

What distinguishes Celean from a pure operations research outfit is the visual planning layer. Many bottlenecks form not because work is missing but because the work that exists is invisible to the people who could act on it. The team's simulation outputs feed directly into Kanban-style boards, so a queue the model predicts at minute 47 of every cycle becomes something a team can literally see and respond to during their daily stand-up.

Building Digital Twins of Knowledge Work

A model is only as good as its calibration. Celean's researchers spend a surprising share of their time on this unglamorous step: pulling ticket timestamps from issue trackers, interviewing reviewers about how long they actually spend on a pull request, and observing the rhythm of meetings in a tradie's project office in Brisbane or a policy team in Canberra. The aim is to capture the work as it is, including slack, informal handovers, and coffee-break drift, before any optimisation is attempted.

Once the raw inputs are gathered, the team constructs a digital twin. The twin mirrors the real workflow in code, complete with stochastic arrivals, varied task durations, and resource pools that map onto real roles. Researchers can then replay a week of work in seconds, tweak a single policy, and observe downstream consequences. If a change cuts average lead time by 18 percent but doubles variance, the trade-off is recorded honestly rather than buried in a summary slide.

This approach also catches patterns that humans systematically misread. A team in Adelaide might swear Tuesday is their worst day, but the simulation often shows the real cost is paid on Wednesday when Tuesday's backlog flows through review. Surfacing those second-order effects is one of the most concrete contributions the methodology offers to practitioners who would otherwise rely on anecdote.

Reading Queue Dynamics and Variability

The mathematics underlying the work draws heavily on queueing theory, but the team's communication with industry partners stays firmly in operational language. A few metrics recur across almost every engagement, and they tend to be the ones that distinguish a busy team from a healthy one.

Indicators the Celean team watches closely

Variability is the silent driver of nearly every queue. A team handling a steady trickle of work can absorb small shocks; a team receiving its work in clumps, even at identical average load, will see queues balloon and staff burn out. Think of a Gold Coast council planning department flooded with development applications in the two weeks after a state budget, or a Perth mining supplier whose orders cluster around maintenance shutdowns. The simulation work at Celean is, in part, an effort to put numbers on the cost of that clumping and to test which smoothing policies pay off.

Partnering with Industry for Real-World Calibration

Industry collaboration is not an afterthought at Celean; it is the engine that keeps the models honest. Volvo has been a longstanding partner, providing the large, multi-year datasets that allow researchers to validate long-term claims rather than short-term wins. Similar collaborations exist with software and service organisations across Europe, each bringing workflow idiosyncrasies into the lab.

When a new partner joins a project, the team typically works through a short list of model adjustments before any analysis runs. These adjustments are rarely dramatic, but most of the value is created there.

Adjustments the team works through with new partners

In Australia, partnerships of this kind are still emerging but the appetite is real. Universities in Melbourne and Sydney have begun conversations with healthcare networks and the resources sector about adapting the methodology to FIFO rotations and to the long, thin supply chains that stretch from a Pilbara mine to a port in Dampier. Early signs suggest the same queueing dynamics apply, though the policy levers, such as swing rotations and travel time, differ from those a Gothenburg engineer would recognise.

Translating Simulation Outputs into Practice

A simulation that no one uses is an expensive curiosity. Celean's researchers therefore spend as much energy on the delivery format as on the modelling itself. Outputs are packaged as short scenario briefings, with three or four named interventions, predicted effect sizes, and the conditions under which each intervention would fail. Partners can pick one or two and run a controlled experiment on a real team before committing to wider rollout.

The Australian context offers a useful cautionary tale. A Brisbane software team might run a model that recommends cutting WIP limits, only to discover their review culture cannot absorb the change without first investing in shared coding standards. The simulation said nothing wrong; it simply could not anticipate a constraint living in the team's social fabric rather than in its ticket data. Models inform judgement; they do not replace it.

What does work, in the team's experience, is starting narrow. Pick one queue, one team, one fortnight. Model it. Run the interventions in the simulation. Apply the smallest promising change in the real workflow. Measure again. Adjust the model. Repeat. Over a quarter or two the gains compound, and the team builds the muscle to ask better questions of the next bottleneck that surfaces.

A useful starting point for any team curious about this kind of work is to instrument the queue that already annoys them. Count arrivals over four weeks, time the service steps, and plot the inter-arrival gap. Even a rough spreadsheet will reveal whether the bottleneck is driven by demand spikes, by service variability, or by a constraint the team has not yet named. From there, a conversation with researchers, or a careful read of the Celean publications, can turn anecdote into a working model. The hard part is rarely the mathematics. It is the willingness to watch one's own workflow behave badly on screen long enough to learn from it.