Lean Fundamentals
How to Collect Value-stream Data: Make the Current-state Map a Verifiable Improvement Baseline
The direct answer for value-stream data collection is to select a product family and start/end boundaries first, record cycle time, changeover, available time, work in process, quality and batching rules along material and information flows, and then calibrate system data with shop-floor observation. A value-stream map is not an MES report drawn as a flowchart. It explains how demand triggers production, where materials wait, where information becomes distorted, and which losses belong in future-state design.
Select the Product Family and Boundaries First Instead of Mapping the Whole Plant
A product family should share similar process routes and demand characteristics that can be analyzed together. Start and end boundaries may run from supplier to customer or initially focus on a controllable segment inside the plant. Wider boundaries do not automatically create more value; if data ownership and improvement authority lie outside the scope, the map becomes merely a complex display.
Demand definitions must also be consistent, including customer demand, shipment pace, planned batch size and shift calendar. Without common time units, cycle times, inventory and demand cannot be compared on one value stream.
| Scope element | What must be confirmed | Common deviation | Correction method |
|---|---|---|---|
| Product family | Process route, critical equipment and demand similarity | Averaging highly dissimilar products together | Stratify first, then decide whether consolidation is valid |
| Start and end boundaries | Which event starts the stream and which ends it | Omitting external waiting or internal rework | Mark boundaries and list external interfaces separately |
| Time window | Representative period, shift, season and abnormality context | Selecting only the smoothest day | Observe multiple windows and retain context |
| Demand definition | Customer or downstream demand and pace | Substituting upstream released quantity for real demand | Distinguish demand, plan and actual output |
| Time unit | Conversion rules among seconds, minutes, shifts and days | Adding inventory days directly to processing cycle time | Unify units and explain the working calendar |
Process Data Boxes Must Serve Flow Analysis
Common data boxes include processing cycle time, changeover time, equipment or labor availability, batch size, yield and operators, but more fields are not automatically better. Fields should explain the main questions for the stream, such as whether waiting comes from changeovers, failures, batching or information triggers.
Processing cycle time must distinguish manual work, automatic equipment running and whole-batch processing. Yield must distinguish first-pass yield from final good output. If a rework route returns to an earlier operation, show thereturn flow outside the main map; otherwise, total labor and work in process will both be underestimated.
| Data item | Recommended definition | Shop-floor verification | Misuse risk |
|---|---|---|---|
| Processing cycle time | Record per-unit, per-batch, equipment and manual cycles separately | Observe repeatedly and distinguish products and states | Using the fastest run as the standard for every product |
| Changeover time | Record using consistent changeover boundaries and product combinations | Break down preparation, removal/installation, first piece and recovery | Taking only the equipment-stop segment and omitting startup losses |
| Availability | Combine the planned calendar, downtime and speed definitions | Compare equipment events with shift reports | Using calendar time to conceal planning differences |
| Quality | Define first pass, rework and final disposition separately | Trace the creating workstation andreturn flow | Using only final inspection to conceal process defects |
| Batch size and buffers | Separate transfer batch, production batch and normal buffers | Observe physical flow and waiting | Treating average book inventory as actual inventory at every moment |
Shop-floor Measurement and System Data Must Calibrate Each Other
Shop-floor observation reveals waiting, transportation, temporary storage and rework that systems do not record, while system data provides events, cycles and lot changes over longer windows. The two should validate each other rather than competing over which is inherently more accurate.
If the system shows equipment running while the shop floor is waiting for the downstream process, status mapping may be incomplete. If one field measurement differs from a long-term system average, product or operating conditions may differ. Check definitions and samples first, then decide whether additional collection or correction is needed.
| Information source | Strength | Limitation | Suitable use |
|---|---|---|---|
| Shop-floor timing and walk-throughs | Reveals actual motions, waiting and temporary flows | Limited window and influenced by observation conditions | Validate process relationships and typical abnormalities |
| SCADA equipment events | Provides continuous status, cycle and process times | Business semantics and planned boundaries may be insufficient | Calibrate downtime, cycles and equipment availability |
| MES station transactions and work orders | Clarifies identity, batch size, execution and rework relationships | Depends on scanning and workflow-execution discipline | Analyze WIP, flow and routing |
| Warehouse and enterprise reports | Provides relatively complete inventory, demand, order and master data | Time granularity and shop-floor status may differ | Establish demand, inventory and planning context |
| Team and functional interviews | Explains rules, exceptions and responsibilities | Memory and perspective may introduce bias | Form information-flow hypotheses for validation |
WIP and Information Flow Determine Whether the Map Can Explain Waiting
Work in process is not only in warehouses. Equipment-side queues, inspection-awaiting areas, rework areas and unscanned temporary queues can all create waiting. Records should identify quantity, identity, status, lot age and conditions for the next step; book-to-physical discrepancies are themselves problems to validate.
Information flow should show how demand becomes a plan, how the plan becomes a work order, how the order triggers material issue and completion reporting, and how abnormalities feed back. Focus on duplicate entry, verbal rush orders, batch aggregation and information delays because these mechanisms can directly drive overproduction and inventory.
- Follow the physical item: record every stop, transfer, split, merge and identity change.
- Follow the order: record responsibility for demand, scheduling, release, change, completion and feedback.
- Follow the abnormality: record how quality, equipment or shortage information changes the original plan.
- Mark time: distinguish processing, waiting, transportation and information delay rather than combining them into one total cycle.
- Mark unknowns: put book-to-physical discrepancies and missing data on a validation list instead of filling them from experience.
From Current State to Future State, Change Mechanisms Before Automating
Future-state design commonly addresses demand pace, continuous flow, pull, leveling and information triggers, but choices must respect process, quality and supply constraints. Necessary buffers cannot simply be removed to make inventory disappear from the map, and every manual step cannot automatically become an automatic collection point.
Digital priorities should target confirmed mechanisms. If work-order status is unclear, improve execution and interfaces. If equipment minor stops are invisible, add state acquisition. If planning rules cause overproduction, adding dashboards alone will not eliminate the root cause.
- Identify critical constraints: select the main mechanisms affecting delivery, flow or quality.
- Design target rules: specify what demand will trigger future work and which batch sizes and buffers will apply.
- Assess prerequisites: check whether equipment, process, supply, quality and workforce capabilities support the design.
- Pilot on a small scale: validate within a clearly bounded product family instead of switching the whole plant directly.
- Then define system scope: use validated rules to determine MES, SCADA, Andon or interface requirements.
Make the Value-stream Map a Versioned Improvement Baseline
A value-stream map should record the product family, time window, data sources, definitions and mapping owner. Critical data must be reviewed after significant process, demand or equipment changes rather than treating an old map as permanently true.
Improvement validation recollects critical data using the same definitions and checks whether losses have moved. For example, does less local waiting create an upstream backlog, or does a shorter cycle introduce quality or energy abnormalities? Public content uses only approved anonymous information and does not display customer-site maps, interfaces or sensitive parameters.
- Retain the time window and sample context for every current-state map.
- Record the source, definition and measurement or extraction method for every critical data item.
- Link every future-state action to its baseline, owner, validation window and unresolved issues.
- Review flow, quality, equipment and workforce effects together to avoid single-metric optimization.
Map Real Flow First, Then Decide on Data and Systems
The essence of value-stream data is not field completeness, but explaining processing, waiting, inventory and information triggers for one product family, demand basis and time boundary. Shop-floor observation and system data must calibrate each other to create a reviewable current-state baseline.
Future-state work should design flow and information mechanisms before defining digital acquisition and interface scope. Retain versions, samples and improvement validation so the map evolves with the facts, turning a one-time mapping exercise into a sustained cross-functional improvement tool.
Frequently asked questions
Can a value-stream map be created without MES or SCADA?
Yes. Shop-floor observation, timing, inventory counts and order tracking can establish the current-state map. System data is useful for expanding the window and continuous validation, but it cannot replace observation of actual material and information flows.
Is it enough to use averages for cycle time and inventory?
No. Averages hide differences among products, shifts and abnormalities. Retain distributions, ranges and sample context. Value-stream analysis must pay particular attention to how waiting and variation arise.
Is a value-stream map better when it covers more of the plant?
No. Scope should serve a clear product family and improvement problem. Excessive breadth introduces uncontrollable interfaces and averaged data. Close the loop within a controllable boundary first, then expand.
Is a value-stream map the same as a digital twin?
No. A value-stream map focuses on lean analysis of materials, information and time, while a digital twin typically emphasizes a dynamic representation of a physical object. They can share data, but their purposes, models and delivery scopes differ.
