The purpose of a pilot
A pilot is a defined, time-limited engagement designed to answer a specific question about a real operational situation. That question is not "can this technology work in principle?" It is "does addressing this specific problem, in this specific context, produce a measurable and useful result?"
The distinction matters. Technology demonstrations show capability under controlled conditions. Pilots show whether a problem is real, whether the proposed approach addresses it, and whether the result justifies further investment.
What makes a pilot narrow enough to be useful
The most common failure mode for operational pilots is scope creep before the first result is produced. A pilot that begins with "let's understand what's happening on the production floor" is not a pilot — it is an open-ended investigation with no defined endpoint or decision criteria.
A useful pilot starts from:
A specific problem statement. Not "we want better visibility" but "we believe we are losing 8–10% capacity on Line B to events that do not appear in our downtime reports."
A defined scope. One line. One machine area. One shift team. The narrower the scope, the cleaner the result.
A clear success criterion. What would the pilot need to show for you to say it worked? If the answer is "we'll know when we see it," the pilot is not well-defined.
A defined duration. Two weeks. Four weeks. A specific endpoint, not "until we're satisfied."
What a pilot should produce
A well-run pilot produces three things:
A finding. What actually happened, in operational terms. Not a dashboard or a report — a specific statement about the problem that was investigated.
Evidence for or against the hypothesis. Did the problem exist as described? Was the proposed approach effective? Was the result of the scale that justified further investment?
A decision basis. The pilot should make a specific question answerable: expand, modify, or stop. If the pilot cannot produce this, it was not scoped tightly enough.
What a pilot is not
A pilot is not a commitment to build a system. It is not a proof that a system is needed. It is not a vendor demonstration on your own data.
It is also not a guarantee of a positive result — and that is the point. A pilot that shows the problem is not as significant as assumed, or that the proposed approach does not produce useful results in this context, is a successful pilot. It prevented an investment that would have failed.
The discipline of running narrow pilots is precisely the discipline of being willing to accept a negative result and act on it — rather than finding a way to interpret ambiguous results as confirmation.
The expansion question
If a pilot produces a clear positive finding, the natural question is: where does this go next?
The answer should follow the same logic as the original pilot: narrow scope, specific hypothesis, defined evidence. The next step is not "roll this out across all lines" — it is "apply the same approach to Line C, where we have reason to believe a similar pattern exists."
Scale follows evidence. Evidence comes from narrow, well-defined engagements. This is the whole model.
---
This is how Advisource structures every engagement: one line, one problem, a short pilot, a clear finding. Expansion only if the evidence supports it.