A readiness assessment should expose the conditions that could weaken an automation project before capital is committed. It is a decision gate, not a scorecard designed to make every opportunity look acceptable.
A promising concept can still fail when part presentation varies, ownership is unclear, fault recovery depends on one person or the business case assumes every saved minute becomes usable capacity. These are not small implementation details. They determine whether the proposed result can survive normal production.
Use the twelve questions below with operators, maintenance, quality, engineering, safety, planning and finance. Record the evidence behind each answer, the remaining uncertainty and the person responsible for closing it.
Start with the operating need
What recurring loss are we trying to change? State where the loss occurs, how often it occurs and whether it affects safety, quality, delivery, cost, capacity or responsiveness.
Is the baseline reliable enough to judge improvement? Confirm the measurement rule, time period, product mix and data source. If teams calculate the loss differently, align the definition first.
Is automation the simplest credible intervention? Compare standard work, fixtures, poka-yoke, layout, sensing, guided work and maintenance restoration before selecting a more complex route.
A project is not ready because a solution exists. It is ready when the problem, evidence and acceptance conditions are sufficiently clear to make a responsible commitment.
Test process stability
Is the current method defined and repeatable? Observe different shifts, operators and product variants. Automation applied to an unstable method can reproduce variation faster and make recovery harder.
Are inputs and interfaces controlled? Check material condition, orientation, tolerances, tooling, utilities, upstream flow, downstream capacity and the information needed to release work.
Do we understand exceptions and recovery? List jams, missing parts, quality holds, rework, changeovers, power interruptions and abnormal stops. Define how each condition will be detected and safely recovered.
Do not average away the difficult conditions. The rare product variant, damaged container or awkward restart may carry more project risk than the normal automatic cycle. Readiness improves when these conditions are designed into the requirement rather than left for commissioning.
Confirm technical and safety conditions
Are the technical interfaces understood? Document controls, signals, mechanical interfaces, network access, data ownership, space, environment and utility requirements.
Have safety and compliance needs shaped the concept? Identify hazards, access requirements, safeguarding principles, validation responsibilities and changes to operating or maintenance work.
Can the site support the solution through its life? Assess diagnostic access, documentation, critical spares, vendor response, software backups and the skills required for routine maintenance and fault finding.
A technically impressive proposal is weak if the factory cannot restore production after a common fault. Ask suppliers to demonstrate recovery, not only the normal cycle, and make supportability part of technical acceptance.
Verify ownership and economics
Is there one accountable business owner? Name the person responsible for the operating result, cross-functional decisions, resource availability and benefits after handover.
Does the business case include the whole change? Include engineering, integration, guarding, infrastructure, training, production disruption, ramp-up, maintenance, software and realistic residual labour.
Are acceptance criteria agreed before purchase? Define representative products, cycle and quality requirements, availability, changeover, fault recovery, data integrity, documentation, training and the period used to confirm sustained performance.
Turn answers into a decision
Classify each question as evidenced, partly evidenced or unresolved. Avoid compressing the result into one attractive percentage. A single unresolved safety, process-interface or ownership condition can stop a project even when the overall score appears high.
- Proceed: the critical conditions are evidenced and the remaining actions have owners, dates and acceptance evidence.
- Validate: the opportunity remains attractive, but a bounded trial or study is needed to test the assumptions that could change the decision.
- Stabilise first: process variation, measurement, maintenance or ownership must improve before automation design continues.
- Stop: the operating need is weak, a simpler intervention is preferable or the support burden cannot be justified.
Revisit readiness after the concept changes and before final acceptance. Readiness is not a workshop completed at the start; it is the discipline of keeping the investment connected to the conditions required for success.