A Simulationist's Framework
for Business Analysis

Part 02:

Framework Introduction

R.P. Churchill

Lean Six Sigma Black Belt

www.rpchurchill.com | Portfolio | Presentations
30 Years of Simulation

Continuous simulation of the heating of a square billet and Discrete-Event simulation of a multi-phase process.
30 Years of Simulation


  • Paper (Chemical/Process)
  • Nuclear (Power Generation)
  • Metals (Steel, Non-Ferrous)
  • HVAC (Building Control)
  • Insurance, Banking, Legal
  • Security, Inspections
  • Passenger Processing
  • Medical Facilities
  • Evacuations
  • Area Control
  • Threat Response
  • Logistics, Supply
  • Maintenance and Reliability
  • Staff Level Determination
  • Fleet Management



  • Design and Sizing
  • Operations Research
  • Real-Time Control
  • Operator Training
  • Risk Analysis
  • Economic Analysis
  • Impact Analysis
  • Process Improvement (BPR)

Architectural Considerations

  • Continuous vs. Discrete-Event
  • Interactive vs. Fire-and-Forget
  • Real-Time vs. Non-Real-Time
  • Single-Platform vs. Distributed
  • Deterministic vs. Stochastic
Where Do We Start?

Before my nervous system decided to depart for Pago Pago, I did swing dancing for over fifteen years. My favorite dance within that genre all grows out of a simple basic step I could tech you in five minutes. (Learn something about its history through parts one, two, three, four, and five.)

Back in the day, people could tell what high school you went to by the way you did your basic.

Individuals and groups solve problems in different ways, driven by their experience and preferences, and also by the nature of the problem and its potential solutions.

There are a zillion different ways of doing things, and you can spend a lifetime getting better, adding variations, and doing all the other things possible in a dance, but we have to start somewhere.

I'm going to show you one business analysis "basic," which is based on my many decades of building and employing computer simulations.

Here Is Our "Somewhere"

For this initial discussion, we're going to talk about the process of building a simulation of a system that already exists.

The simulation will be used to improve the operation of the existing system.

The system does not have to be real-time or interactive.

The existing system is a process consisting of multiple steps (think of a flowchart, possibly with branches), and not a single entity.

Who Is Going To Be Involved?

The process I describe can be done alone, but most work of any scale will involve groups.

Working with multiple people and groups involves communication — and empathy.

Define terms. Learn how to speak each other's language.

Understand that you won't get it right the first time. Listen, document, review, correct. Repeat this process until all parties reach agreement.

Analysis and solution happen within a managed environment of limited resources. Understand the context and how to generate the best results.

1. Figure Out What You Want the Simulation To Do

There are many reasons to write and run simulations. I listed some industries and applications on the third page.

Simulations have to provide some kind of value, or else there is no reason to build them.

The simulation has to be accurate enough to be meaningful. Remember that all simulations are wrong; some are useful.

The use(s) of the simulation may be expanded, limited, or otherwise modified as more is learned through the process.

2. Understand the Thing You're Going to Simulate

Discover what the existing system does, what components make it up, and the actions that take place within it. These are your nouns and verbs.

  • Most systems have components that do standard kinds of things.
  • Different industries and systems will employ standard kinds of components.
  • There are many ways to do discovery. Use all of them that work.

Collect the data that characterize the system. These are your adjectives and adverbs.

  • Data come in infinite varieties and quantities, but they have some characteristics in common.
  • Learn what the data all mean. Document everything.
  • There are many ways to do data collection. Use all of them that work.
  • The data may be messy. Figure out how to make it usable or handle the mess.
3. Identify What the Stakeholders, Users, and Solution Need

The organization has needs, customers have needs, users have needs, and designers and analysts have needs.

The solution may have needs of its own. We may learn about those needs at any point in the process, but the earlier we know, the easier it will likely be to make allowances.

We need to understand the difference between what the solution DOES and what the solution IS. The latter describe qualities the solution should have. For example, two solutions may generate the same answer, but the one that is simpler to use, runs faster, requires less maintenance, and is easier to modify will be preferred.

Define the criteria by which the requirements are agreed to be met.

4. Generate Possible Solutions and Pick the Best

The solution should simulate everything that the existing system does — unless all parties agree that things can be omitted or simplified.

There are many (very good) reasons to make assumptions and simplifications, but they should all be understood, agreed to, and documented. The risks and impacts should also be understood.

There are many ways to evaluate and rank solutions. They may differ based on the organization and application.

A classic way to compare solutions is by the net present value they provide after cost-benefit analyses are performed.

However, not all criteria can be reduced to monetary figures, and all organizations are not bound by the same incentives.

The full solution package should consider construction, operation, deployment, training, maintenance, and more.

5. Build and Deploy the Solution

Solutions should generally be as simple as possible — but no simpler. Remove complexity whenever possible, but retain all required functionality. Avoid adding features that aren't needed out of a sense of "completeness" or because they're "cool."

Solutions may need to be implemented in phases.

Training, documentation, and ongoing management and maintenance are part of the solution.

I generally strive to make solutions as standardized and modular as possible. That said, it takes time to learn how to do that.

Initial solutions in a problem space tend to be custom, expensive, and brittle. They become standardized, cheaper, and robust over time. Think cars!

6. Test and Accept(?) the Solution

EVERY aspect of a solution should be tested, alone and in combination.

Testing should be planned for from the beginning (as much as possible).

Solutions should be evaluated on how they work — and how they address the stated problem.

Tests should meet defined standards that give pass/fail answers (as much as possible). Different kinds of tests are more amenable to this than others (Think TQM. What are the exceptions?).

Consider the entire solution process from the point of view of the tests it will have to pass (think Test-Driven Development - TDD).

Remember, the market provides the most important — and stringent — test of all. The best solution doesn't always win.

Let's Summarize:
  1. Define the problem
  2. Figure out what's going on now
  3. Identify what everyone needs
  4. Propose, develop, and select a design
  5. Build the solution
  6. Test it
Do That Work in a Project Management Wrapper
  • Provision and launch project
  • Define the problem
  • Determine what to simplify or omit, and the effects of doing so
  • Figure out what's going on now
  • Data sources, conditioning, and collecting
  • Identify what everyone needs
  • Propose, develop, and select a design
  • Build the solution
  • Test it
  • Close project
The Framework:
  • Project Planning
  • Intended Use
  • Assumptions, Capabilities, Limitations, and Risks and Impacts
  • Conceptual Model (As-Is State)
  • Data Sources, Collection, and Conditioning
  • Requirements (To-Be State: Abstract)
    • Functional (What it Does)
    • Non-Functional (What it Is, plus Maintenance and Governance)
  • Design (To-Be State: Detailed)
  • Implementation
  • Test
    • Operation, Usability, and Outputs (Verification)
    • Outputs and Fitness for Purpose (Validation)
  • Acceptance (Accreditation)
  • Project Close
The Framework: Simplified
  •   Intended Use
  •   Conceptual Model (As-Is State)
  •   Data Sources, Collection, and Conditioning
  •   Requirements (To-Be State: Abstract)
    • Functional (What it Does)
    • Non-Functional (What it Is, plus Maintenance and Governance)
  •   Design (To-Be State: Detailed)
  •   Implementation
  •   Test
    • Operation, Usability, and Outputs (Verification)
    • Outputs and Fitness for Purpose (Validation)
Basic Engagement Structures

Link to detailed discussion.

Engagement Structure Variations

Link to detailed discussion.

Continuous Iteration and Correction

Regardless of the structure of the engagement, the activities in each phase are carried out in an iterative fashion that continuously incorporates review, feedback, and correction both within and between phases.

Link to detailed discussion.

This presentation and other information can be found at my website:


E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill