Twelve decisions before consulting a software vendor

A warehouse system project rarely fails for technical reasons. It fails because decisions that belonged to the company were made by default, in the rush of configuration, by people who did not have the authority to make them.

This document lists those decisions. There are twelve. None requires IT expertise. All must be decided — by you — before a software vendor, ourselves included, starts proposing anything.

You can read it as a preparation checklist. You can also use it as a framework for comparing providers: a vendor that asks none of these questions during the pre-sales phase will not ask them during the project either.

Before discussing items, pallets or parcels, you need to decide what the system tracks individually.

There are three possible levels, with different costs and effects:

• The item and its quantity by location. The system knows there are 240 units of item X in A-12-3. Simple and sufficient for many operations.
• The identified logistics unit. Each pallet has its own identifier, is tracked individually and has a recorded content. Necessary whenever multiple batches, multiple best-before dates or contractual traceability are involved.
• The serialised sales unit. Each individual unit has its own number. Reserved for operations that genuinely require it — the data-entry burden is considerable.

The question to decide: what journey must you be able to prove, and to whom?

The classic trap is to choose the finest level ‘just in case’. Traceability that is not recorded properly is worth less than coarser but reliable traceability.

A seemingly trivial question whose answer is rarely shared across departments.

The physical stock in the warehouse is not the stock available for sale. Between the two are reservations, quantities awaiting quality control, blocked stock, stock allocated to orders that have not yet shipped, returns not yet put back into stock, and sometimes stock that belongs to a customer but cannot be sold by you.

Decide and write down which categories are excluded from available stock, who is allowed to block it and who is allowed to release it.

Without this definition, sales and the warehouse will display two different figures, both correct, and no one will know which one to trust.

A warehouse project involves data already held by other systems: items, customers, suppliers, orders and prices.

For each one, there is a single question: who decides, and who copies?

There is no universally correct answer. There is one written answer for each data item:

The table above can be completed in a one-hour meeting. Leaving it blank leads to years of systems falling out of sync.

A warehouse system directs people to addresses. If an address does not physically exist, or changes without the system knowing, everything else breaks down.

This requires:

• a single naming convention, decided once (aisle, bay, level, position — or any other consistent scheme);
• labels that can be read from the actual working position, not from ground level one metre away;
• one person responsible for maintaining them over time.

A simple test: take a new starter, give them a random address and time them. If they cannot find it unaided in under a minute, the addressing system is not ready.

Every company picks orders. Few have written down the rules they follow.

Questions to decide:

• Do you pick order by order, or in batches?
• What determines the processing sequence: promised date, carrier, customer or size?
• What do you do with an incomplete order: ship it partially, wait, or decide case by case? And who decides?
• In what sequence does the picker move through the warehouse?

These rules already exist in your business, in your team leaders’ heads. The project consists of writing them down — and sometimes discovering that they conflict from one team to another.

Every check takes time and prevents an error. The right balance depends on your operation, not on a universal best practice.

For each stage, decide:

• At receiving: a systematic or sample-based quantity check? A quality check? What criteria lead to a rejection?
• After picking: a systematic, random or targeted check for high-risk orders?
• At loading: do you check the number of units handed to the carrier, and do you record it?

One general rule: a check that is not recorded is not a control; it is a habit that can be neither proven nor improved.

Returns are the blind spot in most requirements specifications. They arrive anyway.

You need to decide:

• Who decides what happens to a return — put it back into stock, downgrade it or destroy it?
• Within what timeframe, and where does the merchandise wait in the meantime?
• How is the physical return linked to the original order?
• Who issues the credit note, and on the basis of what evidence?

This process crosses at least three departments. That is precisely why it is poorly defined.

A project has one primary objective. Just one. Other benefits are welcome, but they do not determine the trade-offs.

• Stock reliability — knowing what you have, where it is, and being able to trust that information.
• Traceability — being able to prove a journey for a customer, regulator or recall.
• Productivity — handling more volume without adding people in the same proportion.
• Proof of service — demonstrating what you have done, particularly in contract logistics.
• Visibility — giving other people (sales, customers, management) information they do not have today.

Write yours in one sentence. When a difficult trade-off arises during the project — and it will — that sentence will decide it.

A question that gets postponed and always comes up at the worst possible time.

A warehouse that depends entirely on a system without a fallback procedure comes to a complete stop during a network outage, failure or poorly scheduled maintenance.

Plan how to receive, pick and ship without the system for two hours; how to enter the information afterwards; and who decides to switch to fallback mode.

This subject takes half a day of thought. It prevents a full day of downtime.

This is the decision that best predicts success, and the one most often handled carelessly.

A warehouse project needs someone on the company side who:

• genuinely understands operations (not just the organisation chart);
• has the authority to decide the management rules;
• has a defined and protected amount of time available.

The third point is the most critical. A project manager asked to lead the project on top of a full-time job will make rushed decisions and be absent at the moments when their presence matters.

Estimate that time honestly before starting, and have it approved by management.

There are two migrations, and they must not be confused.

Reference data — items, customers, suppliers and locations. It must be cleaned beforehand, not during migration. Duplicates, inconsistent labels and obsolete references are happily duplicated in a new system.

Decide now, while you can think clearly, what you will measure in six months — and measure it before you start so that you have a point of comparison.

A few indicators that can be measured without sophisticated tools:

• the recorded inventory variance, and the average time taken to detect a variance;
• the time between a truck’s arrival and release;
• the number of orders fulfilled incompletely;
• the number of customer disputes caused by a picking error;
• the time between shipment and availability of proof of delivery.

Without a measured baseline, no assessment will be possible — and the project will be judged on impressions.

SELF-ASSESSMENT GRID

For each decision, tick the column that reflects your actual situation — not the one you are aiming for.

Mostly column 1 — You are ready to consult vendors. Your requirements specification will be precise, the proposals comparable and the project able to meet its deadlines.

Mostly column 2 — The most common and most treacherous situation: everyone knows, but nothing is written down. Allow three to six weeks to formalise matters before starting a consultation. It is the best investment in the project.

Mostly column 3 — Do not consult vendors yet. A vendor will propose a solution to needs you have not yet expressed, and you will discover the real ones along the way — at a high price.

We publish software. This document says almost nothing about software, and that is deliberate.

Successful projects are not those that choose the best tool. They are those where the company knew what it wanted to achieve and the tool served that intent. The reverse — a powerful tool applied to a vague intention — produces a system that no one uses as planned, and disappointment that gets blamed on the supplier.

If the twelve decisions above seem obvious to you, your project will go well, with us or with someone else. If several make you hesitate, you have just saved several months.