Writing a requirements brief: preparing to choose software

Choosing software for a warehouse usually begins with vendor presentations. Each one shows what it can do, and you end up not knowing what you are actually comparing: not requirements, but their slides. A requirements brief changes this order: now the vendors answer your questions. It need not be a document of hundreds of pages. For choosing warehouse software, a clear brief of 5 to 10 pages is often enough.

What a requirements brief should contain

1. Goal and success criteria: what should change (record accuracy, order-picking speed, shrinkage) and how you will measure it.
2. Scope and volumes: number of warehouses, product items, order lines per day, volume on the busiest day, pallet positions, users.
3. Processes: receiving, put-away, picking, packing, shipping, returns, stock counts and their exceptions.
4. Integrations: 1C or another accounting system, online marketplaces (for example Uzum), courier services, scanners and printers.
5. Requirements with priorities: mandatory, important, optional.
6. Technical requirements: speed, ability to work if the internet drops, backups, Uzbek and Russian languages, user permissions.
7. Data migration: catalogue, balances, locations.
8. Implementation: timeline, training, support, responsibility.

Write requirements so that they can be checked

A requirement must be measurable or demonstrable. Phrases such as "the software must be fast" or "a convenient interface" will be confirmed with a "yes" by every vendor, but they mean nothing. Compare:

• bad: "The software must be fast". Good: "Every operation read by a scanner is confirmed in under 2 seconds even with 20 users working at once";
• bad: "Integration with 1C". Good: "Once a receiving document is posted in 1C it appears in the software as expected inbound within 5 minutes; when shipping is complete the actual quantity is returned to 1C".

Do not stretch the list to 300 items: 30 to 60 important, verifiable requirements are more useful.

Three priority levels are enough. If a mandatory requirement is not met, the offer is rejected. An important requirement adds points. An optional one decides only when all else is equal. Keep mandatory requirements to 10 to 15, otherwise nobody is left to choose from.

How to compare prices

Looking only at the licence price is the commonest mistake. Calculate the full cost of ownership over at least 3 years: licence or subscription, set-up, integrations, equipment (scanners, printers), training, annual support, updates and staff time spent on implementation.

An example, with illustrative figures. Offer A: licence 90 million so'm, integration separately 60 million, training 15 million, support 36 million a year. Over three years that is 90 + 60 + 15 + 108 = 273 million so'm. Offer B: licence 130 million, integration included, training 20 million, support 30 million a year. Over three years that is 130 + 20 + 90 = 240 million so'm. Offer A, cheap at first sight, turned out to be dearer in the end. Ask about hidden charges too: is there a separate fee for an additional user, an additional warehouse or a new integration?

Demo scenarios and the choice

Give all vendors the same 3 to 5 real scenarios: a partial delivery, a return, a cycle count, an urgent order. Ask them to show exactly these live rather than slides. Give each requirement a weight (mandatory ones weigh more) and score the answers. Ask the finalists for a list of customers with similar warehouses and call them yourself.

Who writes it and what mistakes occur

The working group: the warehouse manager, a lead employee for receiving and picking, an accountant or 1C specialist, the person responsible for IT, a sales representative. 3 to 4 weeks is usually enough. Typical mistakes: copying a list from a vendor's website; not stating volumes; marking everything "mandatory"; forgetting exceptions; writing the brief without the warehouse staff.

The brief keeps working after the choice: put implementation stages and acceptance criteria into the contract, that is, what result counts as the work being done. Then the requirements do not stay on paper.

Conclusion

A clear requirements brief turns the choice of software from a contest of presentations into a calculation. The OmborExpert specialists help draw up requirements, set priorities and assess vendors' offers.