What Problem Are We Simulating? Using Four Types of Problems to Frame Simulation Studies

One of the hardest parts of a simulation project often occurs before any model is built.

It is defining the problem.

A client may say that throughput is too low, utilization is too high, queues are too long, or that more capacity will be needed. Sometimes there is no obvious problem at all. The organization simply wants to know what would happen if demand increased, a process changed, or an entirely new facility were built.

All of these situations can benefit from simulation, but they are not the same kind of problem.

That distinction matters because the type of problem affects what we model, what data we need, what experiments we conduct, and ultimately what conclusions we can reasonably draw from the simulation.

For this reason, I adopted a framework based on Art Smalley's Four Types of Problems and adapted it to how I approach simulation modeling and analysis.

Smalley's framework distinguishes four situations:

1. Troubleshooting
2. Gap from Standard
3. Target Condition
4. Open-Ended

Smalley's underlying point is straightforward: don't start with the problem-solving tool. Instead, ask what problem you are actually trying to solve. His framework was developed in part to help organizations avoid the "hammer and nail" problem of applying the same method to every situation.

For simulation, I would phrase the question slightly differently:

What are we trying to learn from the model?

That question should come before deciding how detailed the model needs to be, which software to use, or how many scenarios to run.

Type 1: Troubleshooting

A Type 1 problem begins with an abnormal condition that requires an immediate response.

Something happened.

A machine failed. An automated baggage-handling system stopped. A conveyor went down. A critical resource became unavailable. Operations now need a temporary process to keep the system functioning until normal service can be restored.

Smalley describes Type 1 as rapid, situation-driven problem solving. It emphasizes responding to the abnormality, protecting the customer, taking action, and checking whether the response worked.

In my simulation framework, an example is an automated system failure that requires operations to revert to a manual process. The objective is not necessarily to determine why the automated system failed. The immediate question is whether the alternative process can handle the workload and what operating conditions will result during recovery.

A simulation study might ask:

• How much throughput can the manual process sustain?
• Where will queues develop?
• How many additional workers are needed?
• How quickly will the system recover?
• How long can the temporary process operate before unacceptable conditions occur?

This is an important distinction.

The simulation is not necessarily performing root-cause analysis of the equipment failure. Instead, simulation helps the organization understand the operational consequences of the abnormal condition and possible responses.

Simulation is not always practical for the immediate firefighting portion of Type 1. If a problem must be resolved in the next five minutes, building a new model will not help.

However, an existing simulation, digital twin, or previously developed model can be extremely valuable for evaluating contingency strategies before the next disruption occurs.

Type 2: Gap From Standard

Type 2 is probably what most people mean when they say they have a "problem."

An expected level of performance exists, and the actual system does not consistently meet it.

Smalley describes this as a gap from the standard that requires deeper investigation. Instead of simply restoring operation, we want to understand what is actually happening, break the problem down, investigate the causes, and develop countermeasures.

For simulation, however, I think it is useful to divide that gap into three patterns:

• Above
• Below
• Inconsistent

My Type 2 chart deliberately starts with the question:

What is the performance metric actually measuring or quantifying?

That question matters because "higher" and "lower" do not automatically mean "better" and "worse."

For example, a value above the expected range could indicate:

• excessive finished-goods inventory,
• excessive work in process,
• or overproduction.

A value below the expected range could indicate:

• insufficient material inventory,
• underutilized capacity,
• or insufficient throughput.

An inconsistent metric may indicate problems with:

• resource utilization,
• customer demand or requests,
• rework,
• synchronization,
• or variability over time.

This is where simulation becomes particularly useful.

A real system contains interactions that can make cause and effect difficult to discern. A low throughput value, for example, might be associated with equipment reliability, staffing, process times, scheduling rules, blocking, starvation, batch sizes, arrival variability, or some combination of these factors.

A simulation allows us to change those conditions systematically and observe their effects.

But there is an important limitation:

A simulation model does not automatically discover the root cause. It evaluates the behavior represented in the model.

The analyst still needs to understand the real system, formulate hypotheses, verify assumptions, analyze data, and design meaningful experiments. This aligns with Smalley's description of Type 2 as a more disciplined, analytical, and quantitative form of problem solving focused on cause-and-effect relationships and standard attainment.

Simulation becomes one of the analytical tools used during that investigation.

Type 3: Target Condition

Type 3 changes the nature of the question. The current system may be working perfectly well. There is no failure to explain. Instead, we deliberately create a new gap by defining a future condition.

Smalley describes this as moving from an acceptable current state toward a future ideal or target state. Unlike Type 2, which asks why performance is below the existing standard, Type 3 asks how the system could perform at a higher standard.

This is one of the most common applications of simulation.

Consider a system that currently handles demand successfully. Management expects demand to increase substantially over the next several years.

There is no current performance problem.

The question is:

Can the existing system handle the future condition?

My Type 3 example represents exactly this situation: a new standard created by future increased demand.

The simulation can now explore questions such as:

• When will the current system reach capacity?
• Which resource becomes the first constraint?
• What happens to waiting time as demand increases?
• Can scheduling changes delay a capital investment?
• Would an additional resource provide enough capacity?
• Which proposed improvement gives the best operational result?
• What combination of changes produces the desired future performance?

There may be no single root cause because nothing is necessarily "broken." Instead, we are trying to design a better operating system.

That makes Type 3 especially compatible with what-if analysis, experimentation, optimization, Lean improvement, and discrete-event simulation.

It also explains why simulation projects frequently feel awkward when forced into a traditional root-cause problem statement. Sometimes there isn't a root cause to find.

The problem is the gap between where we are today and where we need to be tomorrow.

Type 4: Open-Ended

Type 4 moves even further away from traditional problem solving. Now the future state itself may not be known.

Smalley describes Type 4 as open-ended and innovation-oriented, involving divergent or lateral thinking, analysis and synthesis, creativity, and potentially breakthrough concepts.

For simulation, I associate this strongly with master planning and conceptual design. My Type 4 example therefore uses master planning as the representative situation.

Suppose an airport, factory, warehouse, hospital, or transportation system is being planned.

The question may not be:

Why isn't the current system meeting its standard?

It may not even be:

How do we make the current system better?

Instead, the question might be:

What should the future system look like?

Perhaps several radically different concepts are under consideration.

Simulation can help explore:

• alternative layouts,
• different operating concepts,
• capacity strategies,
• automation levels,
• staffing concepts,
• resource configurations,
• process designs,
• scheduling strategies,
• expansion phases,
• and demand scenarios.

At this stage, the model becomes less of a diagnostic tool and more of a decision laboratory.

We can create a representation of a system that does not yet exist, subject it to different assumptions, and observe its likely behavior before committing significant resources to a particular design.

This is one of simulation's greatest strengths.

Reactive Problems and Created Problems

One of the most useful distinctions in Smalley's framework is the separation between the first two and the last two types.

Types 1 and 2 are primarily reactive.

Something has happened, or an established performance level is not being achieved.

Types 3 and 4 are proactive.

We deliberately create a gap by imagining a better or substantially different future. Smalley's presentation explicitly describes Types 1 and 2 as "caused/reactive" and Types 3 and 4 as "created/proactive."

That distinction is especially valuable in simulation because simulation is inherently capable of working with systems that do not yet exist.

We can therefore summarize the four types from a simulation perspective this way:

These categories are not rigid. A project can move between them.

A Type 1 disruption may reveal a recurring Type 2 problem. Solving the Type 2 problem may expose opportunities for Type 3 improvement. A sufficiently ambitious Type 3 project may eventually become a Type 4 redesign.

Smalley's broader recommendation is therefore not to become attached to one approach, but to recognize the situation and select the appropriate way of thinking.

The Problem Statement Comes Before the Model

Simulation software makes it tempting to start building immediately. Create the entities. Add the resources. Define process times. Connect the logic. Import the data.

But a technically impressive model can still be a poor study if nobody is clear about the question it is supposed to answer.

Before modeling, I therefore want to establish several things:

What type of problem are we dealing with?

What performance metric represents the problem or target?

What is the relevant time scale?

What is the current condition?

What constitutes acceptable performance?

What decisions will be made using the results?

These questions begin defining the model boundary and experimental requirements.

A model intended to understand a throughput gap may be completely different from one intended to evaluate a 20-year master plan—even when both represent the same facility.

The model should follow the problem. Not the other way around.

Simulation as a Tool for Thinking

Simulation is often described as a tool for predicting system performance. That is true, but I think it undersells its value. A well-designed simulation study forces us to make our assumptions explicit. It requires us to define processes, resources, constraints, variability, operating rules, and performance measures. Then it allows us to experiment.

That makes simulation not simply a visualization tool or a prediction engine, but a structured way of thinking about operational systems.

Art Smalley's Four Types of Problems provides a useful framework for determining what kind of thinking is required before the simulation study begins.

Sometimes we need to recover from an abnormal condition.

Sometimes we need to understand a performance gap.

Sometimes we need to reach a new target.

And sometimes we need to explore a future that has not yet been designed.

The simulation model may look similar in each case.

The question behind the model is fundamentally different.

And getting that question right is often the most important step in the entire simulation project.

Relevant References

Link to: Webinar with Art Smalley- Four Types of Problems

Four Types of Problems by Art Smalley (link to Amazon)