A Simulationist's Framework
for Business Analysis

Part 07:

Discovery and Data Collection

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

Customer Feedback Cycle

As always, here's the overview of my framework.

You always iterate within phases to build knowledge, agreement, and buy-in, and between phases for thorough and consistent, robust solutions that address the identified problem.

Link to detailed discussion.

Discovery vs. Data Collection

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

It is performed with an awareness of the problem you're trying to solve (identified in the Intended Use phase).

It's how you go from this...		...to this.

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.

Link to detailed discussion.

Discovery vs. Data Collection (continued)

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

It's how you go from this...		...to this.

Think about what you'd need to know about a car in the context of traffic, parking, service (at a gas station or border crossing), repair, insurance, design, safety, manufacturing, marketing, finance, or anything else.

Link to detailed discussion.

Context of Discovery

Elicitation identifies customers' needs. Discovery identifies elements of the existing process and potential solutions in the Conceptual Modeling phase.

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.

Links 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, environments, or "anything 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, combined, or otherwise modified.
• 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.

If you don't know how everything fits together, map this for everyone (and everything) involved and then stitch them together.

Process vs. Product vs. Environment

I tend to emphasize processes, but BA operations can also be applied to products and environments.

How would you analyze this gas station in terms of processes, products, and environment?

How would you analyze your business analysis work in terms of processes, products, and environment?

Process Mapping (continued)

Drilling down...

Process Mapping (continued)

A single gas pump can be viewed as a process and a product!

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

A product can be part of a process and support or embody many different processes. A car is a product. Think of all the processes it incorporates.

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).

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

rpchurchill.com

E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill