A Simulationist's Framework
for Business Analysis

Part 04:

The Solution

R.P. Churchill

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

Solve the Problem Abstractly Before Solving It Concretely

•   Conceptual Model (As-Is State)
•   Requirements (To-Be State: Abstract)
•   Design (To-Be State: Detailed)
•   Implementation (Future State: Concrete)

Figure out what's going on, figure out what you need, figure out how you're going to do it, then do it.

Identifying Assumptions, Capabilities, Limitations(, and Risks & Impacts) helps define the scope from what is discovered.

If you do the Conceptual Model, Requirements, and Design right, the Implementation practically builds itself!

Discovery vs. Data Collection

Discovery is a qualitative process. It identifies nouns (things) and verbs (actions, transformations, decisions, calculations).

Data Collection is a quantitative process. It identifies adjectives (colors, dimensions, rates, times, volumes, capacities, materials, properties).

Discovery comes first, so you know what data you need to collect.

Imagine you're going to simulate or automate the process. What values do you need? This is the information the implementation teams will need.

Context of Discovery

Elicitation is discovering the customer's needs. Discovery is about mapping the customer's existing process.

If there is no existing process, i.e., a new (greenfield) process is being built from scratch, then a form of discovery will occur during Requirements and Design.

Figure out what you need, figure out what needs to be going on, figure out how you're going to do it, then do it.

Link to detailed discussion.

Process Mapping

• Describes what comes in, where it goes, how it's transformed, and what comes out.
• Describes the movement and storage of information, material, people, and other entities.
• Maps define the scope of a process. Links to connected processes or "everything else" are called interfaces.
• Maps should be presented at the level of detail that makes sense.
• Process elements within maps can themselves be processes with their own maps.
• State, timing, and other data can be included.
• Entities in a process can be split and combined.
• Processes and entities may be continuous or discrete.
• Some items may never leave the system.
• Changes in state may be represented as movement — or by other means.
• ANYTHING can be included, e.g., computers, interfaces, and sections of software.

Process Mapping (continued)

• S-I-P-O-C vs. C-O-P-I-S
• Any number of inputs and outputs are possible.

Process Mapping (continued)

Process Mapping (continued)

Process Mapping (continued)

Dispensables Consumables Utilities Information Procedures Interfaces User Interaction Maintenance Cleaning Advertisements Regulations

Process Mapping (continued)

• Operations inside a process block can be examined to any depth.
• The level of detail should be appropriate to the problem.

Process Mapping (continued)

• Procedures and state transitions can be represented in any way that makes sense.
• Procedures will sometimes be random from definable results and percentages.
• Can consider the emotional or customer satisfaction level in a Customer Journey Map as part of Service Design.

Process Mapping (continued)

Processes may be mapped differently based on needs, industry standards, and the information to be represented.

Mechanical Pulping Mill, Quebec City, QC

Offgas System in BWR Nuclear Power Plant, Richland, WA

Land Border Port of Entry, Columbus, NM

Architecture Study: General Purpose Discrete-Event Simulation

Process Mapping (continued)

I give specific names to modular components.

Link to detailed discussion.

Data Collection (Process Characterization)

• Captures qualitative descriptions of entity types and characteristics, process types and characteristics, and decisions made.
• Captures quantitative data:
• physical dimensions, volumes, and storage capacities
• arrival and departure rates and times
• diversion percentages (what parts of outputs go where)
• process durations
• whatever is needed to describe transitions
• counts or quantities of what's stored
• velocities, frequencies, and fluxes
• number of stations in each sub-process

Link to detailed discussion.

Data Collection (Process Characterization) (continued)

Data collection corresponds to the Observation technique in the BABOK. Methods include:

• Walkthroughs: guided and unguided (Waste Walk)
• Drawings, Documents, Manuals, Specifications
• Electronic Collection (real-time vs. historical, integrated vs. external sensors)
• Visual / In-Person (notes, logsheets, checklists, mobile apps)
• Interviews (with SMEs)
• Surveys
• Video
• Photos
• Calculations
• Documented Procedures and Policies

Domain Knowledge Acquisition

• Domain knowledge is acquired from prior experience or training or from the process SMEs as you go.
• What you need to know to:
• capture process details
• analyze the operations
• perform calculations
• make sure you don't miss anything

Link to detailed discussion.

Making Sure The Analysis Is Thorough

• Consider all elements from all angles.
• UML is a formal example. The BABOK is more diffuse.
• Simulation is great for understanding because the results show if everything's included.
• Formal mathematical proofs of correctness and optimality exist for some problems.
• Customer review and realized results are the best proof for most BA engagements.

UML Basics

• Class Diagram: List of attributes and actions of entities in the system.
• Object Diagram: Individual instantiations of class items.
• Use Case Diagram: User interactions with system items.
• State Diagram: Unique states each system item can be in.
• Sequence Diagram: Shows the order in which events must happen, and relates items to events.
• Activity Diagram: Sequence of activities (without relating items to events explicitly).
• Collaboration Diagram: Relates items to events.
• Component Diagram: A functional section of software.
• Deployment Diagram: Describes deployed system of computers and connections.
• Other Features
• Packages: Groups of classes or components.
• Notes: A way to add clarifications to other diagrams.
• Stereotypes: Special or custom cases of any other component.
• Interface: List of operations that might apply to many items (classes).

Much of this is specifically geared toward object-oriented analysis, which is less prevalent now.

A Different Way

Identify... every element (including users). users, supplies, objects, documents, information, clocks/timers, vehicles, customers, workers every characteristic of every element (that may drive a decision or action). every action of every element (and decision logic). which elements move and don't move. whether each element processes or is processed (interactions). states each element can be in. sequences of events or states. timing or duration of events or states. location and capacity of storage elements (queues, bags, etc.) how elements can be grouped. what entities may have in common (for reuse and modularity).

Process Improvement

• Incremental improvement vs. Quantum Leap (The Big Kill!)
• Center to target and reduce variation (Six Sigma)
• Rearrangement and Compression (Lean)
• Substitution / Elimination / Automation
• Modify a sub-process and see how it affects the whole system
• Theory of Constraints: The Five Focusing Steps:
• Identify the constraint
• Exploit the constraint
• Subordinate to the constraint
• Elevate the constraint
• If constraint is "broken" go back to step 1

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

rpchurchill.com

E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill