Observe a Manufacturing Handoff Before Designing Software

Observe one job crossing a department boundary before designing a new workflow. Record when it is ready, when the next person can act, what information is missing and how the receiver recognises completion. Keep observed events separate from explanations you have not tested.

A software builder sees a queue outside inspection and proposes a dashboard. The queue alone cannot explain whether the cause is a missing request, unavailable gauge, priority conflict or an inspector already working on another job. A short, agreed observation can establish what a useful requirement must address.

Choose a handoff and define its boundaries

Select one repeatable transfer, such as production requesting inspection or stores receiving a material request. Agree the observation with the responsible people, follow site access rules and avoid interrupting hazardous work. Define the start as the sender having completed the required preparation, and the end as the receiver accepting the work or identifying a specific block.

Bring the current request form, job identity, required inputs and relevant status definitions. Ask both roles what “ready” means. The Lean Enterprise Institute describes a gemba walk as direct observation and inquiry where work occurs. Use that principle to investigate this one transfer, rather than inferring the whole factory from a tour.

Write events before explanations

The elapsed handoff is 15 minutes, from 09:10 to 09:25. The documented clarification interval is eight minutes, from 09:14 to 09:22. Do not label the remaining seven minutes as waste or claim a 15-minute saving. The observation does not establish what other necessary work occurred during those intervals.

Capture the actual record identifiers and statements needed to resolve the question. Avoid copying unrelated customer details or private messages into a discovery document. Where photography is allowed, show the work condition and protect information that is not needed for the analysis.

Ask both sides to review the account

Replay the event sequence with the sender and receiver. Ask whether the tray was genuinely ready at 09:10, whether the revision was available elsewhere, and whether the receiver could accept the work without it. Correct your notes when their evidence changes the interpretation. A disagreement is a research question to resolve, not a reason to choose the more senior explanation.

Observe additional examples across the conditions that may change the handoff: another shift, urgent work or an incomplete request. State how many examples were observed and what was excluded. A small observation set can expose a design problem; it cannot establish a factory-wide average or prove its cause.

Write a requirement with a falsifiable check

For the illustrative case, a candidate requirement is: “The inspection request identifies the current drawing revision before the receiver accepts it.” The acceptance check uses a complete request, a missing-revision request and a corrected request. Record the permitted next action, responsible role and retained history for each. If the missing revision is intentional for a valid work type, define that exception instead of forcing irrelevant data.

After a controlled pilot, compare the same handoff definition and operating conditions. Retain counts of clarification requests and observed intervals, including unsuccessful cases. Decide whether the change helped the receiver act correctly; faster entry alone does not establish a better handoff.

Configure the observed workflow

Our Optiwise forms and custom modules support operational fields and attachments. Use them to configure the agreed request and review record around your production process. The discovery notes should explain why each field exists and who uses it, so future changes do not recreate the ambiguity.

Observation questions

How many observations are enough?

Enough to investigate the stated design question across relevant conditions. Report the actual sample and limitations; use a larger planned study before estimating representative performance.

Should we begin by asking users which screen they want?

Ask what decision they need to make and observe the information they use. A screen proposal becomes useful once the task and its exceptions are understood.

Bring one observed handoff and its open questions to a workflow demo.