Scheduling counts for Tashkent and regional warehouses

A warehouse in Tashkent can often be counted in a single day. A site in a regional city adds a journey, a night in a hotel and a local team you may hardly know. When a company has sites in both places, counting them one after another over several weeks produces numbers from different dates that cannot simply be added together. A plan that groups the sites by area and keeps one common cut-off time makes the whole exercise shorter and the numbers comparable.

Group the sites by area

Start with a list of every site: the city, the number of SKU lines, the approximate size and who works there. Then group them by geography, for example Tashkent city, the Tashkent region, and regional cities that lie close to each other. The cities of the Fergana Valley can make one group, and Samarkand and Bukhara another.

One group means one trip. Inside a group, put the larger sites first, because they are the ones most likely to overrun. When time is tight, give each group its own team and run the groups side by side.

One cut-off, one or several counting days

There are two basic models:

1. Parallel: every area counts on the same day, at the common cut-off, with its own team. It needs more people, but the numbers are simple.
2. Wave: one team travels from site to site over several days. Each number now belongs to a different day, so you bring each one back to the common cut-off using documents. Stock at the cut-off equals the quantity counted, plus what left since the cut-off, minus what arrived since.

Suppose the cut-off is Tuesday at 18:00 and a regional site is counted on Thursday, finding 100 pieces of a SKU. Since Tuesday evening it has dispatched 15 pieces and received 5. Stock at the cut-off was 100 + 15 − 5 = 110, and that is the figure to compare with the books. This works only if the site records every movement with a date and time. If it cannot, count it on the cut-off day with a local team, which means the parallel model.

Estimate the time site by site

Make a plan table with one row per site: SKU lines, expected duration, team size, travel and order. Measure the speed at the first site and update the table afterwards. Suppose a team of three completes 600 SKU lines a day in a tidy warehouse. A Tashkent site with 900 lines needs a day and a half, another with 1,500 lines needs two and a half days, a regional site with 1,800 lines needs three, and a small one with 600 needs one. That is 8 team-days in total, so two teams finish in four working days, plus travel. These figures are only an example; measure your own first.

Practical points for regional sites

• Send labels, the code mapping table and the cut-off sheet at least a week ahead. A missing roll of labels is the commonest reason for delay at a distant site.
• Name a local contact responsible for access, keys and lifting equipment.
• Check public holidays, market closing days and the month-end peak before fixing dates, and book travel and lodging early.
• Keep one coordinator in touch with each team by phone at fixed times.
• Keep the last day free for recounts and for any site that had to pause.

Costs and what to put in the budget

For trips outside Tashkent, transport and accommodation should be listed on their own line in the quote, separate from the cost of counting. That makes it easy to compare a plan with fewer, longer trips against one with more, shorter ones. Often a single longer trip to a group of nearby cities is cheaper than two separate visits, even if the team stays an extra night.

Merge in one place

However the counting is organised, the data should flow into one table with one cut-off. Each team exports its files at the end of each day and sends them to the coordinator, who checks that every site has arrived before anything is merged. A site that is late should be visible on the status sheet, not discovered when the report is due.

InventoryHub serves Tashkent and the regions. Transport and accommodation for trips outside the capital are listed separately and written into the contract, and the scan records from every site are merged into one SKU-level table.