Process first, software second

Many companies buying a warehouse management system (WMS) think order will arrive with the software. In fact software only makes a process stricter and faster. If the process is clear, order runs quickly and accurately. If the process is vague, disorder runs at the same speed, only now it shows on the screen and in the report. That is why the sequence of process first, software second prevents costly mistakes.

What software can and cannot do

Software keeps records, directs the picker to the right location, catches a mistake at once through scanning, stores history and prepares reports automatically. But it cannot invent the rules itself: whether to receive a partial delivery or hold it, who writes off a broken box and how, whether an urgent order may jump the queue. People have to answer these questions. Software will not fix a faulty database, replace discipline or improve an awkward layout.

When disorder gets automated

Suppose the warehouse has no marked locations. The software demands that the picker "scan the location", and there is none. Staff find a workaround: they book goods into a "general zone" and mark them on paper afterwards. The system starts showing zero where stock exists and stock where there is none. Double entry appears, paper and system run in parallel, staff lose trust saying "the software is wrong", and in the end they go back to Excel.

There is another problem: every unwritten rule becomes a question from the contractor during implementation. Returns, partial shipments, defective goods and urgent orders surface in the third week of the project and extend the timeline and budget.

What to do before software

1. Describe the current flow on one page: receiving, put-away, storage, picking, packing, shipping, returns, counts. Each stage should have a person responsible.
2. List the exceptions and set a rule for each: partial delivery, defects, wrong item, urgent order, return.
3. Clean the product catalogue: one code per item, units of measure, packaging, weight and dimensions, expiry and batch flags.
4. Introduce a location scheme and labels, and test them by hand.
5. Write down roles and authority: who may correct a balance, who confirms receipt.
6. Measure the current indicators: record accuracy, time to pick one order line, order cycle, errors per 1,000 lines. Without baseline figures you cannot prove the software paid for itself.

These tasks do not depend on software and bring results of their own: in many warehouses, introducing locations and cleaning the catalogue alone raises record accuracy noticeably. In other words, part of the spending on software can pay for itself even before the software.

An example: duplicates in the catalogue

An example, with illustrative figures. The catalogue holds 12,000 items, of which 700 are duplicates: one product kept under two codes. Part of the stock lies under one code, the rest under the other. The system shows "none" under one and "surplus" under the other. If the catalogue is moved into the software without cleaning, those 700 errors move with it and are fixed by hand every day for the first months. Cleaning before the software is a job of a few weeks; after launch it is costlier and more confusing.

When software is really needed

Signs that the process is ready: the procedure is written down and has been followed for at least 2 to 3 months; record accuracy is stable; volume has outgrown paper and Excel (several shifts, several warehouses, many orders); the recurring exceptions are known. Even then an existing 1C configuration or Excel is sometimes enough. Choose software not because it is "popular on the market" but because it solves your problem. Criteria: can it handle your exceptions, how is data exchanged with 1C and other systems, how long will staff need to learn it, will the vendor support you after implementation. Once you have written these criteria down, comparing products becomes much easier.

Conclusion

Software strengthens a good process and speeds up a bad one. The OmborExpert specialists help describe current processes, define exceptions and responsibilities and prepare requirements for software.