7. Automation Decisions at Concept Stage
Tuesday, 2:20 p.m., concept review wrapped an hour ago, the enclosure geometry locked and the probe-access question never raised.
The design review celebrates fit, function, and cost.
Six months later, the line cannot probe one critical node without custom fixture workarounds that add 40 seconds per unit and destabilize yield.
Nothing is "wrong" with the product design. The automation path was never designed into it.
The automation decision belongs at concept stage, where the per-unit test cost can still change the design.
The core mistake
Teams treat automation as a downstream implementation problem.
It is not. Automation viability is set by concept-stage choices:
- access geometry,
- datum strategy,
- tolerance and stack assumptions,
- test point location,
- part presentation.
Delay those decisions and the program pays in cycle time, scrap, and heroic workaround engineering.
On one actuator program — at concept stage, before geometry was locked — the concept team chose recessed test-pad geometry to save enclosure space. At ramp, that choice forced a manual probing station between ICT and final test and added 52 seconds per unit. At 10,000 units per month, 52 seconds per unit added 144 hours of test-floor time; when the team attempted to automate after tooling was fixed, fixture redesign consumed six additional weeks. - Old process: geometry locked without a probe-access check; no automation path review at concept.
- Artifact changed: a mandatory concept-stage automation review added to the Phase 1 gate, requiring each critical characteristic mapped to a physical probe strategy before geometry froze.
- Measured improvement: on the following program, the same class of pad access conflict was caught in week two of concept and resolved with a geometry adjustment before tooling; no manual station appeared in that line plan.
- Cost of the gap: 52 seconds per unit added permanently to the line, plus six weeks of fixture redesign after tooling was already fixed.
That account is the mechanism in miniature: per-unit seconds scaled to monthly floor demand — arithmetic to own at concept while geometry and tooling still trade, not after ramp turns it into a permanent line tax.
Concept-stage questions that prevent late pain
Before concept closes, settle targets on:
- What critical characteristics must be measured in production?
- How will each be accessed physically?
- Throughput envelope — order-of-magnitude cycle-time / rate that the line family must sustain (fine station-cycle budgeting comes after functioning prototype builds, before a test production run).
- What data must be captured per unit for release and field learning?
- Which steps are manual at launch and automatable later?
If these targets are unset or fuzzy, automation is already a schedule and yield risk.
Minimum design-to-automation handoff
You do not need full line design at concept stage.
You do need a minimum handoff package:
- current concept geometry and tolerance assumptions,
- critical-characteristics list,
- preliminary test strategy,
- target cycle-time envelope,
- traceability/data requirements,
- open risks and decision dates.
This lets automation, manufacturing, and test challenge assumptions while change is still cheap.
Failure signature of late automation
Late automation programs show the same signs:
- fixtures become product redesign proxies,
- cycle-time misses are "discovered" at ramp,
- manual rework stations become permanent,
- data needed for root-cause is unavailable or too noisy.
The debt is technical and usually gets masked as "we need to keep ramp moving."
What to do if you are already late
If concept is over, you still have levers:
- Identify top three throughput/yield constraints driven by design-for-automation misses.
- Classify each as design change, fixture change, or process workaround.
- Quantify cost of each workaround in cycle time and yield impact.
- Escalate one design change if workaround cost exceeds threshold.
- Capture lessons as mandatory inputs for the next concept phase.
Use triage outputs to decide this program — design changes, fixtures, workarounds, and what ships. Treat the systemic lessons from that work as binding inputs for the next concept on the next program (or major platform refresh), so the same class of geometry miss is expensive once across the portfolio, not twice.
Automation is a decision-quality topic
Automation arguments are often miscast as tooling brand or robotics preference.
The sharper failure mode is sequencing: “automation last” pushes someone toward line and casting-level commitments before product geometry, packaging, presentation, conveyance, fixture points, or tolerance envelopes are settled — then the conversation is improvised and brittle. Decide automation when those edges are treated as known inputs — e.g., can this geometry be self-centered and probed reliably on this datum — and the residual question is narrower.
Under that sequencing failure, what looks like a tooling fight is usually requirement and ownership failure:
- unclear measurable targets,
- late closure on critical characteristics,
- no owner for integrating design/test/manufacturing constraints.
Treat automation as part of the operating system and it becomes predictable. Treat it as "integration detail" and it becomes late-stage volatility.
If the test coverage plan for your current program includes unit counts, cost per unit, and a pass/fail threshold for automation — and that calculation was done before the concept was locked — the decision was made at the right time. If the test coverage is still 'TBD at D-phase,' the decision is already late.