It is always interesting to describe what you do as a consultant because your job changes from project to project. I would say that it parallels the job of a general carpenter since each job is just a little different. And like a carpenter, a consultant collects more tools in their toolbox as projects come and go and their experience grows. On each new job, they choose the tools that will provide the best solution.
A carpenter doesn’t sell a kitchen remodel as a hammer and saw; they will sell it as a kitchen remodel. Then, based on what is needed to remodel the kitchen, they will select the correct toolset.
So how does this relate to being a consultant?
Sometimes we fall into the trap of selling a specific tool over a solution to a problem. Maybe we don’t want to become irrelevant, so we try to sell our expertise instead of a solution. Then, after starting the project, we may realize that a different tool is more appropriate but find ourselves locked into the tool we promised.
Over the years, I have built many simulations for a variety of industries, including military defense, retail stores, parking garages and healthcare. As my toolbox expanded to include different types of models and analytics, I realized that I had, at times, fallen into the trap of selling a simulation when other tools I could have used.
Simulation affords many benefits, but it also comes with drawbacks:
- It is time-consuming to build and run.
- It is expensive because of the time commitment needed.
- Results are only as good as the data.
- Some systems can be difficult to model because of complexities.
So, when should we utilize simulation? The following checklist will help determine whether it is the right tool for the job.
The Logic Test
One of my first, fast rules is to address the question, ‘Can the issue be logically explained and written down on a piece of paper?’ In this manner, we can begin to determine how much we understand about the system. If there is any vagueness, then we need to step back and spend more time modeling the system. On several occasions, it has been during this step that we have uncovered the issue and made simulation unnecessary. I think back to Simulation 101 in school: The first and most important step is the conceptual model of the system. This is your blueprint!
The Data Dive
Another item to consider is the availability of data. If the data is available and reliable, then it is easier to trust the results. If reliable data is not available, we must go through the process of collecting data and/or interviewing subject matter experts intimate to the process. The results will be only as good as the quality of the data collected.
The Starting Point
Finally, let’s consider how we are going to evaluate the results against a baseline. Where does our system stand today? Can we accurately calculate our key performance indicators (KPIs)? We must understand where we are starting to accurately evaluate improvements. To a simulation developer, this elicits the validation and verification of the simulation and is crucial to ensuring that the model is producing accurate results compared to the real-world system. Many times, we can use analytics with the available data to determine our baseline. I can also say that this step has identified issues and areas to investigate. Occasionally, analytics alone can help solve the problem.
Here's my cheat sheet on situations in which simulation is often warranted:
- Industries with little to no human interaction, such as factory lines, supply chains, etc.
- Variables that can be regularly predicted or modeled
- Queuing theory (i.e., hospital check-in process, bank and grocery store checkouts)
Simulation is a fantastic tool when used correctly, but other tools in the toolbox sometimes can get us to the solution more efficiently. Make sure to sell a solution and use the right tool for the job.
About the author: Nick Brown, Haskell Healthcare Senior Consultant and Operational Analyst, has extensive experience in data collection and converting it to meaningful analysis through dashboard development, modeling and simulation and process mapping. He has developed models to address patient flow and operations of many hospital departments including perioperative suites, supply chain, emergency departments and inpatient units. He has a bachelor’s in Business Administration from Ohio State University and a master’s in Engineering from Wright State.
