For engineers and process experts

Depth, dependencies, and what actually happens on the floor.

Everything a summary hides. MBW is built so that when a number surprises you, you can go and find out why.

Most tools give you an average to trust. Here you can trace everything down to the worst week and the part that waited four hours.Most simulation tools give you an average and ask you to trust it. The interesting questions are about the worst week, the part that waited four hours, and the resource that was the real constraint rather than the obvious one. So everything here can be traced down to that level.

An illustration: behind the average, and where the slowest part lost its time

Follow one unit through everything that happened to it

Each unit's ledger shows where its time went and its share of cost and energy. Add what was spent while idle, and the shares equal the line's totals exactly.Every unit carries its own ledger: each stay split into waiting, waiting for a resource, being processed and blocked; whom it waited for; which full queue ahead held it up; and its share of the line's cost and energy, charged for the time it was worked on. Together with what was spent while nothing was worked on, the units' shares add up exactly to the line's totals. When an average looks wrong, this is where you find out why.

What one unit's passport says, on Analysis

One part's ledger: whom it waited for, what held it, and its share of cost and energy

Accounting that has to balance

Every resource's hours are split by what happened, and must add up exactly to its capacity. The engine is held to that rule, so a modelling error shows.Every resource's hours of capacity are split into working, broken down, in planned service, away, idle and off shift, and together they must add up to exactly the capacity over the horizon. Material, cost and energy hour by hour are held to the same discipline. It is not a report feature but a rule the engine is held to, which is how a modelling error becomes visible instead of merely plausible.

busy + down + maintenance + absent + idle + off shift = capacity × hours, exactly
Utilisation against rostered time, and overtime reported separately rather than folded into busy

Every rule a run is held to, on Analysis

Where every hour went: an illustration of the identity, without figures

Calendars, breakdowns and changeovers that behave properly

Shifts are weekly patterns. Breakdowns come from wear, repairs can wait for a mechanic, and changeovers depend on the product pair, so job order matters.Shifts are weekly patterns with their breaks inside them; holidays and shutdowns are written once, and work already started finishes as overtime. Breakdowns come from wear: the clock runs while a machine works, or counts the pieces it makes, so a line that stands over the weekend does not come back to a pile of breakdowns. A breakdown stops the job in hand, the repair can wait for a mechanic like any other work, and the job carries on where it stopped. Changeovers cost what they cost between a specific pair of products, so the order of the jobs changes the time lost.

Rosters, people and holidays, on Operations

Breakdowns from wear, not the calendar; repairs that queue; changeovers by product pair

Experiments, not repeated guessing

Declare the levers, goal and limits; the search does the rest. The best few are run again, as the best of many noisy readings is partly luck.Declare the levers, the goal and the limits, and let the search do the rest. It can be a surrogate that fits a smooth surface through the points that kept the limits and goes where it promises, random search, simulated annealing or the full grid. Screening ranks many points on a few runs each. The best few are then run again properly, because the best of many noisy first readings is partly luck, and each limit is judged at the unfavourable end of its interval. It reports the path it took, the winner, and which levers moved the result at all.

Goals and the search, on Planning

A search on two levers: the surface it fits, the finalists run again, the winner

It fits into what you already run

A model can read from your own SQL database, as of any moment you name. A snapshot makes the run repeat exactly, and results can be written back.A model can read its data from your own SQL database instead of its files: orders, products and bills of materials, rates, shifts, people, holidays, machines, breakdown history and stock, as of any moment you name. What was read is kept beside the run as a snapshot, so the run repeats exactly and a changed input is reported as such. Finished runs can be written back to the same database.

SQLite or PostgreSQL; the database wins where it holds a value, the files keep everything else
Migrations that only move forward and never drop or rename anything, their SQL shown to your database team first

A real morning read from a database, as a use case

Your database, both ways: what a run reads, kept as a snapshot, and what it writes back

For decision makers

“What does this mean for us, and where should we put our money?”

Explore the decision view

Come and try to break it.

Build models for a living? Bring your questions and your scepticism. Our engineers are at every first call.If you build simulation models for a living, you will have questions this page does not answer, and probably some scepticism. Bring both. Our engineers are at every first call. It is the fastest way to find out whether the engine does what you need.

Book a discovery call