How to Run Your First Simulation Project
Run your first simulation project around one expensive decision, two to four variants and a small team, with the measures of success agreed before anyone builds a model. The steps are: pick the question, set the scope and measures, collect the data, build and check the base model, run the variants, then decide and record why. A focused first project takes days to weeks. In DBR77's published case studies, comparable analyses took from a few days to about a week.
Step 1: Pick one question worth answering
A first project fails most often because its question is too big. "Model the whole plant" is not a question. "Which of three layouts for the new assembly area gives more output per shift with the same people?" is.
A good first question has three features:
- It is expensive or hard to reverse, like a layout change, a robot cell, a new buffer or an extra shift.
- There are at least two real options, and people disagree about which is better.
- The answer depends on time and interaction: shared forklifts, buffers, changeovers or a varying order mix.
If the decision is small and easy to undo, try it on the floor instead. If it is due next week, the model will be late. Pick a decision that is still open and will be made within the next few months.
Step 2: Set the scope and the measures before modeling
Write a one-page charter before any data is collected. It should say:
- The decision, in one sentence.
- The variants to compare, usually two to four, including the current state.
- The boundary: which stations, warehouse areas and transport routes are in, and what is left out on purpose.
- The measures: for example output per shift, minutes of waiting, utilization of stations and vehicles, operator working time.
- The decision rule: what result would make you choose variant A over variant B.
The decision rule is the step most teams skip. Without it, every result can be argued away. With it, the team knows before the first run what it is looking for.
Step 3: Collect the data and name the roles
Most of the data exists already: CAD layout, routings and standard times from ERP, shift calendars, order history. The rest is measured by hand. We list the minimum data set and how to collect it in What Data Do You Need to Start a Factory Simulation?.
A first project needs a few people for a few hours a week. Nobody has to join full time.
| Role | Typical person | What they deliver |
|---|---|---|
| Sponsor | Plant director or COO | The decision, the deadline, the final choice |
| Project owner | Process or industrial engineer | The charter, the data, the timeline |
| Floor expert | Shift leader or foreman | Real cycle times, stops, the rules people actually follow |
| Data contact | Planner or IT | ERP exports, order history, routings |
| Finance contact | Controller | Costs of each variant, the format the board expects |
| Modeler | Internal engineer or DBR77 | The model, the runs, the comparison |
The floor expert matters more than people expect. A model built only from ERP standard times often misses the waiting, walking and workarounds that shape real output.
Step 4: Build and check the base model
Model the current state first, even if the decision is about a future layout. It is the only version you can compare with reality.
Then run three quick checks:
- Rebuild a known week. Use a recent order mix. Output and the main queues should match what the shift leaders remember.
- Check the bottleneck. The constraint in the model should be where the floor sees problems.
- Change one input. A longer cycle at one station should move the result in a direction the team can explain.
If the base model and the floor disagree, find out why before running variants. The gap between standard times and real output usually points to the real bottleneck, so measure there and correct the inputs. A wrong base makes every comparison wrong in the same way, and nobody notices.
Planning a first simulation project?
Describe the decision in a few lines and we can help turn it into a one-page charter, with the variants, the boundary and a short list of the data to collect.
Step 5: Run the variants under the same conditions
Every variant must face the same order mix, the same stops and the same cycle-time ranges. If those differ, the comparison measures the assumptions instead of the layouts. The stochastic simulation in DBR77 Digital Twin varies these inputs from run to run, so each variant is also judged on its bad days.
How long this takes depends on the scope. In DBR77's published case studies, a multi-variant analysis of a production line layout was delivered in about a week. A comparison of automation variants took a few days. A warehouse picking simulation was prepared in a few days from current production orders.
An illustrative timeline for a first project of this size could be one week for the charter and data, one week for the base model and checks, a few days for the variants, and one review meeting. Your numbers will differ, but if the plan stretches to several months, the scope is probably too wide.
Review the variants with the people who will run them. Process animation and 3D views help shift leaders spot a rule that does not match the floor, such as a forklift route that is blocked at shift change.
Step 6: Decide and record why
The project is finished when someone has made the decision and written it down. Close it with a short record:
- the chosen variant and the measures that made it win
- the rejected variants and why they lost, so they do not come back under a new name
- the main assumptions, each with an owner and a source
- what would trigger a rerun, such as a new product, a change in mix or a new machine
- who owns the model from now on
The decision record makes the second project faster. Once the chosen variant is built on the floor, the model owner updates the base model to match the plant. The next question then starts from that model, with the same data and checks. For the meeting where the result is presented, see How to Present Simulation Results to the Board.
Common traps in a first project
- Starting with integration. Connecting machines before the first decision delays the result. Start with the data you have; live machine data is a later stage, once the model is used regularly.
- Adding scope halfway. A new question mid-project resets the timeline, so park it for the next project.
- Leaving the model without an owner. Nobody updates the base model when the plant changes, so a year later it no longer matches the floor and nobody trusts it.
- Presenting the model when executives asked for a decision. They need a choice and a reason, and an animation gives them neither.
These and other causes are covered in Why Most Digital Twin Projects Fail, and How to Avoid It.
FAQ
How big should a first simulation project be?
Small enough to finish in weeks. One area, one decision, two to four variants. A narrow first project that ends in a decision builds more trust than a broad one that is still running.
Do we need a dedicated simulation engineer?
Not for the first project. A process engineer as project owner, a shift leader and a modeler, internal or external, are usually enough.
What if the result says the current state is best?
That is a valid answer. You avoid spending money on a change that would not help, and the model is ready for the next question.
Should we start with the simplest or the most important decision?
Start with an important decision that has a narrow scope. A trivial question proves little. A huge one takes too long.
Conclusion
This week, write the one-sentence decision and the decision rule on a single page and take it to the sponsor. If the two of you cannot agree on which result would change the choice, settle that before anyone collects data.
See a first project from question to decision
The demo walks through the steps above on a sample case, from the charter question to layout and process variants compared on output, waiting and utilization.
Sources
Want to test a decision from your plant?
Book a demo and we will show how DBR77 Digital Twin compares the options on output, waiting time and transport load.