What is the real system we’re modeling?
Most simulation failures don’t come from bad logic — they come from modeling the wrong system.
Before building any simulation model, we need conceptual clarity.
- Not about software.
- Not about 3D.
- Not about data integration.
But about the system itself.
Too often, modeling starts with geometry, equipment, or dashboards. Yet simulation is not about animating infrastructure — it is about understanding how value flows, how decisions are made, and where constraints truly exist.
To define the real system we are modeling, we must address four foundational questions:
- Are we modeling the operations system or merely the technical system?
- Are we thinking in terms of process flow, or are we being driven by layout?
- Have we clearly defined boundaries, scope, and stakeholders?
- And most importantly — what problem are we actually trying to solve?
If these questions are unclear, the model will be unclear.
And if the model is unclear, the decisions it supports will be flawed.
Clarity precedes modeling. Everything else follows.
A Common Starting Mistake in Simulation Modeling & Analysis
Most simulation failures don’t come from bad logic. They come from modeling the wrong system.
Before opening any simulation software, before placing objects, before importing CAD or GIS data — we need clarity: Are we modeling the operations system or the technical system?
That distinction changes everything.
Operations System
An operations system transforms inputs into outputs to create value.
Examples:
- Aircraft arriving → processed → departing
- Orders arriving → picked → shipped
- Patients arriving → treated → discharged
It includes:
- People
- Processes
- Decision rules
- Queues
- Information flows
- Policies
An operations system is value-focused.
Technical System
A technical system consists of physical or digital infrastructure.
Examples:
- Conveyor network
- Airport layout
- AGV fleet
- Software system
- Machine configuration
It includes:
- Equipment
- Hardware
- Software
- Layout
- Physical constraints
A technical system is function-focused.
The Critical Difference
A layout is not the same as a system. Equipment is not the same as a process. Infrastructure is not the same as value flow. We need to analyze how these elements are used/operated.
Focusing solely on the technical system can lead to optimizing the wrong aspect. However, testing the technical system, such as determining the theoretical maximum unconstrained capacity or estimating facility and equipment requirements under hypothetical conditions, is certainly valid.
Process-Oriented vs Layout-Driven Modeling
This is where things can go wrong, given that all the necessary and most relevant information/data is usually not available in the early stages of a simulation project.
Layout-Driven Thinking
“Let’s build the 3D model first.”
You import CAD.
You place conveyors.
You model machines.
It looks impressive.
But you may not understand, at least not yet:
- Arrival patterns
- Routing logic
- Variability
- Constraints
- Control policies
You built the system's geometry — not its operations.
Process-Oriented Thinking
“Let’s map the flow first.”
You define, for example:
- Entities
- Resources
- Queues
- Decision rules
- Service times
- Variability
Then you build the process flow and 3D representation. Now the model answers operational questions
Define the System Boundaries
Every system must have boundaries. If you don’t define them, your scope will expand endlessly.
Ask questions such as:
- Where does the system start?
- Where does it end?
- What is inside our control?
- What is external variability?
- What assumptions are we making?
Example (Airport Turnaround):
Do we include:
- Gate assignment rules?
- Ground handling crews' shifts?
- ATC delay?
- Weather variability?
- Maintenance and equipment failure events?
If you include everything, you build chaos. If you include too little, you build irrelevance. Boundaries define meaning.
Scope and Stakeholders
Different stakeholders see different systems, for example:
Operations Manager typically cares about:
- Throughput
- Resource utilization
- Bottlenecks
- Re-work
Finance typically cares about:
- Cost
- Capital investment
- ROI
Engineering typically cares about:
- Equipment performance
- Reliability
- Product quality
Executives typically care about:
- Strategic decisions
- Risk
Customers typically care about
- Quality of the product
- On-time delivery
If you don’t identify stakeholders early, your model may answer the wrong questions.
Simulation is not neutral — it reflects the priorities of its sponsor.
What Problem Are We Actually Solving?
This is the most important question.
For example, we should not ask, at least not in the early stage of modeling:
- “Can we build this model?”
- “Can we animate this?”
- “Can we integrate this data?”
But:
- Are we capacity-constrained?
- Are we variability constrained?
- Are we policy constrained?
- Are we labor-constrained?
- Are we capital-constrained?
Sometimes the real issue is:
- Poor scheduling policy
- Unbalanced flow
- Overutilization at one step
- Underutilization elsewhere
You may not need a bigger conveyor or a robot. You may need a different rule/strategy for operating your existing resources.
Questions to Ask Before Modeling
Before you open your simulation tool, answer questions like:
- What is the operational objective?
- What transformation creates value?
- What are the known constraints?
- Who makes decisions in the system?
- What decision are we supporting?
If you cannot answer these clearly, you may not be ready to model.
Why This Matters
A simulation modeling and analysis isn’t about 3D animations — it’s about decisions and problem-solving.
If you start with structure rather than flow, you will likely optimize the architecture of the system rather than performance. And in operations, performance is what matters.
Forward View
In the next Simlog, I’ll go deeper into:
Mapping the Flow Before Modeling
- Value stream thinking
- Identifying entities and transformations (flow item/activities)
- Why Lean precedes simulation
Because simulating without understanding flow is just animated confusion.
Closing Principles
- Model the system that creates value — not the system that looks impressive.
- Define the real system first.
- Everything else follows.
