Data collection terminal Zebra WT-40 with a scanner-ring. It is necessary in order to be able to quickly scan the goods, while physically placing boxes on a pallet (hands free).
Over the years we have opened stores and have grown very quickly. It ended with the fact that now our warehouses accept and send about 20 thousand pallets a day. Naturally, today we already have more warehouses: two large ones in Moscow - 100 and 140 thousand square meters, but there are also small ones in other cities.
Every second saved in picking, assembling or shipping on this scale is an opportunity to save time on operations. It's also a huge savings.
That is why the two main efficiency factors are a thoughtful algorithm of actions (process) and customized IT systems. It is desirable "like clockwork", but "working a little less than perfect" is also fine. We're still in the real world.
The story began six years ago when we looked closely at how suppliers unload trucks in our warehouse. It was so illogical, but habitual, that employees did not even notice the suboptimal process. Moreover, at that moment we did not have an industrial warehouse management system, and basically we trusted the logistics operations to 3PL operators who used their software and experience in building processes.
Acceptance of goods
As we already said, our company at that time (as, in principle, and now) was striving to open many stores, so we had to optimize warehouse processes to increase throughput (more goods in less time). This is not an easy task, and it was impossible to solve it simply by increasing the staff, if only because all these people would interfere with each other. Thus, we started thinking about the implementation of the WMS (warehouse management system) information system. As expected, we started with a description of the target warehouse processes and at the very beginning we found an unplowed field for improvements in the process of receiving goods. It was necessary to work out the processes at one of the warehouses, then roll them over to the rest.
Receiving is one of the first major operations in the warehouse. It can be of several types: when we simply count the number of cargo places and when we need, in addition, to calculate how many and which articles are on each pallet. Most of our goods are cross-docked. This is when goods arrive at the warehouse from the supplier, and the warehouse acts as a router and tries to immediately re-send them to the final recipient (store). There are other flows, for example, when a warehouse acts as a cache or as a storage device (you need to put the delivery in stock, split it into parts and gradually take it to stores). Probably, my colleagues who are engaged in mathematical models of optimizing residuals will better tell about working with stock. But here's a surprise! Problems began to arise purely in manual operations.
The process looked like this: the truck arrived, the driver exchanged documents with the warehouse administrator, the administrator understood what had arrived there and where to send it, then sent the loader to pick up the goods. All this took about three hours (of course, in many respects the time of acceptance depends on what kind of logistics flow we accept: somewhere it is necessary to do an intra-batch conversion, and somewhere not). You cannot send more people to one truck: they will interfere with each other.
What were the losses? There was a sea of them. First, the warehouse workers received paper documents. They were guided and made decisions on what to do with the delivery based on them. Secondly, they counted the pallets by hand and noted the quantity on the same waybills. Then the completed acceptance forms were assigned to the computer, where the data was loaded into an XLS file. The data from this file was then imported into the ERP, and only then did our IT core actually see the product. We had very little metadata about the order, such as the arrival time of the vehicle, or this data was inaccurate.
The first thing we did was start to automate the warehouses themselves so that they would have support for the processes (we had to install a bunch of software, hardware like mobile barcode scanners, deploy the infrastructure for all this). Then we connected these systems with ERP via the bus. Ultimately, the information on the availability of goods is updated in the system when the loader passes the barcode scanner along the pallet on the arrived truck.
It became like this:
- The supplier fills in the data himself about what he sends to us and when. For this there is a bunch of SWP and EDI portals. That is, the store publishes the order, and the suppliers undertake to fulfill the order and deliver the goods in the required quantity. When sending the goods, they indicate the composition of the pallets in the truck and all the necessary information of a logistic nature.
- , , ; , , , . : -, , , , . - , (YMS — yard management system), . YMS .
- YMS ( , SWP) , . , , , . , , . , , , , , . .
- , . — — , . API , human-computer interaction-. — .
- , , . , , . . : , , .
- , . . , . , . , . ( , , ).
- , .
In the old process, pallets were often moved to a special buffer zone, where they were already worked with: they counted, registered a marriage, and so on. It was necessary in order to free the dock for the next car. Now all processes are configured so that this buffer zone is simply not needed. There are selective recounts (one of the examples is the process of selective intra-unit recount for cross-docking in a warehouse, implemented in the Traffic Light project), but most of the goods are processed immediately upon receipt and it is from the dock that they go to the optimal place in the warehouse or immediately to another dock for loading, if the transport for shipment from the warehouse has already arrived. I know it sounds a little mundane to youBut five years ago, in a huge warehouse, being able to process a delivery straight to endpoints like a loading dock for another truck seemed like a kind of space program to us.
What happens next with the product?
Further, if this is not cross-docking (and the goods have not already left for the buffer before shipment or directly to the dock), then it must be put into the stock for storage.
It is necessary to determine where this product will go, to which storage cell. In the old process, it was necessary to visually determine in which zone we store goods of this type, and then choose a place there and take it, put it, write down what we put it. Now we have configured placement routes for each product by topology. We know which product should be in which zone and in which cell, we know how many cells to take in an additional row if it is oversized. A person approaches the pallet and scans it with SSCC using TSD. The scanner shows: "Take to A101-0001-002." Then he takes it there and notes what he put, poking the scanner into the code on the spot. The system checks that everything is correct and notes. You don't need to write anything.
This concludes the first part of working with the product. Then the store is ready to pick it up from the warehouse. And this generates the next process, which colleagues from the supply department will better tell about.
So, the stock in the system is updated at the time of order acceptance. And the stock of the cell is at the time of placing the pallet in it. That is, we always know how many goods are in the warehouse in total and where exactly which one is.
A lot of streams work directly to hubs (regional transshipment warehouses) because we have many local suppliers in each region. It is more convenient to install the same air conditioners from Voronezh not to the federal warehouse, but directly to local hubs, if it is faster.
Reverse flows of scrap are also slightly optimized: if the goods are cross-docked, then the supplier can pick them up from the warehouse in Moscow. If the defect was opened after the transport packaging was opened (and it was not clear from the outside, that is, it appeared not through the fault of the transport workers), then there is a return zone in each store. The scrap can be thrown into a federal warehouse, or you can give it to the supplier directly from the store. The second happens more often.
Another process that needs optimization now is the handling of unsold seasonal items. The fact is that we have two important seasons: New Year and the time of the garden. That is, in January, we receive unrealized artificial trees and garlands at the RC, and by winter - lawn mowers and other seasonal goods that need to be preserved if they survive another year. In theory, you need to sell them completely at the end of the season, or give them to someone else, and not drag them back to the warehouse - this is the part where we have not yet reached our hands.
In five years, we have reduced the time of receiving goods (unloading the machine) by four times and accelerated a number of other processes, which in total improved the cross-docking turnover by a little more than half. Our task is optimization in order to reduce the stock and not "freeze" money in the warehouse. And they made it possible for stores to receive the desired product a little more on time.
In terms of warehouse processes, the big improvements consisted in automating what used to be paper, getting rid of unnecessary steps in the process using equipment and correctly configured processes, and connecting all IT systems of the company into a single whole so that an order from ERP (for example, in the store is missing something on the third shelf on the left) eventually turned into concrete actions in the warehouse storage system, ordering transport, and so on. Now optimization is more about those processes that we have not yet reached, and the mathematics of forecasting. That is, the era of rapid implementation is over, we have done those 30% of the work that gave 60% of the result, and then we need to gradually cover everything else. Or move to other areas if more can be done there.
Well, if you count in the saved trees, then the transition of suppliers to EDI portals also gave a lot. Now almost all suppliers do not call and do not communicate with the manager, but they themselves look at the orders in their personal account, confirm them and carry the goods. Whenever possible, we refuse to use paper, since 2014, 98% of suppliers are using electronic document management. In total, this is 3,000 trees saved per year, just on the refusal to print all the necessary papers. But this is without taking into account the heat from the processors, but also without taking into account the saved working time of people like the same managers on the phone.
In five years, we have four times as many stores, three times as many different documents, and if it weren't for EDI, we would have three times as many accountants.
We are not resting on our laurels and continue to connect new messages to EDI, new suppliers to electronic document circulation.
Last year we opened the largest distribution center in Europe - 140 thousand sq. M. m - and began to mechanize it. I will talk about this in another article.