Understand how the system works before deciding how to change it
Many organisational problems are difficult to understand because their causes sit across several functions, processes and relationships. We work with the people who understand these systems to build models of how they behave, so dependencies can be explored, assumptions tested and the consequences of a decision examined before anything changes.
Why we model the whole system
A useful model starts with a clear question rather than a complete dataset.
Read more in There Is No Such Thing as Good Data.
A new security lane, an extra crane or a faster approval step can each look like an improvement on its own. Whether it helps depends on what sits either side of it. If another stage is the constraint, money spent elsewhere improves a local measure and leaves the whole system where it was.
A model makes those relationships explicit. It sets out what flows through the system, where it waits, who controls each lever and what each one costs, so options can be compared on the same basis. It also shows where the evidence is thin, which is often as useful as the answer.
Choosing the level of detail
An organisation can be described at several levels, each of which answers different questions, and detail beyond what the question needs adds cost without adding insight.
Where should the next five years of capital go to meet the outcomes a regulator will measure?
- Holds
- Assets, funding, risks and outcomes, in yearly or quarterly steps
- Method
- Portfolio and system dynamics models; scenarios rather than forecasts
Which stage limits capacity, and what does relieving it gain the whole system?
- Holds
- A chain of stages converted to one common unit, so the constraint shows
- Method
- Constraint and flow models
Where does a design change wait between drafting, costing and approval?
- Holds
- Steps, hand-offs, queues and the rules that route work
- Method
- Process mapping; discrete-event simulation where queues matter
How much does one repeated task vary, and what drives the variation?
- Holds
- Durations, resources and their spread for a single task
- Method
- Statistical and Monte Carlo models fitted to observed cycles
Illustrative questions. Levels are linked only where a decision crosses them and the evidence supports the link; we do not assume one connected model of everything.
How we build a model
Subject specialists know how the system really behaves, including the parts that no dataset records, so they are partners in building and checking the model rather than simply sources of data.
- Frame the questionAgree the decision, the outcome that matters, the boundary of the system and who knows each part of it best.
- Describe the systemMap what flows, where it waits, which rules apply and who holds each lever. Every assumption is written down and owned.
- Build and testBuild the model at the right resolution, then check it against what specialists expect and what records show.
- Explore the optionsRun scenarios, search for better combinations and show where the result is sensitive to an uncertain input.
Two illustrative models
Both are illustrative models, built to show the method, the structure and the kind of question a model can answer.
Airports, optimised as a system
Airspace to Kerb follows one peak hour at an illustrative two-runway hub through six stages: demand, airspace, runway, stands, terminal and surface access. Each stage is converted to passengers per hour, and the smallest is the constraint. It holds 17 stakeholders and nine preset scenarios.
In its "airport silo" scenario the airport invests in security lanes, stands and e-gates, but the runway still binds, so most of that spend adds no peak throughput. That is the point a whole-system model makes and a single-stage business case misses.
Ports, configured by demand
The port configurator starts with the customer's demand: vessel calls a week, cargo per call, dwell time and the sharpness of the peak. It links four sets of requirements, from demand through marine and landside space to capital and operating cost, and recalculates every option as an input changes.
It shows how a model can sit inside a commercial conversation: options can be tested and compared while the discussion is happening.
Other sectors where this applies
Any system in which several parts compete for the same capacity can be modelled in the same way: find the constraint first, then test the options before committing any money.
What a model can and cannot do
A model is a structured argument about how a system behaves. It is only as good as its assumptions, so we make them visible and replaceable, and we say how far each model has been checked.
- Our models explore consequences; they do not produce certain predictions.
- They are built for a decision rather than maintained as a live copy of the operation, so we do not describe them as real-time digital twins.
- Where an input is uncertain, results are shown as ranges, and the inputs that matter most are named.
- A person makes the decision, and the model informs it.
Related
Questions
Do we need clean data before we start?
No. We start with the question and the people who know the system. Records are used where they help to calibrate or check the model, and gaps are shown as gaps.
How accurate are the models?
That depends on the question and the evidence available, so we say so for each model: what it has been checked against, where it is uncertain and which inputs matter most. A model that is honest about its limits is more useful than one that looks precise.
Is this a digital twin?
No. We build models for decisions, at the level of detail those decisions need. Some can be rerun as inputs change, but we do not present them as live replicas of an operation. We do, however, build digital twins as a separate service, where an organisation needs a connected model of an asset or operation that is kept up to date.
Do we have to use your software?
No. We choose the modelling approach and tools that suit the problem. Where our own products help, we will say why; where they do not, we will not use them.
Who keeps the model at the end?
We agree that at the start. The aim is a model your team understands and can question, with its assumptions written down.
Talk to us about a decision you need to test
Tell us what you need to decide and what makes it hard. We can help work out whether a model would help, and at what level of detail.
Discuss a challenge