What a Rigorous Automation Assessment Actually Looks Like

Before committing capital to an automation project, the quality of the scoping assessment will determine whether the project delivers its business case. This is what separates an assessment that produces a reliable investment decision from one that produces a credible-looking proposal.

An automation proposal is not an assessment. It is a sales document that describes a proposed solution. A genuine assessment is the work that determines whether that solution will actually solve your problem. Understanding the difference between the two is the most valuable thing an engineering manager or procurement manager can do before committing capital to an automation project.

What Most Proposals Miss (and Why)

Most automation proposals are written from the supplier's perspective. They describe the system being sold, its specifications, its capabilities, and its price. What they frequently do not describe is a rigorous analysis of the production problem being solved, the assumptions underlying the throughput and ROI projections, the integration costs, the full commissioning scope, and the ongoing support obligations.

This is not always dishonest. Suppliers often write proposals based on a brief site visit or a conversation with one person on site, because that is all the access they were given. The responsibility for demanding a more thorough assessment before issuing a request for proposal sits with the buyer. A supplier who is asked for a thorough assessment and declines to provide one is telling you something important about how they approach project delivery.

The Eight Components of a Rigorous Site Assessment

1. Current-state process documentation

A floor walk is not sufficient. A rigorous assessment documents the current process with cycle time measurements (stopwatch studies at every station, across multiple operators and shifts), current OEE data (availability, performance, quality losses separately), shift patterns, product variant details (every SKU the automated system must handle, not just the highest-volume one), and the interface points with upstream and downstream equipment.

2. Constraint identification

Before specifying a solution, the assessment should clearly identify where the system constraint sits and confirm that the proposed automation directly addresses it. If the proposal does not include a constraint analysis, the throughput projections cannot be validated.

3. Integration mapping

Every interface between the proposed automation and your existing systems must be documented: upstream and downstream equipment interfaces (timing, interlocking, product handoff), PLC communications (EtherNet/IP, Profinet, Modbus, OPC-UA), SCADA and historian connections, ERP or WMS integration for production reporting, safety circuit integration, and utilities (compressed air, electrical supply, network). Integration costs are frequently the most underscoped element of an automation project.

4. Product variant handling analysis

Every product variant that will run through the automated system should be assessed individually. For a robot pick and place application, this means gripper compatibility with each SKU's packaging, weight, surface finish, and dimensional tolerances. For a conveyor system, it means confirming that every carton size and pack configuration will convey, orient, and transfer reliably. Problems discovered after commissioning with product variants that were not assessed cost far more to resolve than problems identified during the design phase.

5. Risk and sensitivity analysis on the ROI model

The ROI model in an automation proposal should include a sensitivity analysis showing how payback period changes under realistic downside assumptions. What is payback if throughput improvement is 80 percent of projected? What if changeover time takes 50 percent longer than the target? What if two additional product variants need to be handled within 12 months? A supplier who presents only the upside scenario in their ROI model is either optimistic or not being fully transparent.

6. FAT and SAT scope definition

Factory Acceptance Testing (FAT) validates the system at the supplier's facility before shipment, typically using production-representative product samples. Site Acceptance Testing (SAT) validates the system at your facility under production conditions. Both should be described explicitly in the project scope with acceptance criteria that are measurable and agreed before the project starts. Projects without defined FAT and SAT criteria frequently have disputes at handover about whether the system meets its specification.

7. Commissioning timeline with production impact analysis

The commissioning schedule should show the specific periods when production will be unavailable and the production volumes lost. For an operating facility, this is as important as the total project cost. A supplier who says "we will work around your production schedule" without a specific methodology for doing so has not planned the commissioning.

8. Post-commissioning support obligations

The proposal should specify: who owns the program code and documentation at project completion (it should be you), what the response time and availability commitment for technical support is, what the scope of any warranty period covers (software faults versus hardware failures versus integration issues), and what happens if the system fails to achieve its performance targets after commissioning.

Red Flags in Automation Proposals

• Throughput projections based on rated machine speed rather than demonstrated production speed with your product range.
• Integration described as "standard" or "straightforward" without a specific interface description. No interface is standard until it has been designed.
• Commissioning timeline with no defined shutdown windows or a single item called "site installation" covering 4 or more weeks.
• ROI calculation that uses a fully-burdened labour cost significantly above market rate to make the payback look better.
• No mention of FAT or SAT, or FAT and SAT defined as attendance at a single demonstration rather than a structured acceptance test against agreed criteria.
• Program code described as "proprietary" or "confidential" rather than handed over with documentation at project completion.
• Reference sites that are in a different country, significantly different scale, or for a different application to yours.

Questions That Reveal Proposal Quality

When evaluating competing proposals, these questions reliably differentiate suppliers who have done the engineering work from those who have not.

• "Can you show me the time study data that your throughput projection is based on?" If they do not have one, the projection is an assumption.
• "What is the cycle time for our slowest SKU through this system, and how does that compare to our takt time?" If they cannot answer for all SKUs, product variant analysis is incomplete.
• "Who owns the program code at project completion, and will you hand over source files and structured documentation in IEC 61131-3 format?" The answer should be you own it, unambiguously.
• "What is your response to a critical system failure outside business hours?" The answer should include a specific response time commitment, not a general statement about availability.
• "Can we speak with a reference customer whose application is similar to ours, in Australia?" References from similar Australian applications are a strong quality signal.