Studies
A scenario tests one proposal. A study answers "how much is enough?" It runs a set of scenarios against one Baseline so you can compare them.
When a study is the right tool
- Sizing: How many nurses does this clinic need on a Monday?
- Limits: How much can demand grow before the call center falls behind?
- Comparing options: Is it better to add a station or to speed up the one we have?
If you already know the one change you want to test, a scenario is enough.
Create a study
There's no separate study form. Start with New what-if, as for a scenario. As soon as your what-if has two or more scenarios, the footer changes to Saves as a study of N scenarios, and the button changes to Create study.
Sweep a range of values
On a change, switch from One value to A range. Then fill in anywhere from, to and in steps of. Each value becomes a scenario. People call this a sweep: you try one setting across a range and see where the result stops improving.
Combine two or more changes
When two changes each have values, Quodsi asks How should these changes combine? The numbers below come from an example with 3 values on one change and 4 on the other.
| Option | What runs | Scenarios in this example | Use it when |
|---|---|---|---|
| See changes combined | Every combination of the values | 3 × 4 = 12 | You think the changes interact. Extra staff may only help once the queue has room. |
| See changes one at a time | Each change on its own, with the others left at Baseline | 3 + 4 = 7 | You want to know which change matters most. |
The Baseline runs as well, on top of that count. The THIS WHAT-IF WILL RUN panel shows the arithmetic and lists the scenarios.
Edit the table directly
Switch from Sentence to Table to see the study as a grid. It reads like a spreadsheet:
- Each row is a scenario. Each column is a change.
- A blank cell means that scenario doesn't make that change.
- The Baseline row at the top shows each setting's current value.
- Type in the last row to add a scenario. Use + Add a change to add a column.
The table is the right place for hand-picked proposals that a range can't express, such as "Option A: add a nurse. Option B: add a room and shorten triage." Each row has a pencil that opens Scenario details, where you can add a note on why the scenario exists.
A row must change something. A blank row blocks Save until you fill it in or delete it.
Start a study from a bottleneck
You don't have to build one by hand. In Flow Analytics, each row of the constraint table has a Study button. The Overview tab offers the same thing under What to try next. Either one opens a new what-if that's already filled in with the capacity behind that constraint.
Turn a scenario into a study
Open a saved scenario, switch to Table and add a second row. On Save, the scenario joins a new study as its first row and keeps its runs. The model's own Baseline scenario can't join a study.
Run a study
Choose Run study. The first run takes your model as it stands. The window tells you how many simulations you're about to start.
The table's Status column shows each scenario's latest run. If some scenarios didn't finish, Run study runs what's left. Re-run study runs every scenario again, and Use latest model definition decides which model it uses.
What stays fixed
A study keeps its own Baseline, frozen from the model, so all its scenarios are compared on the same footing. Keep these rules in mind:
- Rerunning one row uses the study's Baseline, like every other scenario in the study.
- Editing the model's Baseline scenario affects new studies, not ones already created.
- A row that has runs is locked. Duplicate it to try something different. You can also delete it, which deletes its runs and results when you save.
Read the results
Choose View tradeoff to plot every scenario on one chart. That's usually the quickest way to see where more capacity stops paying off. See Tradeoff View.
To look inside one scenario, open it in Results. Use the Comparing bar on the Dashboard tab to put up to five scenarios side by side. See Results dashboards.
Common mistakes
- Sweeping too much at once. A large grid is slow to read and hard to explain to a client.
- Sweeping a step that isn't the constraint. The result won't move, and you've learned little.
- Ignoring identical rows. If two rows make the same changes, each still runs as its own scenario. The footer warns you.