Gather the data

A model needs fewer numbers than you might fear. Find out which ones you need, how to turn your client's data into model inputs, and what to do when the data doesn't exist.

Draw first, then collect

Build a rough model before you chase data. Use your best estimates so it runs. It will show you which numbers you need, and you may learn that a number you were about to spend a week collecting barely moves the result.

What you need

Input	Ask the client for	Where it goes	View
Arrival rates	Timestamps of arrivals, orders or tickets	Generator, Basic tab, Inter-arrival Duration	Basic
Arrivals that change by hour or season	Volumes by hour, day or week	Model editor, Arrivals tab	Advanced
Processing times	Time studies, system logs, the shortest, usual and longest time from the people doing the work	Activity, Actions tab. Set a random time in the Classic layout, under Processing Time Duration.	Basic
Capacity of a step	Desks, rooms, machines	Activity, Basic tab, Capacity	Basic
Routing	What share of work goes each way	Connector, Routing tab, Weight	Basic
Shared people or equipment	Headcount and which steps they cover	Model editor, Resources tab	Intermediate
Shifts	Rosters and breaks	Work schedules, under Resources	Advanced
Breakdowns	Downtime logs	Activity, Failure tab	Advanced
Costs	Fixed costs, cost per unit, hourly rates	Activity or Resource, Financial tab. Tick Enable financial tracking on an activity first.	Basic

You'll only need part of this list. Go back to the model needs you wrote when you framed the problem.

Turn data into model inputs

Arrivals

Quodsi wants the average time between arrivals, not a rate. Divide: 12 arrivals an hour is one every 5 minutes.

When arrivals are independent, as walk-ins and calls usually are, choose Exponential and enter that average as the Mean. If work arrives on a fixed cadence, such as a conveyor or booked slots, Exponential will overstate the randomness. Look at the gaps in your data before you decide.

Measure demand, not completions. A completions log only shows what the process managed to handle, and it hides any peak the process couldn't keep up with.

Processing times

The Actions tab opens in its Recipe layout, where a step reads "Wait for 4 minutes". For a random time, switch to Classic. Pick the form that fits what you have:

You have	Use	Enter
One number, and the step truly doesn't vary	Constant	The value
Shortest, usual and longest	Triangular	Minimum, Mode, Maximum
A shortest and longest, with nothing more likely in between	Uniform	The low and high values
A mean and standard deviation from a time study	Normal	The mean and standard deviation

Triangular is often the best friend of a consultant on a deadline. Asking "What's the shortest it ever takes? The usual? The longest?" gets you usable numbers in a five-minute hallway conversation.

A processing time is touch time only. If your cycle time data includes time spent waiting in a queue, you will count the wait twice: once in your number and again when the model creates its own queue. This is one of the most common mistakes, so check where each number came from.

Routing

Connector weights set the share of work taking each path. They don't have to add up to 100, because Quodsi converts them to probabilities. Using counts from your data works fine.

Label every number

Keep a simple input log. For each number, record the value, where it came from and one of these labels:

Label	Meaning
Measured	From your client's own data
Sourced	From a source you can cite
Derived	Calculated from other numbers. Note how.
Assumed	A judgement call. Note whose.
Missing	Needed and not yet known

This log takes minutes to keep, and it protects you. When someone asks, "Where did 12 minutes come from?", you have the answer. It also shows your client how much of the result rests on assumptions.

When the data doesn't exist

Ask the people who do the work. They know the shortest, usual and longest times, and they'll tell you about the exceptions.
Sample it. A stopwatch on the floor for a morning beats a guess.
Use a range. Run the model at both ends of what's plausible. If the decision is the same at both ends, the number doesn't matter much.
Say so. Mark it as assumed and carry that into your presentation.

To test an uncertain number, make it a what-if. See Test your changes.

Common data traps

Unusual periods. A week with a system outage or a holiday isn't typical. Decide on purpose whether to include it.
Standard times. The planned time in a system may not be what actually happens. Compare it with a sample.
One value for all work. If simple and complex cases take very different times, one average hides that. Consider treating them separately.
Rounded timestamps. Manual logs often cluster on the hour or the quarter hour, which can make arrivals look more bunched than they are.

What you should have now

A model that runs on real numbers wherever you could get them
An input log with a source and label for each number
A list of the assumptions most likely to matter