Data collection terminal Zebra WT-40 with ring scanner. It is needed in order to be able to quickly scan the goods, while physically stacking the boxes on a pallet (hands free).
Over the course of several years, we opened stores very quickly and grew. It ended with the fact that now our warehouses receive 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 the process of receiving, assembling or shipping goods on such a scale is an opportunity to save time on operations. And it's also a huge savings.
That is why the two main efficiency factors are a well-thought-out algorithm of actions (process) and customized IT systems. Preferably βlike a clockβ, but βworking a little less than perfectβ is also quite suitable. Yet we are in the real world.
The story began six years ago when we took a closer look at exactly how suppliers unload trucks in our warehouse. It was so illogical, but familiar, that the 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 3PL operators who used their software and experience in building processes for logistics operations.
Acceptance of goods
As we said, our company at that time (as, in principle, 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 will interfere with each other. Thus, we started thinking about implementing a WMS (warehouse management system) information system. As expected, we started with a description of the target warehouse processes and already at the very beginning found an uncultivated field for improvements in the process of receiving goods. It was necessary to work out the processes in one of the warehouses, in order to then roll them over to the rest.
Receiving is one of the first big operations in a warehouse. It can be of several types: when we simply recalculate the number of packages and when we need, in addition, to calculate how many and what articles are on each pallet. Most of our goods pass through the cross-docking stream. This is when goods arrive at the warehouse from the supplier, and the warehouse acts as a router and tries to immediately resend them to the final recipient (store). There are other flows, for example, when the warehouse acts as a cache or as a store (you need to put the supply in stock, divide it into parts and gradually take it out to stores). Probably, my colleagues who are engaged in mathematical models of optimization of residuals will better tell about working with stock. But here's a surprise! Problems began to arise purely on 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 he sent the loader to pick up the goods. All this took about three hours (of course, the acceptance time largely depends on what kind of logistics flow we accept: somewhere it is necessary to do intra-package recalculation, but somewhere not). More people cannot be sent to one truck: they will interfere with each other.
What were the losses? They were the sea. First, warehouse workers received paper documents. They were guided and made decisions on what to do with the supply, according to them. Secondly, they counted the pallets by hand and noted the quantities on the same waybills. Then the completed acceptance forms were taken to a computer, where the data was entered into an XLS file. The data from this file was then imported into 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 transport, or this data was inaccurate.
The first thing we did was to start automating the warehouses themselves so that they would have process support (it took a bunch of software, hardware like mobile barcode scanners, deploy the infrastructure for all this). Then they connected these systems with ERP via a bus. Ultimately, availability information is updated in the system when a loader runs a barcode scanner over a pallet on an arriving truck.
It became so:
- The supplier himself fills in the data about what he sends to us and when. There is a bunch of SWP and EDI portals for this. That is, the store publishes the order, and the suppliers undertake to fulfill the application and supply the goods in the required quantity. When sending the goods, they also indicate the composition of the pallets in the truck and all the necessary information of a logistical nature.
- When the car left the supplier for us, we already know what goods are coming to us; Moreover, electronic document management has been established with suppliers, so we know that the UPD has already been signed. A scheme is being prepared for the optimal movement of this product: if this is cross-docking, then we have already ordered transport from the warehouse, counting on the goods, and for all logistics flows we have already determined how much warehouse resources we will need to process deliveries. In cross-docking details, a preliminary plan for transport from the warehouse is made at an earlier stage, when the supplier has just reserved a delivery slot in the warehouse door management system (YMS - yard management system), which is integrated with the supplier portal. Information comes to YMS immediately.
- YMS receives the truck number (to be more precise, the shipment number from the SWP) and records the driver for acceptance, that is, allocates him the necessary time slot. That is, now the driver who arrived on time does not need to wait for a live queue, and his legal time and the unloading dock are allotted for him. This allowed us, among other things, to optimally distribute trucks across the territory and use the unloading slots more efficiently. And also, since we make a schedule in advance, who, where and when will arrive, we know how many people and where we need. That is, it is also connected with the work schedules of warehouse employees.
- As a result of this magic, loaders no longer need additional routing, but only wait for cars to unload them. In fact, their tool - the terminal - tells them what to do and when. At the abstraction level, it's like the loader API, but in the human-computer interaction model. The moment of scanning the first pallet from the truck is also a record of the delivery metadata.
- Unloading is still done by hand, but for each pallet the loader runs a barcode scanner and confirms that the label data is in order. The system controls that it is the correct pallet that we expect. By the end of unloading, the system will have an accurate recalculation of all packages. At this stage, marriage is still eliminated: if there is obvious damage to the shipping container, then it is enough just to note this during the unloading process or not to accept this product at all if it is completely unusable.
- Previously, pallets were counted in the unloading area after everyone had been unloaded from the truck. Now the process of physical unloading is a recalculation. We return the marriage immediately if it is obvious. If it is not obvious and is found later, then we accumulate it in a special buffer in the warehouse. It is much faster to throw a pallet further into the process, collect a dozen of these and let the supplier pick up everything at once in one separate visit. Some types of defects are transferred to the recycling zone (this often applies to foreign suppliers, who find it easier to get photos and send a new product than to take it back across the border).
- At the end of unloading, documents are signed, and the driver leaves on his own business.
In the old process, pallets were often moved to a special buffer zone, where they were already worked on: they were counted, marriage was registered, and so on. This was necessary in order to free up the dock for the next machine. Now all processes are configured so that this buffer zone is simply not needed. There are selective recalculations (one of the examples is the process of selective intra-container recalculation for cross-docking in a warehouse, implemented in the Svetofor project), but most of the goods are processed immediately upon acceptance and it is from the dock that it goes 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 this sounds a little mundane to you, but five years ago, in a huge warehouse, being able to process a shipment directly 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 shipping or directly to the dock), then it must be put into 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 a given type, and then choose a place there and take, put, write down what was put. Now we have configured placement routes for each product according to the topology. We know which product should go to which zone and which cell, we know how many cells to take additionally next to each other if it is oversized. A person approaches the pallet and scans it with the SSCC using the TSD. The scanner shows: "Take it to A101-0001-002." Then he drives there and notes what he put, poking the scanner into the code in place. The system checks that everything is correct and notes. You don't need to write anything.
This concludes the first part of the work with the product. Then the store is ready to pick it up from the warehouse. And this gives rise to the next process, which colleagues from the supply department will tell about better.
So, in the system, the stock is updated at the time of acceptance of the order. And the supply of the cell is at the moment the pallet is placed in it. That is, we always know how many goods are in stock in total and where which one lies specifically.
A lot of flows work directly to hubs (regional transshipment warehouses), because we have many local suppliers in each region. The same air conditioners from Voronezh are more convenient to install not at the federal warehouse, but immediately at local hubs, if it is faster.
The reverse flows of rejects are also slightly optimized: if the goods are cross-docked, then the supplier can pick them up from a warehouse in Moscow. If the marriage was opened after the opening of the transport package (and it was not clear from the outside, that is, it did not appear through the fault of the transport workers), then there are return zones in each store. Marriage can be thrown into the federal warehouse, or you can give it to the supplier directly from the store. The second happens more often.
Another process that needs to be streamlined right now is the handling of unsold seasonal items. The fact is that we have two important seasons: the New Year and the time of the garden. That is, in January we receive unsold artificial Christmas trees and garlands at the DC, and by winter we get lawn mowers and other seasonal goods that need to be preserved if they last 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 got our hands on yet.
In five years, we have reduced the time of acceptance of goods (unloading the machine) by four times and accelerated a number of other processes, which in total improved the turnover of cross-docking by a little more than twice. Our task is to optimize in order to reduce the stock and not βfreezeβ money in the warehouse. And they made it possible for stores to receive the right product a little more on time.
For warehouse processes, the big improvements were to automate what used to be paper, get rid of unnecessary steps in the process due to equipment and properly configured processes, and connect all the 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 from the left) eventually turned into concrete actions in the warehousing 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 we count in saved trees, then the transition of suppliers to EDI portals also gave a lot. Now almost all suppliers do not call or communicate with the manager, but they themselves look at orders in their personal account, confirm them and deliver the goods. If possible, we refuse paper; since 2014, 98% of suppliers have been using electronic document management. In total, these are 3 trees saved per year only by refusing 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 quadrupled the number of stores, tripled the number of different documents, and if there were no EDI, we would have tripled the number of accountants.
We are not resting on our laurels and continue to connect new messages to EDI, new suppliers to electronic document management.
Last year we opened the largest distribution center in Europe - 140 sq. m. m - and took up its mechanization. I will talk about this in another article.
Source: habr.com