Few indicators recur as frequently in industrial automation as the failure rate of machine vision projects. Most do not reach production. Open conversation in technical committees typically centres on adjustments to camera, algorithm or lighting, but analysis of root causes suggests that the problem, almost always, is not technical.
The root cause points to the phase preceding the PoC. The client knows that something needs to be inspected, measured or identified, but rarely has articulated with precision the tolerances, the edge cases, the actual line conditions or the part variables. The incomplete definition reaches the laboratory and, once in testing, no technical configuration can recover what the specification failed to capture.
The second pattern that recurs in closed projects is subsequent rescoping. A significant proportion of apparently successful PoCs do not scale to production in line with the client's initial expectations. The line introduces variability that the test scenario did not replicate. The system works in the laboratory and begins to fail when transferred to the plant.
Technical scoping identifies which hardware, which algorithm and which configuration solve a given task. Commercial scoping identifies, beforehand, whether the task is properly framed. These are distinct disciplines, require distinct capabilities and, in most medium-sized organisations in the sector, fall upon the same profiles, who execute them asymmetrically.
The pattern among suppliers that close projects is the opposite. Before the PoC they dedicate application engineering time to walking the line with the client, to documenting real samples under real conditions and to drafting the specification jointly. That phase, rarely invoiced, decides whether the PoC will validate product or be used as an excuse to abandon the project.
Three components define a system that performs measurably. Protected application engineering time dedicated to the client before the PoC. Physical capture of real samples under real conditions, with characterisation of expected variation, not average variation. And joint drafting of the specification, signed by client and supplier, with edge cases and acceptance criteria for production.
The frequent error consists in treating the scoping phase as unrecoverable expense and minimising it. The aggregate arithmetic contradicts that logic. A failed PoC damages the relationship with the client, consumes internal engineering time and hinders the next sale. Five additional hours of scoping save fifty of rework.
The consequences are threefold. The allocation of application engineering time must extend to the pre-PoC phase, with explicit criteria regarding which projects merit it. The commercial team requires technical capability to reframe the client's problem, not merely to describe the product. And the commercial scorecard requires a specific indicator of scoping quality, distinct from the indicator of closure and invoicing.
The usual objection is that the client will not accept paying for the definition phase. The objection is accurate and is resolved with judgement. What the client pays for is the final result, not the hours. The supplier who captures the correct specification captures the operation. The one who does not loses the PoC and, with it, the project.
The observed failure rate describes a growth leakage that the market has accepted as inevitable. It is not. It is a specific, identifiable and correctable commercial method problem. The company that decides to treat it as such opens a competitive asymmetry over those who continue to interpret it as a technical problem.