Pick-up cell on the ground floor of the shelf
You take one of the kitchen faucets from our store and carry it under your arm to the checkout. At the checkout, they make you a sales document, and at this moment the amount of this product on the balances in the systems and on the site decreases.
At night, each store calculates the forecast for orders for the next period. More precisely, a forecast for one year ahead is calculated every week, and orders for the store manager are calculated from it every night. The script sees that someone bought a mixer, and if sales go at such a pace (there is a whole block of a complex model, what is considered "at such a pace" and at what period), then the mixers will run out in seven days. This means that you need to form the next order for them to be delivered.
Most of the goods go to stores either through the cross-docking stream (the warehouse transfers pallets without opening or storing them in its stock), or directly from local suppliers. In part, we have already analyzed these processes in the last post . Consider a difficult case when a store needs mixers from a pallet that is in a warehouse in Moscow.
The difficulty is that a pallet is quite a lot of mixers. And you need to bring 50 pieces to the store, say. Can't take it entirely? And then the picking process appears, when the pallet is removed from the cell, put down, and then the nested container is taken out of it. This can be a transport box, an inner and a piece. The distribution center almost never operates with pieces, with the exception of rare and expensive equipment. For units, fulfillment centers are needed, but this is a slightly different part of logistics, and this post will not be about them.
Ultimately, when a store needs a product, the need is considered in the GOLD GWR forecasting system, and in the ERP (Oracle RMS) a final document appears with how much of what needs to be brought and where. It enters the warehouse management system (WMS) in the form of the "Ship to there" task and to the transport management system (TMS) in the form of the directive "Pick it up at the warehouse so and so and take it to the store so and so". Further, the task of TMS is to provide transport (for this, an application is sent to logisticians), and the task of WMS is to ensure the start of loading at the moment the dock opens for the arriving truck.
The goods can be shipped as a whole pallet or in a nested storage unit. The most convenient for the warehouse is, of course, to load the whole. Because when a nested storage unit (box) is needed, it takes time and manual steps. That is, it costs some money and reduces the turnover of goods (does not allow the warehouse to be used for something else).
It is appropriate to compare the warehouse with a database. She must respond as quickly as possible to applications that pull her. Part of it in-memory is cross-docking processes that do not require "writing" to the stock at all. Another part is the cache: these are special buffers where the product can lie down for a while before the next operation. And another part is a storage, a stock, where the goods are stored for further processing.
The task of a warehouse is always to reduce the stock and increase its turnover (i.e., reduce its shelf life). The less goods are idle, the more profitable for the company. But at the same time, when someone requested the desired product, but the warehouse cannot provide it, this is also a failure. All mathematics works between these two extremes.
So what's with my mixer?
The ideal process from the point of view of flow optimization is to use the warehouse only as a router. The ideal process in terms of availability is to keep all the world's goods in stock and dispense as needed.
In the end, the compromise for mixers looks like this: there is a mathematical optimum of how to transport them. Sometimes it is profitable not to buy this particular model at all (because there is a direct analogue), sometimes it is really profitable to buy and bring a whole pallet and slowly sell it from the store's warehouse. But more often it is profitable to carry a transport box. If there are 52 units in the box, and the store system calculated that 50 is needed, then the decision is obvious: a little more will be ordered - 52. But if the store needs three units, and the box - 100 units, then the question of the expediency of the minimum arises.
We do not use the minimax algorithm for stores, but now we are developing it and will use it mainly for small formats, since it is well suited when there is no or little space in the store's warehouse and you need to replenish the shelf immediately. For a small format there will be: maximum - shelf capacity, minimum - "trigger" quantity for the order, if the stock drops to a lower or equal value - we make an order to the maximum shelf.
Formation of demand for us works on the principle of order coverage and each order is covered with a stock until the delivery date of the next order.
For example, we place an order today, 01/01/2021, and we have 18 pieces left. The delivery date of such an order will be 01/07/2021 (the supplier carries one week in advance). The date of the next order is 01/14/2021, delivery is 01/21/2021.
Let's say we always sell two a day.
This means that we have to cover with the order on 01/01/2021 with stock right up to 01/21/2021, otherwise we will have nothing to sell.
Therefore, until 01.21.2021 we need 21 * 2 = 42 pieces.
We have 18 pieces on stock, so we order 24 pieces on 01/01/2021.
Of course, every order also contains a share of the safety stock.
Further, the order data is entered into the container. That is, if you need 45, 48 or 49 pieces, a minimum box of 50 is ordered. If you need 55 pieces, you need to order two boxes or optimize the model. As you can see, the less quantization (the more frequent the deliveries and the more manageable nesting units in the container), the more accurate the optimization. Therefore, deliveries to stores are made as often as possible, and therefore sub-boxes appear in boxes.
How does the box end up in the truck?
So, the task from the store goes to the ERP, and from there to the warehouse. The warehouse must provide the packed goods at the dock when the car ordered by the TMS system arrives there and takes it to the store.
In the warehouse, all orders are clustered in order to then optimize the routes of tasks for each individual loader. For each loader, the route is considered where it will pick up all the necessary goods most quickly and will not interfere with others. The function is general happiness, that is, reducing the total execution time of all operations in general.
Then people receive specific coordinates of targets (pallets in cells) and actions with them in the form of an algorithm. And they do it. It is broken down into steps in the spirit: "Go to cell such and such, take a pallet." A person drives, scans her barcode there, the system checks that everything is correct, and gives the following action: "Take it there." And so - all the time. We operate mobile terminals, and the movers obey them. So we have a kind of API for people in the warehouse. The next step, of course, is to remove people, but about that another time.
When a pallet needs to be taken apart, a separate picking process takes place. We take it from the storage compartment at the top and lower it to the lower compartment. From there we take two boxes of mixers, from the other - three boxes of other goods (let there be nails, they are interesting because they are packed in bulk) and so on. All this with terminals is scanned and checked at every step. As a result, you still get one pallet for the dock, only with different boxes.
When it is ready, a separate label is printed on it on the terminal, and it is now counted in the system as a separate place. Can be placed in the shipping buffer or directly on the dock.
The pick bins are a buffer, so after removing the goods from the pick pallet it is often necessary to lift the original pallet back up. Because at the bottom the cell will be needed for something else.
The one who puts the pallet from top to bottom and the one who takes the boxes from the picking bin are two different people. The pikeman is just picking up the goods, and the other person on the forklift is just juggling pallets.
Where did the truck come from?
From a TMS tool that consolidates all the needs of all stores a couple of times a day and cuts the needs of trucks. There, not only the order for each node of the graph is considered, but also the optimal route along the graph of different transport. The store places orders once a week, and scheduling of transport starts two days before delivery. In two days it is already clear what kind of transport will come to the dock, what and in what order to put it in it and how it will go. This automation applies to everything: when this truck just arrives at the warehouse, the system will tell by the number which gate it should go to and when, that is, we also manage the optimization of traffic at the docks.
In this case, we take into account not only the actual availability of goods in the warehouse, but also the goods that only go to it - this is also an important part of optimization.
How is it decided that the product needs to be replenished for such and such a quantity?
First, we look to see if this product will still be purchased. For each store there are matrices of what is on sale in it and what is not. These are regional features due to local suppliers, regional demand (very expensive professional equipment for repairs is most often needed only in Moscow), cultural characteristics (in Kazakhstan, there is a huge area of carpets for decoration), and so on.
The goods may stop being purchased in the store due to the end of the season: few people need lawn mowers in winter and Christmas tree decorations in summer.
If the product will be purchased, we calculate how much is needed for the next period. This is a pretty interesting model that takes into account the history of sales of a product (this is the main weighting factor) and takes into account the seasonality profile of the family that this product belongs to. When a product has a long history of sales in this and other stores, the model is built smoothly and you can get it down to the piece.
When the item is new, there is no history. You need to either take it from somewhere, or manually manage the product. In the case when this is a direct analogue of something known, you can simply indicate a pair of goods to it in the card. There were gloves working from one manufacturer, another came (or just the article or the model changed) - we indicate the previous pair, and the model is based on the history of another product. After six weeks (this is a magic constant), the product is automatically untied and only its own history begins to count.
When a product is completely new and it is generally unclear what to do with it, a certain amount is brought to stores according to a manual forecast. Then history is typed. Our fashion colleagues have a lot of mathematics about this, but we don't: we are still about renovation, and our fashion has just begun to appear in the field of kitchen ruler design and decor in general. The rest of the demand is smooth for almost all product groups. Seasonal changes are taken into account quite easily: for a new product - by group, for old ones - according to their long history.
Since we are still far from being able to count everything correctly and the system can make mistakes, the final document is sent for approval to the store administrator (or the person who is responsible for delivering the goods). More precisely, this is usually done by department managers (there are 15 departments in the store: tools, hardware, plumbing, etc.). It displays all items, without exception, that can be delivered within the department, and their number. That is, if the order contains 0, then there is a position and it costs zero.
We are currently testing ADR for some vendors. Since there are cases when the system offers a quantity for the order, and store managers confirm the parameters without changes and for a long time, the user does not need to process such orders in ERP and we automatically send them to suppliers. But there is a group of coordinators who support stores and monitor the correctness of such orders.
By agreement, you can remove the goods (if the New Year season ends, then you do not need to order another 100 artificial trees) or add one that has not been sold before. This requires another person from the office.
In 99.9% of cases, everything is decided on the spot in the store, and administrators only increase the amount of the product that, in their opinion, is being sold more and faster than the system can predict. Still, 50-60 thousand SKUs are very difficult to process only manually. They end up making minimal changes that help increase sales, feel in control, but don't introduce human error. Everything is done in a decentralized way, that is, each store manages its order itself, except in rare cases.
There are manual products. For example, non-standard shower cabins. There are goods on semi-automatic replenishment: the system for such goods calculates the offer for the order and quantitatively displays how much to order. Store managers see sales forecasts, sales history and, if necessary, adjust the quantity. We are engaged in reducing the number of adjustments to the proposed order, so that users do less manual operations and the system generates "ideal" proposals for the order.
We understand seasonal ratios well, where the same product is sold at different rates throughout the year. But at the same time, the goods that are sold a lot for part of the season, but not for part, are not yet processed very accurately. The model is sharpened for smooth shifts, not sharp fluctuations.
To calculate the order, the system takes into account the average delay of the supplier. If we see that the supplier is regularly five days late, then, in addition to penalties, GOLD will take this into account when placing an order and order more safety stock to take into account possible delays. Additionally, we have built on the analysis of daily balances: if a product was missing on the shelf for a large number of days in a week and if these days had a significant probability of sales, then the system sees this and understands that such a week should be excluded to take into account the sales history, and not lower the forecast.
How does the warehouse know how much to take and from where? Now you know how a store defines its needs. You know how it is consolidated and sent to the warehouse, and the warehouse must get the transport and ship it all. But there is another layer: the warehouse needs to process all this.
The sales forecast for each store and the logistics forecast, taking into account routes and the use of different types of transport (refrigerated trucks, sideboards, and so on), gives an understanding of how much goods will be needed and where. And by what dates you need to get it.
Further - another layer of optimization: where is it more profitable to get it by this time? Which party? Some suppliers set a minimum shipment volume (you won't be able to order a kilogram of nails), some give volume discounts, rebates and other special conditions. It is necessary to consider how to carry the goods and from where. We have just started working on this topic, while it is in a rather simple form. I think in a year there will be something to tell.
Sometimes it is more profitable to store the goods in a large batch than to buy several small ones; sometimes it is more profitable to split the delivery into ten local lots from different suppliers. Etc.
You need to know the percentage of rejects, so that there is no such thing that the goods have arrived, but they cannot be sold. The warehouse smoothes out all these fluctuations due to large numbers.
If you do not predict everything accurately, then the marginality of the product category decreases (unnecessary stock accumulates). The larger the assortment, the more items you need to track. When it comes to tens of thousands of positions on the market where there are global changes (and they are), then you simply cannot do without good automation.