Operations and Supply Chain

Overview

Process-flow mapping represents steps, decisions, inputs and outputs, delays, rework, and handoffs within a defined boundary. ASQ's guide emphasizes defining scope, arranging activities in sequence, reviewing the map with people involved in the process, and checking bottlenecks, errors, delays, and excessive handoffs. A map can make operating hypotheses visible, but observation, logs, incidents, service data, or urgent containment may come first. ^[6]

Figure 6.1. Constructed process-map symbol flow. The diagram uses a teaching subset of common process-map symbols and does not represent a complete notation standard. ^[6]

flowchart LR
    S([Start]) --> P[Process step]
    P --> D{Decision condition}
    D -->|Yes| E([Complete])
    D -->|No| R[Rework or escalation]
    R --> P

Text equivalent: A start/end ellipse connects to a rectangular process step and then to a diamond decision. Yes and no branches lead to completion or rework. The symbols are a teaching subset, not a complete standard.

Source note: Author-created Mermaid redraw informed by process-mapping guidance; the labels and symbols are a teaching subset and do not reproduce external artwork. ^[6]

How to Apply

1. Define Boundaries: Clearly define the start and end points of the process you are mapping. Example: "From customer order submission to product shipped" or "From raw material receipt to finished goods inventory."

2. Use a declared symbol set: For a basic map, ASQ uses a rounded rectangle or oval for start/end, a rectangle for a process step, a diamond for a decision, and arrows for direction. Declare any additions or deviations; this teaching subset is not a complete or universal notation. ^[6]

3. Use Swimlanes: Draw vertical or horizontal lanes for each department or role involved (e.g., Sales, Operations, Finance). When the process flow crosses a line, it represents a handoff—a common source of delays and miscommunication.

4. Annotate with Data: For each step, capture key metrics like Cycle Time (how long the step takes), Wait Time (how long work sits idle before this step), and Defect Rate.

Example: E-Commerce Order Fulfillment Process

Figure 6.2. Constructed order-fulfillment handoff map. The example exposes validation, rejection/remedy, warehouse, shipping, and customer handoffs without claiming that every retailer uses this sequence.

flowchart LR
    C[Customer: place order] --> V{Sales/system: valid and authorized?}
    V -->|No| R[Correct, explain, refund, or reject]
    R --> C
    V -->|Yes| W[Warehouse: pick and verify]
    W --> S[Shipping: dispatch and track]
    S --> D[Customer: receive or raise exception]
    D --> M[Measure handoffs, queues, defects, and remedy]
    M --> V

Text equivalent: A customer places an order. Sales or the ordering system validates it. Invalid orders enter a correction or rejection path; valid orders move to warehouse picking, shipment, and customer receipt. Each handoff should record owner, queue time, cycle time, defects, system state, and exception/remedy path.

Source note: Author-created Mermaid redraw informed by process-mapping guidance; the sequence and example are constructed and do not represent a company process. ^[6]

Operator's Checklist: Creating Effective Process Maps

• Observe the Work Safely: When feasible and authorized, combine frontline observation with documentation and event data. Remote, sensitive, hazardous, or regulated work may require different access and privacy controls.
• Include the Frontline Team: The people doing the work are the experts. They know the informal workarounds and hidden steps that never appear in official documentation.
• Map Reality, Not Aspiration: Your first map should capture the current state, warts and all. You'll create an ideal "future state" map later.
• Look for Handoffs: Every time work crosses a swimlane (department boundary), there's risk of delay, miscommunication, and dropped balls. These are prime targets for improvement.
• Capture Wait Times: The time work spends between steps can exceed actual process time by a large margin; use observed flow, service, quality, safety, and customer evidence to identify high-leverage opportunities.

Constructed Classroom Exercise: Paper-Airplane Flow

A facilitator can use an explicitly constructed paper-airplane simulation to compare batch size, handoffs, WIP, throughput, defects, and flow time. Record the process and results rather than attributing universal outcomes or an unverified corporate training practice.

Contrarian Thinking: When NOT to Map

While process mapping is powerful, over-mapping can be a form of waste itself. Don't map:

• Creative processes: Mapping interfaces, decisions, or learning loops may help, but do not force exploratory work into a linear production model.
• One-off processes: A one-time high-risk event may still warrant a map for coordination, safety, audit, or learning.
• Highly variable processes: If every instance is unique (e.g., complex legal cases), a single process map won't capture the reality.

So What for Managers

• Define the process boundary, owners, queues, handoffs, and exception paths before proposing an improvement.
• Combine observation with event, service, incident, customer, and safety evidence; a map is a hypothesis record, not the evidence itself.
• Use the map to stage changes and monitor cycle time, waiting, rework, quality, accessibility, labor, and risk effects.

Limits and Critiques

• A map is a selective representation and cannot by itself establish causality, capacity, customer value, or the best intervention.
• “Value-added” and “waste” classifications depend on customer, safety, regulatory, learning, and service context.
• Creative, one-off, remote, or highly variable work may require scenarios, qualitative evidence, or other methods alongside mapping.

Connections

• Input: The best data comes from direct observation of the frontline team and their feedback (Gemba walk).
• Output: A completed process map can inform a Value Stream Map, Theory of Constraints Analysis, and Six Sigma project; it is one possible starting point for improvement.

Overview

Lean developed from Toyota Production System practices and later practitioner synthesis. Womack's retrospective states five principles: customer value, value stream, flow, pull, and continuing pursuit of perfection. Use waste categories to investigate flow and customer value while protecting safety, quality, reliability, people, supplier health, learning, and necessary resilience; a labeled “waste” is a hypothesis, not an automatic deletion. ^{[3] [7]}

Visual: The 8 Wastes (TIMWOODS)

Table 6.1. TIMWOODS investigation prompts. These categories identify places to investigate; they do not authorize removal without customer, safety, quality, resilience, labor, accessibility, learning, and risk evidence. ^{[3] [7]}

How to Apply

Conduct a "Gemba Walk" (go to the actual place where work is done) and hunt for the 8 Wastes:

1. Transportation: Unnecessary movement of materials, information, or files.

   • Example: A document that gets physically passed between 5 different offices before approval.
   • Solution: Co-locate teams, use digital workflows, or redesign the layout to minimize movement.

2. Inventory: Excess stock or work-in-progress (WIP) that ties up cash and hides problems.

   • Example: A warehouse full of components "just in case" they're needed.
   • Solution: Test pull systems (Kanban), smaller batches, and JIT-style replenishment only when demand, lead-time, quality, service, safety, and supplier evidence supports the design.

3. Motion: Wasted movement by people (e.g., walking to a printer, searching for a tool).

   • Constructed example: A nurse walking a long distance each shift to retrieve supplies from a central supply room.
   • Solution: Apply 5S methods where they improve safety, access, search time, quality, or reliability; do not assume one layout fits every work setting.

4. Waiting: Idle time between process steps and decisions; investigate its causes and service consequences.

   • Constructed example: Parts sitting for several days waiting for the next manufacturing step.
   • Solution: Test workload balance, flow, pull, staffing, queue, and priority alternatives against service and safety requirements.

5. Overproduction: Making more, sooner, or faster than the next process needs.

   • Constructed example: Manufacturing produces more units than the next process or customer demand requires.
   • Solution: Align release with demand, capacity, service, shelf-life, and downstream requirements using an appropriate planning and replenishment rule.

6. Over-processing: Doing more work than the customer values (e.g., unnecessary features, excessive reporting).

   • Example: Creating beautiful PowerPoint decks when a simple email would suffice.
   • Solution: Validate what the customer actually values (Voice of Customer), then remove steps that evidence shows are not required by customer, safety, quality, regulatory, or learning needs.

7. Defects: Rework, scrap, and incorrect information that requires correction.

   • Example: 15% of manufactured parts fail quality inspection and require rework.
   • Solution: Implement Poka-Yoke (error-proofing), use Six Sigma DMAIC to reduce variation.

8. Skills (Unused): Failing to utilize the talent, ideas, and creativity of your team.

   • Example: In a constructed case, experienced assembly workers are not included in improvement design.
   • Solution: Implement suggestion systems, run Kaizen events with frontline teams, create a culture of continuous improvement.

Sourced Practice Example: Virginia Mason Health System

Kenney documents Virginia Mason's use of lean-healthcare methods and Toyota-inspired learning. Use the case to discuss translation into a service and clinical environment; do not infer exact wait, inventory, savings, satisfaction, or outcome effects without page-level inspection and design evidence. ^[8]

Operator's Practical Tip: The "5 Whys" for Waste

When you identify waste, don't just eliminate the symptom. Use the "5 Whys" technique to find the root cause:

• Observation: "There's a pile of work-in-progress inventory sitting here."
• Why? "Because the next step is backed up."
• Why? "Because that machine breaks down frequently."
• Why? "Because we don't do preventive maintenance."
• Why? "Because we don't have a maintenance schedule."
• Why? "Because no one owns the responsibility for creating one."
• Solution: Assign ownership and create a preventive maintenance program.

Contrarian Thinking: Some "Waste" is Strategic

Not all waste should be eliminated:

• Strategic Inventory: Holding extra inventory of critical components from unreliable suppliers is insurance, not waste (see Supply Chain Risk Matrix).
• Slack Capacity: Having some idle capacity in non-bottleneck steps can be rational when it protects system flow, maintenance, safety, service, or resilience. ^[2]
• Experimentation: In R&D, "defects" (failed experiments) are necessary learning. Eliminating them would kill innovation.

So What for Managers

• Use TIMWOODS categories to form testable hypotheses about flow, cost, service, quality, and customer value; do not delete work from a label alone.
• Include frontline workers and supplier, safety, accessibility, resilience, and learning evidence before changing the system.
• Prioritize improvements against system throughput, service, quality, cash, and risk rather than local utilization alone.

Limits and Critiques

• Inventory, slack capacity, redundancy, and failed experiments can be protective or valuable; “waste” is context-dependent.
• Gemba observation and 5 Whys can surface hypotheses but do not prove a root cause without measurement and challenge.
• Lean practices depend on process stability, leadership, worker participation, supplier conditions, and the decision horizon.

Connections

• Input: A Process Flow Diagram (Framework 1) makes waste, especially Waiting and Transportation, visually obvious.
• Output: The identified wastes are prioritized and become the targets for Kaizen (rapid improvement) events or larger Value Stream Mapping initiatives.

Overview

DMAIC is a structured improvement cycle for a defined, measurable process problem. The familiar 3.4 defects per million opportunities figure depends on a conventional long-term 1.5-sigma shift, a defined opportunity count, and distribution assumptions. Report the actual defect definition, denominator, measurement quality, stability, capability, uncertainty, and customer requirement rather than treating “sigma level” as universal quality. ^[9]

Visual: The DMAIC Cycle

Figure 6.3. DMAIC evidence-and-control loop. The redraw treats each phase as a decision gate and returns control evidence to a new problem definition; it does not imply that a phase is complete because a document exists. ^[9]

flowchart LR
    D[Define: customer, problem, scope, CTQ, owner, safety] --> M[Measure: operational definition, measurement system, baseline]
    M --> A[Analyze: competing causes, evidence, uncertainty]
    A --> I[Improve: options, pilot, guardrails, implementation]
    I --> C[Control: standard work, SPC where suitable, owner, response plan]
    C --> R{Requirement met and stable?}
    R -->|No| D
    R -->|Yes| H[Hand off, monitor, and retain learning]

Text equivalent: Define the customer, problem, scope, requirement, owner, and safety constraints. Measure the baseline with a validated measurement system. Analyze competing causes and uncertainty. Improve through bounded tests with guardrails. Control the adopted process with owners, response plans, and monitoring, then use new evidence to redefine or close the problem.

Source note: Author-created decision-loop redraw informed by DMAIC framing. The phases, labels, and return path are teaching synthesis, not a claim that documentation alone completes a project. ^[9]

How to Apply

DMAIC is a rigorous, 5-phase project management methodology:

1. Define: Define the problem, the customer, and the Critical-to-Quality (CTQ) requirements.

• Key Question: What does the customer consider a defect?
• Tools: Project Charter, SIPOC diagram (Suppliers, Inputs, Process, Outputs, Customers), Voice of Customer research
• Deliverable: A clear problem statement and measurable goal (e.g., "Reduce order fulfillment errors from 5% to 1%")

2. Measure: Collect data and measure the current performance of the process. Establish a baseline defect rate.

• Key Question: How bad is the problem right now, and how do we measure it consistently?
• Tools: Process mapping, data collection plans, measurement system analysis (to ensure your measurements are reliable)
• Deliverable: Baseline metrics (e.g., "Current defect rate: 5.2%, Sigma level: 3.1")

3. Analyze: Use statistical tools to analyze the data and identify the root cause(s) of the defects.

• Key Question: What are the root causes of variation and defects in this process?
• Tools: Fishbone diagrams, Pareto charts, regression analysis, hypothesis testing
• Deliverable: Validated root causes with statistical evidence

4. Improve: Brainstorm, pilot, and implement solutions that address the root causes.

• Key Question: What changes will eliminate or reduce the root causes?
• Tools: Brainstorming, Design of Experiments (DOE), pilot testing
• Deliverable: Implemented solution with proven results (e.g., "New process reduces defect rate to 0.8%")

5. Control: Implement controls and monitoring systems to ensure the improvements are sustained.

• Key Question: How do we prevent the process from reverting to its old state?
• Tools: Statistical Process Control (SPC) charts, standard work documentation, training programs, audits
• Deliverable: Control plan, updated SOPs, SPC charts monitoring key metrics

Historical Context and Evidence Boundary

Six Sigma is associated with Motorola's quality-improvement practice and later practitioner adoption. The registered source supports DMAIC management framing and the conventional performance target; this chapter does not retain unverified company defect, award, or savings figures. ^[9]

Operator's Practical Tip: Define Before Analyzing

A weak problem, customer, defect, or measurement definition can invalidate later analysis. Establish purpose, scope, affected parties, operational definition, measurement-system evidence, and decision ownership before modeling:

• Don't assume: Just because you've always measured "on-time delivery" doesn't mean that's what the customer actually cares most about.
• Interview customers: Use Jobs-to-be-Done interviews (Chapter 5) to understand what outcomes they're trying to achieve.
• Translate to CTQ: Convert customer needs into measurable Critical to Quality characteristics.

Sigma and DPMO Interpretation Boundary

DPMO = defects / (units × defined opportunities per unit) × 1,000,000. The result depends on what counts as a unit, opportunity, and defect. Do not convert DPMO to a sigma label or quality judgment without stating the long-term-shift and distribution conventions. A statistically stable process can still be incapable of meeting specifications, and an apparently capable process can be unstable or poorly measured. ^{[9] [10]}

Contrarian Thinking: Six Sigma Can Kill Innovation

While incredibly powerful for optimizing existing, high-volume processes, applying Six Sigma to creative or innovative work (like R&D) can be disastrous:

• Innovation requires variation: Experimentation means trying new things, where "defects" (failed experiments) are necessary learning.
• Six Sigma optimizes for efficiency: It reduces variation, which is the opposite of what you need in exploration and creativity.
• Rule of Thumb: Use Six Sigma for exploitation (optimizing known processes). Use Lean Startup/Agile for exploration (discovering new products/markets).

So What for Managers

• Define the customer requirement, defect, opportunity, unit, measurement system, owner, and decision before calculating a sigma or capability result.
• Use stability and capability evidence to select a bounded pilot, then retain a control plan that states triggers, responses, and escalation.
• Separate exploratory learning from repeatable-process improvement so efficiency targets do not suppress useful variation.

Limits and Critiques

• The 3.4 DPMO convention depends on a long-term shift, opportunity definition, distribution, and measurement assumptions; it is not universal quality.
• A stable process can be incapable, and an apparently capable result can be invalid if the measurement system, subgrouping, or specification is wrong.
• DMAIC does not prove causality or guarantee a durable result; data quality, adoption, safety, and customer requirements remain decisive.

Connections

• Input: A problem identified by a high Defect Rate on a Process Flow Diagram or a poor quality metric on a Financial Ratios Dashboard (Chapter 4).
• Output: A control plan and a measured improvement hypothesis; any defect-rate change must be demonstrated with local data. The SPC Charts (Framework 8) are a key tool used in the "Control" phase.

Overview

Theory of Constraints (TOC) is a management philosophy associated with Goldratt and Cox's The Goal. It focuses attention on the factor currently limiting a defined system goal, but “one constraint” is an operating abstraction: constraints can be interacting, product- or horizon-specific, misidentified, or shifting. Work away from the current throughput constraint can still create independent value through safety, quality, reliability, maintenance, risk reduction, learning, demand, or preparation for a future constraint. ^{[1] [2]}

Visual: Identifying the Bottleneck

Figure 6.4. Constructed five-step capacity line. Under one product, one route, qualified output, adequate demand, and the stated capacities, assembly is the candidate constraint at five units per hour. Actual throughput can be lower because of downtime, yield, setup, starvation, blocking, mix, labor, or policy.

flowchart LR
    C[Cut: 10 per hour] --> P[Polish: 15 per hour]
    P --> W[Observed WIP before assembly]
    W --> A[Assembly: 5 per hour candidate constraint]
    A --> T[Test: 12 per hour]
    T --> K[Pack: 20 per hour]
    X[Verify demand, mix, yield, setup, downtime, starvation, blocking, and policy] -.-> A

Text equivalent: Material moves through cutting at 10 units per hour, polishing at 15, assembly at 5, testing at 12, and packing at 20. Work may accumulate before assembly, making it the candidate constraint in this simplified case. Managers must verify qualified throughput, demand, mix, downtime, setup, flow, safety, quality, and policy before acting.

Source note: Author-created capacity-line example informed by Theory of Constraints logic. Capacities and positions are constructed teaching inputs, not a measured facility or benchmark. ^{[1] [2]}

How to Apply

The five focusing steps:

1. Identify the Constraint Map your process and identify a candidate constraint using qualified throughput, WIP, demand, mix, downtime, setup, and policy evidence. A pile of work or a long cycle time is a clue, not proof of the system constraint.

• How to spot it: Look for the step where work piles up upstream, or the step that has the longest cycle time.
• Common mistake: Focusing on the busiest resource. The constraint isn't necessarily the busiest; it's the one limiting total output.

2. Exploit the Constraint Improve use of the constraint without compromising safety, quality, maintenance, labor, or regulation.

• Protect productive time: Reduce avoidable waits for materials, approvals, or repairs while preserving required controls and maintenance.
• Eliminate waste at the bottleneck: Reduce setup times, eliminate defects that waste constraint time, optimize the work sequence.
• Consider capacity options: Scheduling, setup reduction, cross-training, shifts, or outsourcing require fatigue, safety, quality, cost, and labor review.

3. Subordinate Everything Else Coordinate non-constraint work with the current flow hypothesis when doing so improves the defined system goal and does not compromise safety, quality, maintenance, service, learning, or other independent obligations.

• Control overproduction: Match release and production to downstream demand and variability where excess WIP would create delay, cost, expiry, or quality risk.
• Design buffers: Size time, capacity, or inventory protection from variability, service, perishability, cost, and risk rather than using a universal “small” buffer.
• Permit protective capacity: Non-constraint resources need not maximize utilization; idle or reserved capacity can be rational when it protects flow, resilience, maintenance, or service.

4. Elevate the Constraint If evidence shows that more system output is valuable, compare capacity investment at the current constraint with demand management, redesign, quality, policy, risk, and alternative interventions. The canonical sequence is a focusing aid, not an absolute ban on earlier investment.

• Options: Add staff, buy another machine, outsource the bottleneck step, or completely redesign the process.
• Value test: Capacity at the current constraint may raise throughput, but compare demand, future constraints, economics, risk, and alternative interventions before investing.

5. Repeat After an intervention, remeasure the system and return to Step 1; the constraint may move, remain, or prove to have been misidentified.

• Warning: Don't let inertia become the constraint. After elevating, re-examine your policies and assumptions.

Figure 6.5. Theory of Constraints five focusing steps. The canonical loop returns from elevation to identification; measurement is a control across every step, not a replacement focusing step. ^{[1] [2]}

flowchart TD
    A[Identify Constraint] --> B[Exploit Constraint]
    B --> C[Subordinate Other Work]
    C --> D[Elevate Constraint]
    D --> E[Return to Identify; Prevent Inertia]
    E --> A
    M[Measure Flow, Safety, Quality, Cost, and Risk] -.-> A
    M -.-> B
    M -.-> C
    M -.-> D

    style A fill:#4ecdc4
    style B fill:#ffd93d
    style D fill:#95e1d3
    style E fill:#ff6b6b

Text equivalent: Identify the current system constraint, exploit it within safety and quality limits, subordinate other work to system flow, elevate the constraint when evidence supports investment, then return to identification and prevent old policies from becoming the constraint. Measure flow, safety, quality, cost, and risk throughout.

Source note: Original redraw of the Theory of Constraints focusing steps; the dotted measurement node is an explicit control overlay, not an added canonical step. ^{[1] [2]}

Constructed Semiconductor Constraint Example

In a constructed fabrication line, a lithography step limits qualified output. The team protects required maintenance and quality checks, reduces avoidable setup and starvation, limits upstream release, and compares an additional tool with scheduling, yield, and demand options. The case is illustrative and makes no claim about a named manufacturer or equipment cost.

Operator's Critical Insight: Optimize the System, Not Local Busy Time

• The current constraint can bound throughput under the specified demand, routing, mix, quality, and time horizon.
• Lost productive constraint time can reduce feasible throughput, but maintenance, safety, quality, and controlled downtime may protect total value.
• Nonconstraint improvements can reduce defects, risk, cost, setup, fatigue, or future bottlenecks even when they do not raise current throughput. ^{[1] [2]}

Visual: Drum-Buffer-Rope System

TOC uses a "Drum-Buffer-Rope" system to synchronize production:

Figure 6.6. Constructed drum-buffer-rope control logic. The constraint schedule is the drum, a context-sized time/capacity/inventory buffer protects it from selected variation, and the rope controls upstream release. The design does not require zero upstream activity or a universally small buffer. ^{[1] [2]}

flowchart LR
    D[Qualified demand and due dates] --> S[Drum: constraint schedule]
    S --> B[Buffer: time, capacity, or inventory protection]
    B --> C[Constraint executes qualified work]
    C --> O[Downstream flow and customer output]
    B --> R[Rope: release signal based on buffer status]
    R --> U[Upstream material and work release]
    U --> B
    G[Safety, quality, maintenance, service, and risk controls] -.-> S
    G -.-> B
    G -.-> R

Text equivalent: Demand and the constraint schedule set a paced release signal. Upstream work replenishes a protective buffer rather than maximizing local output. Buffer status and constraint performance feed back to release. Safety, quality, maintenance, perishability, reliability, service, and disruption risk determine whether and how the control should be used.

Source note: Author-created drum-buffer-rope redraw informed by Theory of Constraints logic. Buffer size, release rules, and controls are context-specific teaching synthesis. ^{[1] [2]}

Contrarian Thinking: Efficiency is a Trap

TOC directly contradicts traditional "efficiency" thinking:

• Traditional view: "Keep every machine and every person busy all the time."
• TOC view: Local utilization should serve system flow rather than become an end in itself.
• Why? Producing without downstream demand can create excess WIP; protective capacity may still support variability, maintenance, safety, and service.
• Balanced measures: Track throughput, WIP, flow time, service, quality, safety, cost, and risk rather than one utilization target.

So What for Managers

• Validate the system goal, demand, mix, horizon, and qualified throughput before naming the current constraint.
• Exploit and elevate the constraint only after checking safety, quality, maintenance, labor, service, economics, and alternative interventions.
• Remeasure after each intervention and return to identification when the constraint moves, persists, or was misidentified.

Limits and Critiques

• Constraints can be multiple, interacting, policy-based, demand-based, or shifting; “one bottleneck” is a useful abstraction, not a law.
• Nonconstraint work can create independent value through safety, quality, reliability, learning, preparation, or future-constraint reduction.
• More capacity at a bottleneck does not guarantee more value if demand, mix, downstream flow, cash, or service conditions do not support it.

Connections

• Input: A Process Flow Diagram (Framework 1) with cycle time data is essential for identifying the constraint.
• Output: The analysis informs Capacity Planning (Framework 7) by identifying precisely where investment in new capacity will actually increase system-wide output.

Overview

Inventory is a double-edged sword: too little, and you risk stockouts and lost sales; too much, and you tie up cash and risk obsolescence. This section compares two classic models—EOQ and JIT—alongside the separate protection-policy choices needed for uncertain demand and supply.

Visual: EOQ vs. JIT Comparison

Figure 6.7. Constructed EOQ/JIT decision path. EOQ is a cost-minimizing lot-size model under explicit assumptions. JIT is a pull-and-flow operating system, not a command to drive inventory to zero. Both require separate treatment of variability, shortage consequences, service, quality, resilience, and working capital. ^{[3] [4]}

flowchart LR
    D[Decision context: demand, lead time, service, shortage, quality, resilience, cash] --> A{Which operating question dominates?}
    A -->|Lot-size cost under defensible assumptions| E[EOQ candidate: square root of 2DS divided by H]
    A -->|Pull, flow, small batches, quality at source| J[JIT operating design]
    E --> V[Validate assumptions and sensitivities]
    J --> V
    V --> P[Set context-specific replenishment and protection policy]

Text equivalent: EOQ converts demand, ordering cost, and unit holding cost into a candidate order quantity when its assumptions are adequate. JIT links replenishment to consumption while improving flow and quality. Neither approach determines the protective inventory needed for uncertain demand, unreliable supply, safety, or continuity.

Source note: Author-created decision-path redraw. The EOQ and JIT labels are bounded by the adjacent assumptions and do not establish a universal inventory policy. ^{[3] [4]}

How to Apply

1. Economic Order Quantity (EOQ) EOQ calculates the order quantity that minimizes the model's ordering and holding costs under assumptions such as stable demand, fixed order cost, constant unit holding cost, no stockouts, and unconstrained replenishment. Validate those assumptions before use.

Formula: EOQ = √(2DS/H)

• D = Annual demand (units/year)
• S = Fixed cost per order ($)
• H = Holding cost per unit per year ($)

Illustrative Calculation:

• Annual demand: 10,000 units
• Order cost: $100 per order
• Holding cost: $5 per unit per year
• EOQ = √(2 × 10,000 × 100 / 5) = √400,000 = 632 units per order
• Orders per year = 10,000 / 632 = 16 orders

Use when: The assumptions are reasonable enough for the decision and sensitivity does not reverse it; otherwise use a model that represents uncertainty, service, shortage, perishability, capacity, or quantity discounts.

2. Reorder points and protection:

• Define the service target, demand during lead time, review period, lead-time distribution, shortage consequence, perishability, and supplier recovery before setting a reorder point.
• A simple teaching form is Reorder Point = expected demand during lead time + safety stock; size safety stock from the stated service target, demand/lead-time variability, correlation, and review policy rather than a universal days-of-supply rule.
• For multi-echelon networks, model where protection sits and how upstream and downstream buffers interact; do not add independent safety stock at every node without checking total cost and service.

3. Just-in-Time (JIT) JIT is a pull-oriented operating system that seeks flow, quality at source, small batches, and replenishment linked to consumption. “As little inventory as possible” is not the goal when variability, service, safety, or resilience requires protection. ^[3]

Core Principles:

• Use a pull signal where appropriate: Link replenishment to consumption and an explicit protection policy; forecasts still inform capacity, procurement, and supplier planning.
• Small batch sizes: Frequent deliveries of small quantities
• Supplier capability and recovery: Validate lead time, quality, information, capacity, geographic exposure, and recovery options; proximity alone is not a guarantee.
• Quality at the source: Build supplier and process quality into the system; retain incoming verification where risk, regulation, or evidence requires it.

Use when: The pull design fits observed demand, lead-time, quality, service, supplier, and resilience evidence; validate reliability rather than assuming it.

Toyota Production System Evidence Boundary

Ohno's account supports JIT, pull, flow, and waste-elimination principles in the Toyota Production System. It does not support the exact delivery-hour, inventory-day, working-capital, earthquake, or post-disruption claims previously presented here. Use local demand, lead-time, quality, supplier, and disruption evidence to design inventory protection. ^[3]

The Hybrid Approach: Best of Both Worlds

Table 6.2. Constructed candidate hybrid inventory policies. The item descriptions suggest models to evaluate, not automatic assignments.

Operator's Decision Matrix

Choose your inventory strategy based on two factors:

Table 6.3. Constructed inventory-policy decision matrix. The candidate policies are prompts for scenario analysis, not automatic assignments.

Resilience Boundary

Do not optimize inventory in isolation. Compare ordering, holding, shortage, obsolescence, working-capital, service, safety, supplier, concentration, and disruption costs under explicit scenarios. A hybrid policy may be appropriate, but the buffer must be item-, network-, and decision-specific.

So What for Managers

• Select EOQ, pull/JIT, reorder, safety-stock, or hybrid policies only after defining demand, lead time, service, shortage, holding, and disruption assumptions.
• Use EOQ as a candidate lot-size calculation and compare it with scenario-based shortage, perishability, capacity, supplier, and quality consequences.
• Reconcile inventory choices with working capital, customer service, safety, supplier concentration, and recovery options.

Limits and Critiques

• EOQ assumes stable demand, fixed order cost, constant holding cost, no stockouts, and unconstrained replenishment; real decisions often violate these assumptions.
• JIT is a pull-and-flow system, not a universal zero-inventory policy; variability and resilience can justify protection.
• Aggregate inventory ratios can hide item, location, lifecycle, substitution, and network-level risk.

Connections

• Input: Demand forecasts from the Sales team and lead times from the Procurement/Supply Chain team are critical inputs.
• Output: The chosen inventory strategy directly impacts your Working Capital Cycle (Chapter 4) and the resilience of your operations as mapped in the Supply Chain Risk Matrix (Framework 6).

Overview

Supply-chain risk triage in this matrix is an author-created ordinal aid, not a published quantitative model or estimate of expected loss. Define the disruption scenario, time horizon, evidence, affected service, dependencies, detectability, recovery, and owner; separately analyze concentration, correlated failures, tail risk, and mitigation economics.

Figure 6.8. Constructed supply-chain risk triage matrix. The anonymous positions are discussion prompts, not measured probabilities, expected losses, or automatic action rules.

quadrantChart
    title Supply Chain Risk Matrix
    x-axis Low Ordinal Likelihood --> High Ordinal Likelihood
    y-axis Low Impact --> High Impact
    quadrant-1 Higher Likelihood / Higher Impact
    quadrant-2 Lower Likelihood / Higher Impact
    quadrant-3 Lower Likelihood / Lower Impact
    quadrant-4 Higher Likelihood / Lower Impact
    Scenario A: [0.8, 0.9]
    Scenario B: [0.3, 0.8]
    Scenario C: [0.7, 0.4]
    Scenario D: [0.2, 0.2]

Text equivalent: Place each explicitly defined disruption scenario on ordinal likelihood and impact axes for triage. High-impact scenarios require contingency and recovery analysis even when likelihood is uncertain; high-likelihood scenarios require process and control analysis. An owner must validate evidence, dependencies, mitigation cost, and residual risk before acting.

Source note: Author-created ordinal triage aid. Scenario labels and coordinates are illustrative; they are not probability estimates, expected losses, or action recommendations.

How to Apply

Step 1: Brainstorm Risks List all potential supply chain risks across categories:

• Supplier Risks: Sole-supplier failure, quality issues, financial insolvency, labor strikes
• Geopolitical Risks: Trade wars, sanctions, political instability, regulatory changes
• Natural Disasters: Earthquakes, floods, hurricanes, pandemics
• Logistics Risks: Port congestion, transportation delays, customs issues
• Cyber Risks: Ransomware attacks on suppliers, data breaches
• Demand Risks: Sudden demand spikes or drops, product obsolescence

Step 2: Assess Likelihood and Impact For each scenario, use clearly anchored ordinal categories or evidence-based probability ranges; do not multiply uncalibrated ordinal scores as though they were quantities. Define impact across safety, service, finance, legal/regulatory, reputation, recovery time, and affected stakeholders.

Step 3: Plot on the Matrix

• High-likelihood/high-impact: Escalate for deeper analysis; urgency depends on time horizon, controls, recovery, legal/safety duties, and mitigation options.
• Yellow Zone (Either High): Lower-likelihood/higher-impact scenarios may require contingency planning; higher-likelihood/lower-impact scenarios may warrant process or control improvement after exposure, cost, service, and residual-risk review.
• Green Zone (Both Low): Accept and monitor the risk.

Step 4: Develop Mitigation Plans For each significant risk, choose a mitigation strategy:

Table 6.4. Constructed supply-chain risk mitigation options for scenario review. The options require cost, service, recovery, safety, supplier, and residual-risk analysis.

Constructed Electronics-Supply Scenario

A manufacturer depends on one qualified component with a long recovery time. It compares redesign, second-source qualification, supplier development, strategic inventory, contractual capacity, geographic diversification, and business-continuity options. The team models cost, qualification time, correlated failure, quality, IP, demand, and residual risk rather than claiming that any one mitigation ensures continuity.

Network Design and Resilience Screen

1. Map supplier, plant, warehouse, route, customer, and recovery nodes; record concentration, substitutability, lead time, qualification time, and dependencies.
2. Compare total landed cost—not purchase price alone—across transport, duties, inventory, quality, labor, energy, carbon, service, disruption, and switching costs.
3. Stress-test disruption scenarios with time-to-detect, time-to-recover, service loss, liquidity, safety, contractual, and residual-risk measures.
4. Select a staged option with an owner, trigger, review date, evidence threshold, and rollback or exit path; resilience is a portfolio decision, not a matrix color.

Operator's Practical Tip: The "Cone of Uncertainty"

Long lead time, concentration, low visibility, correlated exposure, and slow recovery can increase vulnerability, but their effects are not captured by multiplying ordinal labels. Build scenarios with explicit probability or range evidence, time-to-detect, time-to-recover, service impact, and mitigation options.

Contrarian Thinking: Resilience Costs Money (But It's Worth It)

• The trade-off: Resilience options can add recurring cost or complexity; compare them with scenario-specific disruption loss, liquidity, safety/service obligations, option value, and residual risk.
• The decision: Compare recurring resilience cost with scenario-based disruption loss, liquidity, safety/service obligations, option value, and residual risk. Expected cost is useful only when probability and consequence estimates are decision-grade.

So What for Managers

• Define each disruption scenario, owner, horizon, affected service, dependencies, detectability, recovery time, and evidence before scoring it.
• Use ordinal triage to prioritize deeper analysis; use calibrated probabilities or ranges when an expected-loss or investment decision requires them.
• Link each material risk to a mitigation, trigger, contingency, recovery owner, review date, and residual-risk decision.

Limits and Critiques

• Ordinal likelihood and impact labels are not probabilities, expected losses, or a license to multiply scores into precise risk.
• Correlated failures, tail events, changing controls, and slow recovery can dominate a simple two-axis placement.
• Mitigation can add cost, supplier, cyber, quality, legal, workforce, or concentration risk; diversification is not automatically safer.

Connections

• Input: The matrix is informed by geopolitical analysis from your PESTLE Analysis (Chapter 3) and supplier reliability data from your Procurement team.
• Output: The mitigation strategies inform your Inventory Management Models (Framework 5) (e.g., justifying safety stock) and can be a key part of your overall Business Continuity Plan.

Overview

Capacity planning compares resource options with uncertain demand, service, cost, indivisibility, ramp time, utilization/queue effects, labor, quality, and option value. Lead, lag, and match are stylized strategies, not universal prescriptions. ^[11]

Visual: Capacity Planning Strategies

Figure 6.9. Constructed capacity-strategy comparison. Lead, lag, and match describe timing choices, not guaranteed outcomes. A lead strategy creates capacity before observed demand; lag waits for stronger demand evidence; match adds capacity in increments. Each can outperform or fail depending on forecast error, queueing, ramp time, service loss, indivisibility, reversibility, and cost. ^[11]

flowchart LR
    U[Demand scenarios and uncertainty bounds] --> L[Lead: commit before demand is observed]
    U --> G[Lag: commit after demand evidence]
    U --> M[Match: stage incremental commitments]
    L --> T[Compare service, queueing, cost, ramp time, reversibility, and downside]
    G --> T
    M --> T
    T --> R[Choose, monitor triggers, and preserve revision options]

Text equivalent: Compare the same demand scenarios against three capacity paths. Lead commits earlier and risks unused capacity; lag commits later and risks congestion or unmet demand; match stages smaller commitments but can add coordination cost and still miss abrupt changes. Choose through scenario analysis rather than a universal ranking.

Source note: Author-created capacity-strategy comparison informed by capacity-expansion evidence. The strategies and paths are constructed and do not guarantee service, economics, or market outcomes. ^[11]

How to Apply

Step 1: Measure Current Capacity Determine the maximum theoretical output of your current resources.

• Manufacturing: Units per hour, shift, or day
• Service: Transactions per hour, customers served per day
• Software: API requests per second, concurrent users

Important: Measure effective capacity, not just theoretical. Account for:

• Downtime (maintenance, changeovers)
• Quality issues (scrap, rework)
• Efficiency losses (breaks, training time)

Step 2: Forecast Future Demand Obtain a demand forecast from Sales and Marketing teams:

• Monthly or quarterly projections for the next 12-24 months
• Include seasonality and growth trends
• Add uncertainty bounds (best case, worst case, most likely)

Step 3: Identify Capacity Gaps Constructed capacity-gap example: The following values are teaching inputs, not a benchmark or real-company result. Compare demand forecast to capacity. Create a capacity gap analysis:

Month    Demand    Capacity    Gap      Status
Jan      10,000    12,000      +2,000   ✓ Excess capacity
Feb      11,000    12,000      +1,000   ✓ Excess capacity
Mar      13,500    12,000      -1,500   ⚠ Shortfall
Apr      15,000    12,000      -3,000   ⚠ Critical shortfall

Step 4: Choose a Capacity Strategy

LEAD Strategy: Add capacity before demand materializes

• When to consider: Demand evidence is relatively strong and the service or opportunity cost of waiting is material.
• Example: A constructed retailer adds seasonal capacity before demand materializes.
• Pro: May protect service and capture demand if the capacity, quality, labor, and economics hold.
• Con: Risky if forecast is wrong; high upfront cost

LAG Strategy: Add capacity after stronger demand evidence

• When to consider: Demand is uncertain, capital is constrained, or the penalty for delayed service is manageable.
• Constructed example: A restaurant adds tables after sustained demand and service evidence.
• Pro: Lower risk, higher asset utilization
• Con: May create lost service or demand during the catch-up period.

MATCH Strategy: Add capacity in smaller increments as evidence changes

• When to consider: The operation can add capacity in reversible or modular increments and review frequently.
• Constructed example: A digital service adds server capacity as observed demand and service thresholds change.
• Pro: Balanced risk/reward
• Con: Requires frequent planning cycles and flexible capacity options

Step 5: Evaluate Options For a capacity shortfall, model the ROI of different options:

• Overtime: Quick, flexible, but expensive per unit
• Add shifts: Moderate cost, requires available labor
• Outsource: May be fast, but requires service, quality, security, labor, IP, and dependency controls.
• Expand facility: May offer scale, but has long lead time, capital exposure, permitting, and stranded-asset risk.

Constructed Capacity-Expansion Case

A manufacturer must choose among overtime, a new shift, outsourcing, modular expansion, and a large facility before demand is certain. Compare demand scenarios, ramp time, quality, labor, supply dependencies, financing, stranded-asset downside, option value, and exit/redeployment. A lead strategy can capture demand or destroy capital; the model must show both. ^[11]

Operator's Practical Tip: The Capacity Buffer Rule

Queueing logic warns against planning at full utilization because variability causes waiting time to rise sharply as utilization approaches full load. ^[4]

• With buffer: You have room for demand spikes and maintenance.
• Near full load: Disruptions such as machine breakdowns or demand spikes are more likely to cause missed deadlines and quality issues.
• At full load: There is no room for error; stress rises and corners get cut.

So What for Managers

• Reconcile demand scenarios with effective—not theoretical—capacity, including downtime, yield, setup, labor, quality, and service constraints.
• Compare lead, lag, match, overtime, outsourcing, modular expansion, and demand-shaping options under the same scenarios and decision date.
• Include financial, labor, safety, quality, supplier, reversibility, and queue effects in the capacity recommendation.

Limits and Critiques

• Forecasts, ramp times, demand substitution, and capacity availability are uncertain; a deterministic gap table is not a demand or service forecast.
• High utilization can increase waiting nonlinearly, while unused capacity can protect service, maintenance, learning, or resilience.
• Capacity investments can be lumpy, slow, irreversible, and dependent on financing, skills, permits, suppliers, and future constraints.

Connections

• Input: Requires the demand forecast from your GTM Strategy (Chapter 14).
• Input: The ROI calculation for a major capital investment requires a DCF model (Chapter 4).
• Output: The decision to invest in new capacity is a major component of the company's Financial Forecast (Chapter 4).

Overview

Statistical process control (SPC) uses time-ordered data and a chart suited to the measure and sampling design to distinguish evidence of common-cause from special-cause variation. Control limits describe process behavior under the baseline; they are not specification limits and do not establish capability, customer acceptability, causality, or safety. ^[10]

Visual: SPC Control Chart (In Control vs. Out of Control)

Figure 6.10. Constructed SPC signal-response loop. A pre-specified signal on a correctly chosen and validated chart triggers the response plan; it does not by itself prove a special cause, mandate a universal shutdown, or establish process capability. ^[10]

flowchart LR
    A[Choose measure, chart, subgrouping, and baseline] --> B[Pre-specify signal rules and response plan]
    B --> C[Plot time-ordered observations]
    C --> D{Applicable rule signals?}
    D -->|No| E[Continue monitoring; assess capability separately]
    D -->|Yes| F[Protect as required, verify measurement, investigate]
    F --> G{Cause supported?}
    G -->|Yes| H[Correct, document, and validate recovery]
    G -->|No| I[Record uncertainty; avoid unsupported adjustment]
    H --> C
    I --> C

Text equivalent: Select a chart and sampling design, establish a defensible baseline, pre-specify applicable signal rules and responses, plot time-ordered data, and distinguish routine behavior from a signal. When a signal occurs, protect people or output as the context requires, verify measurement, investigate plausible causes, document the finding, and validate recovery. If a stable process is still unacceptable, redesign it rather than tampering with individual points.

Source note: Author-created signal-response redraw informed by SPC interpretation guidance. The signal rules and response path are teaching synthesis and require chart- and process-specific validation. ^[10]

How to Apply

Step 1: Select a Critical Process Metric Choose a key quality characteristic to monitor:

• Manufacturing: Product dimensions, weight, temperature, defect rate
• Service: Call handle time, customer satisfaction score, delivery time
• Software: Response time, error rate, uptime percentage

Step 2: Establish Control Limits Collect enough representative baseline data to assess stability for the selected chart and subgroup design; no universal sample count applies. Depending on chart assumptions, estimate:

• Mean (μ): Average of all baseline samples
• Standard Deviation (σ): Measure of variation
• Upper Control Limit (UCL): μ + 3σ
• Lower Control Limit (LCL): μ - 3σ

Three-sigma limits are a common Shewhart convention, but calculation and interpretation depend on chart type, subgrouping, distribution, autocorrelation, measurement quality, and the run rules chosen. A signal prompts investigation; it does not prove a cause. ^[10]

Step 3: Plot Data Over Time Continuously plot samples of your process metric on the chart. Update daily, hourly, or in real-time depending on the process.

Step 4: Interpret the Signals

In Control (Common Cause Variation):

• All points are within UCL and LCL
• Points are randomly distributed (no patterns)
• Action: Avoid reacting to individual routine points as special causes. If capability, safety, service, or economics are unacceptable, redesign the system using an appropriate improvement method.

Signal requiring investigation: A pre-specified chart rule, data-quality concern, or relevant specification/safety signal requires investigation; it is not a confirmed special cause.

1. Point outside selected limits: Investigate after checking the chart, data, measurement system, and applicable limits.
2. Run or trend rule: Use only a rule selected for the chart, subgroup, distribution, and operating decision; do not assume seven points is universal.
3. Cyclic or patterned behavior: Investigate when the pattern is relevant to the sampling interval and process mechanism.
4. Sudden shift: Check data integrity, measurement changes, process changes, and plausible causes before adjusting the process.

Measurement and Capability Check

• Verify calibration, repeatability/reproducibility or classification agreement, sampling, data integrity, and subgroup logic before interpreting a signal or capability result.
• Define the customer, engineering, regulatory, or safety specifications separately from control limits. For a stable continuous process with defensible assumptions, capability indices can be calculated as Cp = (USL − LSL) / (6σ) and Cpk = min((USL − mean) / (3σ), (mean − LSL) / (3σ)); otherwise report observed nonconformance, percentiles, and uncertainty instead of forcing an index. ^[10]
• Treat capability as conditional on the measurement system, stability, distribution, specification, and sampling plan; a capability number does not prove customer acceptability or safety.

Constructed SPC Investigation

A dimensional chart shows a pre-specified run-rule signal before measurements cross the engineering specification. The owner follows the response plan, protects potentially affected material, verifies the measurement system, investigates equipment and material changes, documents the cause, and validates recovery. Control limits and specification limits remain distinct. ^[10]

Operator's Critical Mistake: "Tampering"

The Problem: Many operators see normal variation and overreact, constantly adjusting the process.

• Example: Widget weight varies between 98g and 102g (within control limits). Operator sees 98g and increases material. Next part is 104g (out of spec). Operator decreases material. Next is 96g. The operator's adjustments are making things worse!
• The Solution: Do not adjust a stable process in response to individual routine points. Improve an incapable or harmful stable process through designed system change, then establish and validate a new baseline.

The Four Types of SPC Charts

Table 6.5. Constructed common SPC chart candidates. Selection also depends on sampling, subgroup logic, opportunity or exposure, distributional assumptions, independence, measurement quality, and the response plan. ^[10]

Contrarian Thinking: SPC Can't Fix a Bad Process

• The Mistake: Putting SPC charts on a fundamentally flawed process.
• The Reality: SPC tells you when a process has changed, but it doesn't tell you how to improve the process. If your process is "in control" at a 15% defect rate, SPC will just tell you "Yes, you're consistently producing 15% defects."
• The Fix: Use Six Sigma DMAIC (Framework 3) to improve the process first, then use SPC to hold the gains.

So What for Managers

• Select a chart and sampling design that match the measure, subgroup, opportunity, distribution, independence, and response decision.
• Establish a defensible baseline, pre-specify signal rules, verify the measurement system, and document the investigation response.
• Distinguish common-cause stability from capability, specifications, customer acceptability, and safety before deciding to hold or change the process.

Limits and Critiques

• Control limits describe baseline process behavior; they are not specification limits, safety thresholds, or proof of capability.
• A signal prompts investigation but does not prove a cause; autocorrelation, subgrouping, classification, and measurement error can mislead.
• SPC can monitor a bad process consistently; redesign, DMAIC, engineering, or containment may be needed instead of tampering with routine points.

Connections

• Input: The metric to be controlled is often a "Critical to Quality" (CTQ) characteristic identified during a Six Sigma DMAIC (Framework 3) project.
• Output: SPC charts are the core tool used in the "Control" phase of Six Sigma to ensure that process improvements are sustained over time.

Overview

Value Stream Mapping (VSM) records the material and information flow required to bring a product or service to a customer, beyond the steps shown in a process-flow diagram. It helps a team distinguish value-creating from non-value-creating activities and use a current-state map to design a leaner future state. ^[5]

Visual: Value Stream Map Example

Figure 6.11. Constructed current-state value-stream map. Cycle and queue times are teaching inputs, not a benchmark or named-factory result. The arithmetic declares the listed process time as a process-time input; it does not classify that time as customer value unless a real team separately defines the clock, states, demand, quality, rework, and customer value. ^[5]

flowchart LR
    CU[Customer demand] --> PC[Production control]
    PC --> SU[Supplier order and status]
    PC -. daily schedule .-> ST[Stamp: 30 seconds]
    SU --> Q1[Queue: 5 days]
    Q1 --> ST
    ST --> Q2[Queue: 3 days]
    Q2 --> WE[Weld: 45 seconds]
    WE --> Q3[Queue: 4 days]
    Q3 --> PA[Paint: 60 seconds]
    PA --> Q4[Queue: 2 days]
    Q4 --> AS[Assemble: 90 seconds]
    AS --> SH[Ship and customer receipt]
    SH --> CU

Text equivalent: Production control receives customer demand, sends a supplier order and a daily schedule, and receives status from the flow. Material moves through stamping, welding, painting, and assembly with illustrative cycle times of 30, 45, 60, and 90 seconds. Illustrative queues of 5, 3, 4, and 2 days create 14 days of lead time versus 3.75 minutes of listed process time. The discrepancy is a diagnostic prompt, not proof that all unlisted time is removable waste.

Source note: Author-created current-state redraw informed by VSM practice. The process, timings, queues, and ratio are constructed teaching inputs and not a factory benchmark. ^[5]

How to Apply

Step 1: Map the Current State Walk the entire process ("Gemba") from start to finish. Document for each step:

• Cycle Time (C/T): How long the actual work takes; do not equate processing time with customer value without a separate classification.
• Uptime %: Equipment availability
• Changeover Time: Time to switch between products
• Batch Size: How many units are processed together
• Defect Rate: Percentage of defective outputs
• Number of Operators: Labor required
• Wait Time: Time between this step and the next; classify its customer, safety, quality, and process role separately

Step 2: Compare observed work time with elapsed lead time Use a process-time ratio only as a diagnostic: it is sum of observed processing time / total elapsed lead time, not a value-added ratio unless the team separately defines customer value, required work, quality, safety, regulatory, and learning requirements.

• Constructed example: (30 sec + 45 sec + 60 sec + 90 sec) / 14 days = 3.75 min / 20,160 min = 0.02% of elapsed time. This does not establish that all processing time creates customer value or that all waiting is removable.
• Author synthesis: Interpret the ratio within the local process boundary, demand, quality, safety, customer, and service evidence rather than applying a universal benchmark. ^[5]

Step 3: Design the Future State The goal is to reduce avoidable waiting where customer value, system economics, safety, quality, workforce, supplier, and resilience evidence support the change:

• Create Continuous Flow: Can steps be physically moved closer together so work flows directly from one to the next without waiting?
• Implement Pull Systems: Use Kanban to ensure each step only produces what the next step needs, when it needs it
• Reduce Batch Sizes: Smaller batches mean less WIP inventory and faster flow
• Eliminate Bottlenecks: Apply Theory of Constraints to address the limiting step

Constructed target: Test whether the illustrative 14-day lead time can be reduced by changing WIP, batches, flow, and handoffs; do not assume a 2–3 day target or that all WIP is removable.

Step 4: Create an Implementation Plan Break the transformation into actionable Kaizen events:

• Kaizen Event 1: Test whether rearranging Stamp and Weld reduces WIP or waiting under explicit safety, quality, service, and flow guardrails.
• Kaizen Event 2: Implement Kanban between Weld and Paint (reduce batch sizes)
• Kaizen Event 3: Cross-train operators to balance workload
• Timeline: One Kaizen event per month for 6 months

Sourced Practice Context: Toyota's Process Logic

In Womack's retrospective, Toyota's production-system development combined machines sized for actual volume, built-in quality checks, process-sequence layout, quick changeovers, and signals from downstream steps to upstream steps. This is an author interpretation of operating-system development, not proof that copying individual tools will produce the same cost, variety, quality, or throughput outcomes in another setting. ^[7]

Operator's Critical Insight: "Lead Time is the New Currency"

In traditional operations, managers focus on:

• Machine utilization (keep machines busy)
• Labor efficiency (minimize direct labor cost per unit)

VSM can show when these metrics are counterproductive under the stated demand and flow conditions:

• High utilization can increase WIP: Keeping machines "busy" can create overproduction and downstream waiting when release is not synchronized with demand.
• Large batches can lengthen lead times: Producing in big batches may increase local efficiency while increasing WIP and customer wait.

The decision focus: Reduce avoidable lead time when doing so improves customer value and system economics without harming safety, quality, workforce, supplier, or resilience outcomes. Inventory, cash, and responsiveness are hypotheses to measure, not automatic effects. ^[5]

So What for Managers

• Map material and information flow with actual demand, takt, WIP, cycle time, queue time, quality, rework, and customer-value definitions.
• Use the current state to test improvement hypotheses and the future state to assign owners, controls, measures, and staged experiments.
• Track lead time, WIP, service, quality, cash, workforce, supplier, and resilience effects rather than optimizing value-added ratio alone.

Limits and Critiques

• Value-added classifications depend on the customer, process boundary, regulatory work, safety, quality, and learning requirements.
• Author synthesis: A low process-time ratio is a diagnostic prompt, not a universal benchmark or proof that all waiting can be removed. ^[5]
• A VSM does not establish causality or guarantee improvement; implementation, measurement, ownership, and system interactions determine outcomes.

Connections

• Input: A VSM is a more advanced version of a Process Flow Diagram (Framework 1), adding data on wait times and information flows.
• Output: The future state map provides a detailed project plan for a Lean (Framework 2) transformation initiative.

Overview

A digital twin is a purpose-defined digital representation linked to a physical asset, process, or system across an identified lifecycle. ISO 23247-1 provides public metadata for terms, definitions, general principles, and requirements for a manufacturing digital-twin framework; it does not make the teaching architecture below an ISO reference architecture. A twin can support monitoring, simulation, or prediction, but fidelity, configuration, latency, measurement, uncertainty, security, human authority, and change control determine whether an output is fit for use. ^[12]

Visual: Digital Twin Architecture

Figure 6.12. Constructed digital-twin component architecture. Data does not flow directly into an autonomous operating change: configuration, validation, uncertainty, safety, security, authorization, and rollback govern the loop. ^[12]

flowchart LR
    P[Physical asset, process, or system] --> S[Sensors, events, and operating records]
    S --> Q[Quality, identity, time, and configuration controls]
    Q --> T[Versioned digital representation]
    T --> A[Simulation, estimation, or analytics]
    A --> O[Prediction or operating option with uncertainty]
    O --> G{Validated, safe, secure, and authorized?}
    G -->|No| R[Reject, redesign, recalibrate, or gather evidence]
    R --> T
    G -->|Yes| C[Stage change with monitoring and rollback]
    C --> P

Text equivalent: A physical asset or process produces sensor data that update a digital representation. Analytics may generate a failure-risk estimate, tested operating option, or other model output. Accountable owners must validate the data, model, uncertainty, safety, security, and operating guardrails before feeding any change back to the physical system.

Source note: Author-created teaching sketch informed by the locally cited digital-twin literature. ISO 23247-1 supports the existence and scope of a manufacturing digital-twin framework, not this exact architecture or its arrows. ^[12]

How to Apply

Step 1: Build the Virtual Model Define the decision and required fidelity before building the model:

• Manufacturing Line: Model each machine, buffer, conveyor, and constraint
• Product: Model the product's behavior under different conditions (temperature, stress, etc.)
• Supply Chain: Model inventory levels, transportation routes, supplier lead times

Tool boundary: Select tools only after architecture, validation, security, interoperability, ownership, and lifecycle requirements are defined.

Step 2: Integrate Real-Time Data Integrate the physical, transactional, event, or sensor data needed for the named decision; a sensor-heavy design is one option, not a default:

• Sensor Types: Temperature, vibration, pressure, flow rate, GPS location, power consumption, throughput
• Data Frequency: Match sampling, latency, storage, and synchronization to the physics and decision; faster is not automatically better.
• Constructed architecture option: Sensors → edge or local processing → cloud or on-premise representation → analytics and control interface. Select the deployment from latency, safety, security, interoperability, cost, and ownership requirements.

Step 3: Simulate & Optimize Use the digital twin to run bounded “what-if” scenarios without treating simulation as real-world validation:

Manufacturing Examples:

• "What happens if we increase production line speed by 10%?"
• "If Machine B goes down, where will the bottleneck shift?"
• "What's the optimal preventive maintenance schedule to minimize downtime?"

Supply Chain Examples:

• "If a high-concentration supplier becomes unavailable, what is the impact on service and recovery?"
• "What inventory levels minimize total cost (holding + stockout)?"

Step 4: Validate, Decide, and Control Change Validate the model for the intended decision, quantify uncertainty and failure modes, and keep accountable human authority over consequential operating changes.

Predictive Maintenance:

• Old approach: Fix machines when they break (reactive) or on a fixed schedule (preventive)
• Digital-twin approach: Analyze relevant condition and use data to estimate failure risk within a validated horizon.
• Decision: Compare inspection, maintenance, continued operation, shutdown, and evidence collection under safety and reliability rules.

Prescriptive Optimization:

• Example: The model compares bounded parameter combinations, then a controlled real-world test validates performance, energy, safety, quality, and equipment-life guardrails.

Figure 6.13. Governed digital-twin decision loop. Physical data can update a digital representation, but validation, uncertainty, security, human approval, staged change, and rollback sit between a model output and an operating action.

flowchart LR
    A[Physical Asset] --> B[Sensor Data]
    B --> C[Versioned Digital Representation]
    C --> D[Simulation]
    D --> E[Prediction or Option]
    E --> F[Validate Fidelity, Uncertainty, Safety, and Security]
    F --> G{Authorized Change?}
    G -->|Yes| H[Stage, Monitor, and Retain Rollback]
    G -->|No| I[Reject, Redesign, or Gather Evidence]
    H --> A
    I --> C

    style A fill:#4ecdc4
    style C fill:#ffd93d
    style F fill:#ffd93d
    style G fill:#ff6b6b
    style H fill:#95e1d3

Text equivalent: Sensor and operating data update a versioned digital representation. Simulation produces a prediction or option, which must pass fidelity, uncertainty, safety, and security validation. An authorized owner either stages the change with monitoring and rollback or rejects, redesigns, or gathers more evidence.

Source note: Author-created governance extension of the digital-twin concept. ISO 23247-1 is linked only for the published manufacturing-framework scope; it does not define this governance loop. ^[12]

Constructed Condition-Monitoring Example

A regulated asset operator uses a versioned digital representation to compare maintenance options. It validates sensor calibration, failure labels, prediction horizon, false-negative consequences, configuration, cybersecurity, human authority, and rollback before changing a maintenance plan. The example is illustrative and makes no claim about a named engine maker, sensor count, data volume, prediction, or savings.

Constructed Scope Taxonomy

The four labels below are an author-created teaching taxonomy, not a universal or standards-defined classification.

Table 6.6. Constructed digital-representation scope taxonomy. Actual terminology and scope must follow the governing standard, architecture, and use case.

Text equivalent: The teaching taxonomy distinguishes a component representation for one part, an asset representation for one machine, a system representation for interacting assets, and a process representation for an end-to-end workflow. Actual terminology and scope must follow the governing standard, architecture, and use case.

Operator's Practical Tip: Start Small

Don't try to build a digital twin of your entire operation on day 1. Start with:

1. Name the decision and owner: Define what action the representation may inform.
2. Choose a bounded scope: Select an asset or process where better evidence could change a material decision.
3. Validate value and risk: Compare the twin with simpler sensing, rules, simulation, inspection, or process-change alternatives.
4. Expand only with evidence: Require validated performance, lifecycle cost, interoperability, security, adoption, and residual-risk evidence.

Contrarian Thinking: Don't Twin Everything

• The Hype: Digital twin vendors will tell you to twin everything.
• The decision: A digital twin may be useful for:
  • High-value assets: Assets where downtime is extremely costly (e.g., jet engines, manufacturing lines)
  • Complex processes: Where simulation provides insights humans can't easily see
  • Regulated industries: Where you need to prove compliance (pharmaceuticals, aerospace)
• Prefer simpler methods: When observation, SPC, rules, conventional simulation, or process redesign provides sufficient evidence at lower lifecycle cost and risk.

Real-World Implementation Challenges

• Data quality: "Garbage in, garbage out." If your sensors are miscalibrated or your data is noisy, the twin will give bad predictions.
• Model fidelity: Building an accurate virtual model is hard. It requires deep process knowledge and iterative refinement.
• Change management: Operators must trust the twin's recommendations. This requires training and proving the twin's accuracy over time.
• Lifecycle economics: Include sensing, integration, validation, compute, security, model/configuration updates, people, downtime, vendor dependence, and retirement; do not use a universal cost range.

So What for Managers

• Name the decision, owner, scope, lifecycle, fidelity, data requirements, security boundary, and rollback condition before building a twin.
• Validate data, configuration, model performance, uncertainty, safety, cyber controls, and human authority before staging an operating change.
• Compare a twin with simpler sensing, rules, SPC, simulation, inspection, or process redesign and expand only when evidence justifies lifecycle cost.

Limits and Critiques

• ISO 23247-1 provides a manufacturing framework scope; it does not validate this chapter's architecture, arrows, predictions, safety, security, or economic value.
• Fidelity, latency, data quality, configuration drift, model error, cyber exposure, adoption, and retirement cost can dominate technical promise.
• A digital representation cannot replace physical evidence, approved controls, accountable authority, or a monitored rollback path.

Connections

• Input: The creation of a digital twin requires a detailed Process Flow Diagram (Framework 1) and data from Operations.
• Output: Validated insights may inform capacity and SPC decisions; the twin does not replace physical evidence, approved control plans, or accountable operating authority.