Your automation RFP needs more than ‘we need more capacity’

‘More capacity’ is often where an automation conversation starts. But what is the supplier supposed to design from that? A Request for Proposal (RFP) asks integrators to propose and price a solution against your requirements.

An integrator can design cranes, conveyors, shuttles, racking, controls and software interfaces. The operator has to decide whether one customer’s order takes priority, who can release stock on hold and how late a truck may leave. The technical solution has to execute those decisions.

An operating concept puts them on paper: the business rules, the scenarios the operation must handle, the processes from receiving to dispatch and the timeline for the work. That gives the integrator something to design against.

Take an illustrative operation that dispatches 1,200 pallets per day. Spread evenly across 24 hours, that is 50 pallets per hour. If 60% must leave within two hours, the operation needs to handle 360 pallets per hour during that window. The daily total has not changed. The design requirement has.

Does inbound continue during that dispatch window? What load sequence must the pallets follow? Which stock is eligible for release? Does replenishment use the same buffer or transport route? What happens when an urgent order arrives after the wave has begun?

Those answers belong in the RFP’s functional and performance requirements before the supplier starts to dimension the solution.

Business rules define the decisions the operation must make consistently. In cold storage, that may include FEFO allocation by best-before date, customer-specific shelf-life requirements, authority to release stock from a quality or temperature hold, order priority, load sequence, cut-off times and conditions for accepting late orders.

These rules determine what the WMS needs to do. If the business has not agreed them, someone will fill the gap during configuration: a project team member, an implementation consultant or a shift lead trying to keep work moving. Later, the assumption is difficult to find. It has become a setting or a work-around.

A useful rule has an owner and a reason. ‘Priority customer’ is not enough. Which orders take precedence, under which conditions, and who can override the sequence? What happens when two rules conflict?

Start with the rules that affect capacity, service, stock integrity, safety or the business case.

Work through the normal day, a peak, a planned change and the exceptions that could have serious consequences. These establish the conditions under which the design must perform.

For a pallet operation, that could mean a late inbound delivery during an outbound peak, a missing ASN at receiving, an unreadable SSCC label, an urgent order after replenishment has started, a temperature deviation that puts stock on hold, or an equipment fault near a customer cut-off.

Describe what triggers each scenario, which work must continue, who decides, what information is needed, the time available and the acceptable result. ‘Late delivery’ as a scenario title tells the designer too little.

The operator knows which customer commitment or process is at risk. The integrator can show what that means at a conveyor merge point, storage interface or buffer. They need to work through the same scenario.

Fraunhofer IML approaches material-flow planning through processes, technology, logistics IT and people. It translates operational data into specifications and support for tendering and implementation. That requires decisions from both the operator and the designer.

Follow product and information through the warehouse. Inbound may start with the ASN and an appointment, then cover receipt, identification, physical checks, reject handling, receipt confirmation, stock status and putaway. Outbound may cover allocation, release, retrieval, staging, load sequence, loading, shipment confirmation and gate-out.

Show where an instruction comes from, who owns the next decision, which system holds the state and where a physical hand-off occurs.

The WMS holds inventory, order, customer and warehouse-process rules. The WCS releases, sequences, routes and balances work through automation. The PLC and control layer execute safe machine movement. The equipment moves, stores, detects or buffers the pallet.

That distinction helps during a stoppage. Is the pallet unavailable because of a stock-status hold in the WMS? Is the WCS holding back a task because of a sequence rule? Is the control layer reporting a physical fault? The answer determines who needs to act and what they need to do it.

Customer requirements for load sequence, labels, pallet type and release authority are easy to overlook in a general flowchart. They can determine whether a pallet is ready to ship on time.

A process map shows that receiving, replenishment and dispatch exist. The timeline shows when they need the same people, equipment, buffer or route.

For the 1,200-pallet example, the integrator needs the hour-by-hour profile, departure windows, release rules, order mix, shift handovers and exceptions that use the same resources.

Include when decisions have to be made. Releasing stock at 07:00 has a different consequence from the same release at 16:30, five minutes before a planned departure. The same applies to an ASN correction, quality check, replenishment or equipment recovery.

Use that timeline in capacity calculations, staffing plans and acceptance tests. Check which activities must run at the same time.

The operating concept supplies the functional and performance requirements for the RFP: demand and product data with their gaps and assumptions; rules for allocation, release, service and exceptions; and scenarios for normal, peak and disrupted conditions.

Include process maps that distinguish operating decisions, information flows and physical flow. Add the time profile, including cut-offs, concurrent activities and shared constraints.

Make clear which decisions are agreed, which still need validation and who owns them. Include the acceptance criteria users will need to test the future operation in UAT.

Leave room for the integrator to challenge those inputs. A good integrator asks for better data, exposes constraints and shows the technical consequences of an operating choice. The operator still needs to approve that choice.

VDI 2519 describes how tender and performance specifications establish technical and economic requirements for material-flow and automation systems. They give operators, planners and manufacturers a common basis for their work.

Take the concept to the people who will run the warehouse before the configuration is fixed. Shift leads, planners, quality, customer service and maintenance need to walk through the scenarios.

Does the sequence reflect the work? Which rule breaks when a truck is late, stock is blocked, a label cannot be read or the dispatch window changes? Record a decision, a changed scenario or an open point with an owner. ‘We will work it out during go-live’ leaves the choice unresolved.

Use the same scenarios in acceptance. FAT tests equipment or software against its specification in a controlled setting. SIT tests the interfaces. SAT tests the installed solution in the building. In UAT, users test whether they can execute their operating scenarios. The concept supplies the scenarios and expected outcomes.

A project can reach technical acceptance while an important business rule still has no owner. The choice then falls to the shift that has to work with it.

I see a clear role here for client-side support: work through the operating decisions with the operator and turn them into agreed requirements for the RFP.

I would build that assignment in four steps. First, understand the current operation: review the data, observe the work and establish the customer commitments, rules and decisions that determine flow. Then define the normal, peak and exception scenarios for the future operation.

Next, test the rules, timelines and process assumptions with the people who will use them. Finally, hand the integrator the validated scenarios, requirements, assumptions, open decisions and acceptance criteria.

Some sites need a focused concept review. Others need a fuller material-flow, process and requirements exercise. In either case, the operating decisions need to be visible while the technical design can still respond.

Can we explain, in writing, what the future warehouse must do on a peak day, who makes the operating decisions and when they need to happen?