In this week's article, in the series from members of the Automated Material Handling Systems Association (AMHSA), David Hayward-Browne, Director of Logistics Planning Consultants International (LPC), considers one of the key requirements when procuring an automated system: the use of Requirement Specifications within the project process and their benefits. LPC is a consultancy that has extensive experience in helping companies automate and run their operations.
A successful automated or mechanised project requires a lot of things before somebody “cuts metal” or turns up on site. The process includes tenders and quotations, contracts, designs and plans and programmes, but at the very start is the user requirement. You can consider the starting point of a project to be when a client says “I want to get…”, or “I want to install…” etc. The user requirement specification is where the want is described.
The first point to remember is that unless your project is very simple, you are not buying a product with a pre-defined specification, you are buying a system made up of a number of components such as shuttles, mini loads, conveyors, control systems etc. with the specification and performance agreed between you and the supplier.
There is a very wide range of equipment and systems available when looking at automation and frequently more than one way of approaching the solution. Equally, there is a wide variation in the companies, business sectors, and industries that suppliers deal with. A supplier may well have significant experience with your type of business and industry, but you might do things a little differently. Therefore there is a need for the supplier to understand your actual requirements.
The best way to do this is to produce a User Requirement Specification. This does not have to be a long and complex document, but should contain the following:
- An Overview Of What The Facility & The System Being Supplied Should Do
- The intention is to get everybody on the same page, and that includes the judge should the project not go to plan and there is a contractual dispute.
- It Should Contain Key Figures & Hard Numbers
- This will limit the scope for assumptions to be made. The numbers should relate to overall totals and movements and keep process and material flows. For example, you are not specifying such things as the number of pack stations or case erectors needed, just that x needs to be packed and shipped each day by your cut-off time.
- Operational Information & Any Constraints
- A supplier will need to know such information as working hours and shift patterns, service level agreements, such as despatch times, etc. Also any constraints such as existing building features or stock cover requirements.
- Timeframes & Dates
- This should include your timescales for when completion is required including any partial handover dates. It should also include any other key dates such as project sign offs.
- Future Projections
- The system will be designed to last many years and should be designed with the future in mind. Therefore projections for growth and other business changes should be included. Some changes will have more impact than others particularly if growth is anticipated in product size or number of orderlines per order.
The User Requirement Specification should be supported by data. It is much better if information can be supplied for a peak and average period at transaction/item level than high level. This allows the supplier to optimise his proposal and for confidence in the performance of the system to be gained through modelling or simulation.
The specifications should be produced by the client, though if the expertise or resource is unavailable a third party such as a consultant can be used or a supplier if you have chosen to partner with one. However, it is produced the client should take responsibility for the document as it sets out their requirements, and will form the basis for functional design specifications, test scripts, and handover conditions.
If you are going through a formal tender the Specification can form part of the tender documentation and be referenced in the contract when an order is placed. This then ensures that the importance of meeting your requirements is recognised throughout the life of the project.
