Computer Simulation Tip: Sometimes the Goal Isn’t to Change Minds

 

🧠 Sometimes the Goal Isn’t to Change Minds

During a project in an emergency department, a nursing supervisor made an offhand comment to me: 

“The quickest way to screw something up is to bring in an engineer.” 

This is definitely something I have heard before. No tension and no confrontation; it was just a comment, shaped by past experiences and said as a joke.

At the time, I was working on a computer simulation intended to support operational decision-making. 

The model was technically sound, but as anyone who works in simulation knows, correctness alone does not guarantee impact.

---

🧩 Champions, Neutrals, and Blockers

I’m no expert in change management, but over the years I’ve had formal training and have completed organization-specific certifications. One idea that shows up again and again is that people involved in change tend to fall into three groups: champions, neutrals, and blockers.

Champions support the work.
Neutrals sit on the fence.
Blockers don’t need authority to slow things down; they just need influence.

In this situation, my goal was never to turn that supervisor into a champion of simulation. My only objective was to make sure he stayed firmly in the neutral group and didn’t become a blocker for others. 

---

🤝 The Lowest-Effort Intervention

I didn’t manage change, explain modeling assumptions, or try to persuade him of anything. I was simply very pleasant and consistently positive.

I made sure every interaction we had, no matter how brief, ended on a good note. It was easy to do, took very little time, and didn’t distract from the actual technical work.

For simulation practitioners, this is an important point: technical correctness doesn’t guarantee adoption.

---

📉 When a “Correct” Simulation Still Loses

The main takeaway for me is this: not every comment deserves engagement, and not every person needs to be converted. In complex environments like healthcare, sometimes the smartest move is not to spend extra time and energy trying to drive adoption of a model or its results.

A technically correct simulation that people choose not to trust or act on can still feel like a loss. 

If stakeholders decide not to take your recommendations, the system doesn’t change, regardless of how strong the analysis is.

---

✅ Final Word

Simulation doesn’t change systems. People do.

Keeping someone comfortably on the fence can be just as valuable as winning a champion. Sometimes success looks like this: when your name or your simulation comes up, someone says, “Yeah, I like them. They are cool, they’re easy to be around, and they really care about what happens here.”

For engineers and simulation professionals, leadership and soft skills aren’t separate from technical work. They’re what allow good models to actually make a difference.

This article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.

Computer Simulation Tip: Stop Modeling the ED Like a Clinic, It Doesn’t End at Bed Placement

🛑Stop Modeling the ED Like a Clinic: It Doesn’t End at Bed Placement

When modeling an emergency department (ED) using discrete event simulation, it’s tempting to treat “bed placement” as the final step for admitted patients. After all, once a bed is assigned, isn’t the job done? Not quite. Bed placement is just a decision point — not the end of the patient’s ED journey.

What comes next — boarding delays, inpatient bed unavailability, transport lags — has a massive impact on ED crowding, length of stay, and even patient outcomes. Ignoring that final stretch means your model is skipping over the part where the system often breaks down.

---

💡 The Biggest Opportunities Are Often After “Admit”

Across many hospitals and real-world models, the most valuable improvement opportunities emerge after the admit decision. Why? Because that’s when the ED starts feeling the weight of the inpatient system’s inefficiencies.

Patients board for hours while inpatient beds are cleaned, staffed, or simply opened up. Observation units run near full, and delays in inpatient discharges cause ripple effects that choke ED flow. The result? Bottlenecks that can't be fixed no matter how efficient the front-end ED processes become.

---

📈 Planning for Growth? You Need to Model What’s Next

Even if boarding times are low, that doesn’t mean your system is in the clear. If you're using simulation to test future volumes, expansions, or surge scenarios, you’re going to stress the system and inpatient and observation capacity will likely become the new limiting factors.

It might be tempting to model the ED alone, just as you might model a clinic because a clinic is a closed system. In a clinic, patients are seen, treated, and discharged all within the same setting. But the ED isn't like that. It’s tightly coupled to the rest of the hospital. Simulating it like a clinic is a category error that can lead to dangerously incomplete results.

Without modeling what happens after admission, you risk generating false positives: results that look promising in simulation, but fall apart in the real world. That could lead to misplaced investments, ineffective policies, and frustrated teams wondering why nothing improved.

---

🤔 But What If You’re Just Improving Fast-Track or Discharge-Eligible Patients?

A common question is: “If our focus is on patients who are likely to be discharged, like fast-track, low-acuity, or rapid assessment areas, do we really need to model the inpatient side?”

It’s tempting to think you can skip it, but here’s why that can backfire.

Your ED is a shared system. Even patients who are quick to discharge still rely on the same beds, staff, and physical space as patients who are boarding. When admitted patients get stuck waiting for inpatient beds, they tie up resources and create downstream congestion that impacts everyone — including the fast-track population.

So you can build the best triage or rapid treatment process in the world, but if hallway beds are full of boarders or your nurses are tied up managing admitted patients waiting hours for an inpatient bed, those low-acuity patients will still get stuck.

Boarding delays hurt everyone. They slow down throughput, create backups in triage, and extend wait times. If your simulation doesn’t account for that reality, your projected gains from front-end improvements will likely be overly optimistic.

✅ When might it be okay to skip it? If you’re modeling a truly separate, dedicated unit with its own space and staff — with guaranteed capacity not shared with boarded patients — you might get away with it. But for most real-world EDs, the flow is interconnected. If you’re testing future volume or surge scenarios, ignoring the inpatient side is almost always a mistake.

🤦‍♂️ The Common Pitfall: Modeling Only the ED

I can’t tell you how many times I’ve gone to simulation conferences and seen detailed, impressive ED models — that stop cold at the admit decision. It’s common, especially for newer modelers or academic projects. The ED feels bounded. The data is accessible. And yes, the inpatient side can feel messy and hard to model.

But here’s the deal:

You can’t fix the ED without fixing how patients get out of it.

A model that ends at bed placement may look clean, but it won’t reflect reality. It risks misleading leadership and producing recommendations that don’t solve the actual constraint.

---

🧠 Yes, It Takes More Time — But It’s Worth It

Sure, including inpatient and observation logic takes more effort. It adds complexity. And stakeholders unfamiliar with simulation might not immediately understand why it's necessary. But that’s where your role as a modeler becomes strategic, not just technical.

If your goal is real-world impact, the extra time is worth it. A more complete model, even a simplified inpatient abstraction helps ensure your insights are valid, your scenarios realistic, and your decisions aligned with how hospitals actually operate.

---

✅ Final Word

Simulation isn’t just about visualizing the present. It’s about pressure-testing the future. And that only works if you model the full story — not just the clean parts. So, if you're serious about change, whether it’s fixing today's ED bottlenecks or preparing for tomorrow’s demand, don’t stop at bed placement. Model what happens next. That’s where the system really starts to speak.

This article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.

Optimizing Hospital Size: Discrete Event Simulation vs. Traditional Architectural Approaches in Healthcare Planning

 

Discrete Event Simulation (DES) plays a crucial role in healthcare planning, focusing on the optimization of hospital size. Contrasting traditional static architectural blueprints with the dynamic, data-driven lens of simulation. 

Strategic Decision-Making: 

Traditional architectural plans provide static blueprints, analogous to snapshots frozen in time. In contrast, discrete event simulation serves as a dynamic, data-driven lens that anticipates and navigates the complexities of operational challenges. The integration of simulation isn't just a strategic addition; it represents a departure from the rigidity of conventional approaches, enabling the creation of operational ecosystems that dynamically evolve and adapt to achieve excellence.

Financial Responsibility: 

Architects bring an artistic touch to hospital design, but discrete event simulation introduces a financial savvy that goes beyond the aesthetic. This presents health systems with a solution that goes beyond space design—creating hospitals that are not just visually appealing but also financially sound and operationally efficient. Simulation provides the means to precisely match the hospital's size with the community's needs, achieving budgetary efficiency, and responsible resource allocation.

Interested in learning more, you can reach me at Astrozuggs@gmail.com

Challenges of Oversizing and Undersizing: 

In the realm of healthcare planning, the unintended consequences of architectural designs often manifest in hospitals that are either too large or too small. Here, discrete event simulation becomes the guiding force. Those well-versed in its dynamic intricacies aren't just advisors; they serve as navigators, steering away from the risks tied to ill-fitted hospitals. The goal isn't merely to provide solutions but to transcend the limitations of conventional architectural finesse, dynamically adapting to the ever-changing operational landscape. By doing so, it aims to alleviate the need for endless, costly process improvement initiatives that may become necessary when the hospital is not initially built to meet the community's precise needs.

Long-Term Impact and Feedback: 

In the ongoing process of healthcare planning, being well-versed in discrete event simulation means more than a fleeting role in the early planning stages. It positions you as a vital player in establishing lasting success. By introducing the concept of continual evaluation and improvement, you guarantee that your insights have a lasting impact well beyond the hospital's beginning. Simulation transcends building design; it is about shaping a legacy of operational excellence, rooted in an enduring dedication to learning and adaptability.

Conclusion:

Simulation transcends conventional building design, becoming a driving force behind a perpetual commitment to learning and adaptability, ultimately reshaping the landscape of healthcare infrastructure.

This article was collaboratively written with the help of artificial intelligence, with human oversight and editing to ensure accuracy and coherence.

 

Computer Simulation can be affordable: You can get enormous benefits with Small Computer Simulations using only a few pieces of information and not break the bank with gigantic consulting fees!!!

Often when performing Discrete Event Computer Simulations for clients, it is because they need to make "What if" decisions on their complex operations that could be costly to get wrong. 

Frequently, you will need a large complex Computer Simulation, which can be a pricey endeavor (most organizations will hire Simulation Engineers/Consultants), which is still worth it because of a 10:1 ROI very common with Computer Simulation. 

BUT

Sometimes all you need is a quick tiny model (in a well-scoped project) to give you answers using some limited data and with some underlying assumptions using simulation, which can be somewhat affordable (even affordable for a small business). 

What is a Tiny Model?

I am defining a "Tiny Model" as any Custom Discrete Event Computer Simulation where the entire project timeline can fit under 1 week. 

Typically, these models have 5 or less processes associated with them and use Subject Matter Expert assumptions rather than historical data to provide the variability for these models.  

However, if historical data is already available, found to be reliable, and analysis of this data can be performed in a few hours, you can use a mix of Subject Matter Expert assumptions AND data.

For my models I use ExtendSim software.

It's also typical to have someone experienced in Industrial Engineering or Operations Research build these models for you. 

If interested in learning more about how I can help, you can reach me at Astrozuggs@gmail.com

Why you need Computer Simulation 

Making decisions by "gut" or "feel" is very risky because of the complexity and variability in most operations (it's virtually impossible to get it exactly right) and even if the "gut" decision panned out somewhat…. how do you know it was an optimal decision? How do you know that you didn't leave money on the table? 

Example Simulation Video below

Need Tiny Computer Simulation? Contact me at Astrozuggs@gmail.com 

A great example of how you can create a small Discrete Event Computer Simulation can be found in the book "Healthcare Management Engineering: What Does This Fancy Term Really Mean? The Use of Operations Management Methodology for Quantitative Decision-Making in Healthcare Settings". 

It discusses how traditional management approaches to problem-solving and decision-making might not be the best way to go….and often point you to do the wrong thing, which can be costly or can impact revenue. 

Instead…why not use Computer Simulation! In the book, there is example 2.3.1 "Flu Clinic: Centralized or Separate Locations Example", which uses a walk-in clinic that provides Flu Vaccinations during flu season, which was receiving complaints from patients about the wait time. 

Traditional management approach

A traditional management approach is to have a brainstorming session, at which point, it was decided to split the clinic into 2 smaller clinics and place them in more convenient locations. 

Discrete Event Computer Simulation Setup 

Well…let's make a quick Computer Simulation to test out this change with some basic information that we already know. 

Simulate Patients arriving randomly 

It is explained that for the current large clinic there would be the following:

• 28 patients arrive per hour (i.e., On average, a patient every 2 minutes and 8 seconds) 

• It takes on average 8 minutes to register and give the flu vaccine to the patient 

• There are 4 exam rooms that can be used 

• Clinic is open for 12 hours (7a – 7p) 

And for the future 2 smaller clinics, it was decided to split everything evenly, specifically,

• 14 patients arrive at each clinic per hour 

• It takes on average 8 minutes to register and give the flu vaccine to the patient 

• There are now only 2 exam rooms for each clinic 

• Clinic is open for 12 hours (7a – 7p) 

To simulate 28 patients arriving randomly each hour, the authors use an exponential inter-arrival time of 2.143 minutes between arrivals for the Large Clinic scenario and 14 patients arriving randomly each hour at each small clinic with an inter-arrival time of 4.2857 minutes between arrivals, which I will use as well. 

Simulate how long it takes to get a patient vaccinated

To simulate the registration and administration of the flu vaccine, the authors use an exponential distribution with a mean of 8 minutes, which I will use as well. 

Results 

The results are as follows: 

As expected, (because of the patient complaints), with 1 large clinic the average time in the waiting room was 15 minutes with the longest wait up to 61 minutes AND at the end of the day, there were 11 patients still waiting to be seen…. Ouch!!!! 

How much more efficient were the 2 smaller clinics?

With 2 smaller clinics, the average time in the waiting room increased to 26 minutes with the longest wait up to 98 minutes AND at the end of the day, there were 39 patients still waiting to be seen. 

Wait! Did you catch that? Their decision to make 2 smaller clinics made things worse for their patients!!! How can this be? This doesn't make sense! Why did things get worse? 

Here is why: 

Basically, if you split up resources in a process whose duration times are random, with no other changes, your performance will decrease. 

Because patients arrive randomly, there will be times, for example, at one of the small clinics where both exam rooms are being used and a 3rd patient arrives. This patient will be forced to wait. If this happened at the larger clinic (with 4 exam rooms), they could have been helped in one of the other 2 available rooms. 

So, you see, there was an unintended consequence by splitting up the rooms that made things worse. 

Could you imagine being the decision-maker for these 2 clinics and spending hundreds of thousands if not millions of dollars to build out these 2 clinics only to realize that you made things worse?

Wouldn't it have been better for you to hire someone to build a computer simulation at a fraction of the cost and get it right? 

Run your Simulation multiple times to account for real-world variability

It should be noted that each simulation run will be different than another and as such, you will want to run multiple simulation runs to see the effect of your scenarios over long periods of time. 

I happened to run the above-mentioned scenario 100 times to see how different each run was from the other. 

Some run's results were not as bad as the first one, and a few runs were somewhat close to each other, however, over time, having 2 smaller clinics made things almost 30% worse. 

So, you can see not every Computer Simulation Project needs to be a 3-5 month-long complex project with hundreds of observations and gigabytes worth of data. 

Sometimes you can get enormous benefits from building a Computer Simulation around a small, but well-scoped process with a few pieces of information and not "break the bank" with enormous consulting fees or long project run times.