VAS Brochure

Read testimonials about our experience, performance, dedication and results.

AWMS™ Adaptive Warehouse Management System

Download PDF

This paper is an introduction to the features and concepts of an Adaptive Warehouse Management System or AWMS™. The features of a non-adaptive system are reviewed and then contrasted with the features of an adaptive system. These concepts are then used in an application example to further demonstrate an AWMS.

Non-adaptive systems more often take the position that reality is represented by the systems internal data and that non-conformant events (or exceptions) should be forced to conform to that internal representation. If conformity cannot be forced, the non-conformant event should be treated as a “logged anomaly” which essentially ignores the event. An inherent design flaw in a non-adaptive WMS is that the “data is reality”, and in order to change reality, the system is first changed and it is assumed the real world will follow. This limited view often results in data inconsistencies due to incomplete or non-existent information updates after one of those exceptions.

On the other hand, an Adaptive Warehouse Management System (AWMS) uses the basic design principle that “internal data models reality”. An adaptive system recognizes inconsistencies in information, and resolves those inconsistencies. Further, an AWMS may often have features that evaluate events as they occur and determine the individual action to take based on the current conditions. “Real-time dynamic optimization” is the term used by VAS to describe this evaluation and setting of a new course of action.

The following example for the Mandate® AWMS starts with a discussion of warehouse locations and location identifiers. An AWMS will typically have unique location identifiers for any place that may contain items to be managed within the AWMS. Examples include fixed locations such as racks of all types, floor positions, bins, rooms, areas, yards, buildings, facility, workstations, “lost location”, stackers, carousels, conveyors, and moveable locations such as trailers, pallets, cartons and totes. Locations in the Mandate® AWMS have an attribute called the “parent location”. The “parent location” of a location indicates the “current location” of the item. The parent location of a fixed location is not normally modified. An example of location parentage is a carton has a parent of a pallet, which has a parent of a workstation, which has a parent of an area, which has a parent of a building or facility.

An AWMS example includes a concept of what VAS describes as “believing the last liar”. This concept is different from “believing the last lie”. A lie is something that is not true, while a liar is a source of information, which is known upon occasion, to provide false information. The notion of believing the last liar implies that new information has intrinsically greater validity than old information. This notion is inherently true because, when evaluating the source of the old information, it too will be discovered to have originated from a liar. Of course, this concept or philosophy cannot be the only basis for making decisions that will establish a current view of reality but it is the basis for adaptiveness. To “adapt” is to “change based on the current environment”.

When put into these terms, no WMS provider in his or her right mind would wish to claim to be non-adaptive. Many will claim that the adaptive (or non-adaptive) features are just part of the specification of the system. In certain cases, this may well be true.

The true distinction of an AWMS is that it has an inherent inclination to accept new information to establish its current image of reality.

Now, for the example: Carton 1234, an assumed unique carton license plate number, is believed to have been placed on pallet 1. Pallet 1 is reported to have been placed in rack location XYZ. For this example, assume the carton and pallet are in their respective desired locations so that the AWMS has no inclination to move them.

The wording of these statements of conditions and events in an AWMS is important. All statements need to be understood as the “most likely truth” and in an AWMS are only believed to be true. This is a recognition that any and all statements of fact have, under certain circumstances, been known to be false. In the statement above, cartons have been known to have been mis-labeled as to make their license plate numbers non-unique. Cartons have also been known to be placed on the wrong pallet or even lost. Additionally pallets themselves have been mis-labeled and placed in the wrong location. Locations have even been known to be mis-labeled. For our example however, since this is the only information known to the AWMS, it will report the actual location of carton 1234 as on pallet 1 in rack location XYZ. This is the perception of reality in the AWMS.

Now, a new piece of information is received by the AWMS. A conveyor barcode reader reports an unexpected carton – carton 1234 at a particular zone. The AWMS will inherently adapt to this situation unless specific conditions are set forth to prevent its adaptation. To adapt, an AWMS “knows” that a single carton cannot be in two places at the same time so an AWMS will remove the carton from pallet 1 and automatically update the inventory for both pallet 1 and location XYZ to reflect the loss of the carton and its contents. The AWMS will then automatically update the location of the carton to reflect that it is now in the reported conveyor zone.

With the newly given input, the AWMS will report the actual location of carton 1234 to be on the conveyor. The AWMS will also report of pallet 1 and rack location XYZ as not including carton 1234. This is the newly adapted perception of reality in the AWMS.

As stated before, an AWMS often has features that support real-time dynamic optimization. If it has these features the AWMS will evaluate events as they occur and determine the individual action that should be taken based on the current condition. This is not as complex as it sounds. Recognize that most operational events are not unexpected – most events are exactly what are expected. Additionally, if the planning process includes only decisions that have to be made at that particular time, exceptions will not result in massive re-plans.

In our example, if real-time dynamic optimization is not supported, the AWMS would normally look at the desired location of the carton, and determine it should be on Pallet 1 in rack location XYZ. The AWMS will attempt to route the carton to that location. Typically, this would cause the carton to be routed to a no-read area where the carton is manually rejoined to the pallet.

If real-time dynamic optimization is supported, the AWMS, detecting the unexpected condition would re-evaluate the desired location of carton 1234. The rules for re-evaluation are defined to minimize operational impacts. Examples of existing Mandate AWMS rules for re-evaluation include 1) check if the carton could be used to efficiently fill a current order and if so use the unexpected carton and cancel any less efficient pending actions to fill that same order. 2) If there is no order for use, evaluate the stock levels for various stock areas and determine where it is best to re-stock the carton. Update the desired location of the carton to reflect the results of the re-evaluation. Then route the carton “toward” this newly optimized desired destination.
To conclude, an adaptive warehouse management system with real-time dynamic optimization is constantly resolving inconsistencies in information and optimizing the best course of action to take based on the current conditions and new information.

Static, Dynamic and Virtual Batching

Download PDF

Batch picking or batch order fulfillment is an operation where multiple orders are filled simultaneously rather than filling a single order at a time. Batch picking fulfillment systems can normally improve productivity. Productivity or efficiency of batch picking operations can be further extended through both dynamic and virtual batching. Dynamic batching allows new orders to be incorporated into the order “pick pool” on the fly. With a larger pick pool, efficiency is improved because better, or more efficient orders, may be selected for a batch. Virtual batching is where orders are added to a single batch as existing orders in the batch are completed. In static batching, a batch is created by selecting orders from the order pool, and the batch is complete only when all orders in the batch are complete. Static batching systems are the least efficient batch fulfillment systems. Using real time dynamic optimization, as described later in this document, can further optimize dynamic and virtual batching.

To demonstrate the differences in each of these batch fulfillment systems the following application examples are provided.

Static Batch

Incoming orders are received in two daily order downloads. Each of the daily downloads are processed into two processing (delivery) waves making a total of four daily delivery waves. Once a daily download is processed, new orders cannot be added, modified or deleted from either of the two created waves. As waves are created, product (inventory) is allocated to fill the orders. The inventory allocation defines the pick locations for each of the orders in a wave. Orders within the wave are grouped together in pick batches. The number of orders in a pick batch (batch size) for this example is six, which in this case is limited by the pick cart. In this example the average number of line items (different SKUs) in an order is five. Orders are shipped in a single carton. Each pick batch will require the picker (order selector) to make a “loop” in the fulfillment zone, starting at fixed location and ending back in that location when all orders and thus the pick batch is complete. The software sequences the orders for the order selector to make the shortest trip around the loop. During pick batch creation (download processing) the specific orders selected for each batch may be optimized based on some criteria (i.e. reduction in the number of locations to visit) to help improve efficiency.

Dynamic Batching

This application example allows new orders to be received continuously throughout the day. The received orders include an individual priority code specifying either a delivery wave or just a delivery priority. All received orders are kept in an “order pool”. Pick batches are not created until needed (a pick cart needs a new pick batch). The software creates a pick batch by selecting the orders with the “highest” order priority from the “order pool”. Pick batch optimization may occur just as in static batching. Orders in the “order pool” may be deleted or modified as necessary. Dynamic batching maximizes operational flexibility to place last minute orders and to make modifications to existing orders. There may be productivity improvements due to the larger order pool size that could benefit order selection optimization in batch creation.

Virtual Batching

This application provides for a single “virtual batch” where new orders may be added to the batch as individual orders complete. In virtual batching, the notion of a “batch completing” does not exist. In this example, the batch size is still limited at six by the cart. The picking loop no longer has a beginning or an end, as it is just an endless loop. As orders (or cartons) complete, they are removed as soon as possible from the cart “put” locations (cells) to provide room for a new order. Completed carton removal may be accomplished by several operational means including using ergonomically unusable pick locations as temporary holding places for completed cartons or by providing multiple unloading locations in a loop. Virtual batching is most useful when one or more of the following conditions exist: 1) the picking loop is very long, 2) average lines per container is small or 3) when dealing with multi-case orders. The estimated walking time reduction factor when using virtual batching compared with static batching can be calculated with the following formula:

Static Batching To Virtual Batching Transit Time Reduction Factor =

1 – ( ( ( L – 1 ) / L ) * ( 1 / C ) )

where:

L is average line items per container

C is average containers per order

In this example there are five line items per order and one carton per order. The transit (walk) time reduction factor is 1–(((5-1)/5)*(1/1)) = 1–((4/5)*(1)) = 1–(.8) = .2. Transit time is reduced by 20% if virtual batching is used instead of ordinary static batching.

Additional Optimizations in Dynamic and Virtual Batching

Real Time Optimization of Next Order to Release: Transit time reduction factor can be increased further in a virtual batching application with real time optimization of new order selection. New orders added to the virtual batch can be selected from the available orders based upon which order will complete in the shortest distance from the current location. This optimization is more efficient with the greater number of available orders as provided by dynamic batching.

Dynamic Order Inventory Allocation

Using real-time order inventory allocation can reduce further the transit (walking) time. In many situations an item can be picked from more than one location. Instead of having an order stock allocation process that pre-defines the location from where an item needs to be picked, the software can decide, in real-time, the most convenient place from where to pick the item. Dynamic order allocation not only increases the picking productivity of the operation, but also simplifies the handling of shortages.

Summary

The features described in this document are examples of real time dynamic optimization. Batch picking with carts or modules is an in-expensive approach to increased productivity. Some of the described features may not apply to a specific batch picking application; likewise, other dynamic features may be advisable for that specific application. Carts, modules and systems based on Mandate® based SOFT™ technology, provide ideal solutions for Dynamic and Virtual Batching applications. Real time optimization and Dynamic Order Inventory Allocation are built in features of the Mandate® AWMS™.

Why Batch Pick?

Download PDF

Batch picking is a process where multiple orders are filled simultaneously, and it is used to reduce transit time. With a “man to goods” system where an order selector travels to the product to fill orders, batch picking can drastically reduce the travel time. In a “goods to man” system where product is delivered to the selector, batch picking can reduce delivery traffic.

This paper addresses batch picking in a “man to goods” system. With modern technology, the transition to a batch pick system can be very inexpensive and un-complex both in implementation and operation. This paper provides the basis for determining the benefit of transitioning a “pick ticket” based order fulfillment system into a batch picking system.

To analyze the benefits of a proposed transition to a batch fulfillment system, the order fulfillment process is divided into three time categories.

  • Pick Time—(PT) the time to retrieve an item from its storage location and place the item in the “order” container.
  • Transit Time—(TT) the time to travel to an item
  • Setup and Close Time—(CT) the time to prepare or setup the “order container” prior to putting any items into it and the time to complete the order container once the required items have been collected.

To analyze the potential benefits of a system, the values for each of the above items must be known. Obtaining these numbers is a very easy process; do not believe those that would tell you that it is complex. Just follow the following five steps:

  • Obtain the normal or average overall picking productivity for a worker Base Fulfillment Rate (BFR) in units per hour. For an existing system, this is easily obtained by dividing the total number of units picked, packed and shipped over some period of time by the number of workers that preformed that work. Normalize the value into the number of units per hour. Insure that the time used does not include “non-productive time”. The result is an average BFR units per hour that a worker can pick, pack and make ready for shipping. If there are no existing metrics, this number will need to be estimated. There are many existing installations that should be similar enough to get an estimate. Additionally, if necessary, there are several simple techniques to refine such estimates.
  • Obtain the average units per order container (i.e. carton) (UC) by either reported metrics or estimation.
  • Obtain the order container (carton) Setup and Close Time (CT) in seconds through direct measurement. This time does NOT include any pick time or travel time. It only includes preparation time prior to picking and completion time following picking. This measurement is always done through observation with a stopwatch. If there is no existing system to measure, set up and measure the time of a simulated operation with real goods, cartons, simulated labels, tapers, staplers, etc. Take many measurements and calculate an average.
  • Determine the Pick Time (PT) in seconds also through direct measurement using a stopwatch. The pick time should not include any walk time but should include any required location or SKU verification, the picking of the product and the placement or packing in the order container. Make many measurements and take an average.
  • Once the above values are obtained the average Transit Time (TT) in seconds is calculated. This calculation yields a TRUE representation of the REAL AVERAGE TRAVEL TIME, for there are no other “productive time” operations that the worker may be doing other than prepare, travel, pick, pack and close. The formula is:

TT = (3600/BFR) – ( PT + (CT / UC))

For a system that has a base fulfillment rate (BFR) of 120 units per hour, 10 units per carton (UC), a pick time of 6 seconds and a carton setup and close time of 60 seconds, the transit time is:

TT = (3600/120) – ( 6 + (60/10))

TT = (30) – (6 + 6)

TT = 18 seconds

To batch-pick with a pick cart is one of the most popular ways of reducing transit time per transaction. Picking several orders at the same time will reduce the transit time by nearly the number of orders picked simultaneously – the size of the batch (SB). There is a small increase in handling time of each item due to the need to select which order container to put the item into—the selection time (ST). There are means to nearly eliminate the additional selection time (ST) through lights and automatic pushers. ST is almost never greater than 2 seconds and in many cases can be less than .5 seconds.

The calculated transit time for the new batch fulfillment system (TTN) is based on the calculation of transit time (TT) for filling single orders (see above). The formula for calculation is:

TTN = (TT / SB) + ST

Converting from a paper based single order fulfillment system as described above to a batch picking system with carts holding nine orders (SB) would yield a travel time of

TTN = (TT / SB) + ST

TTN = (18 / 9 ) + 2

TTN = 4 ; or a travel time reduction of TT – TTN = 18 – 4 = 14 seconds

The fulfillment rate of the new batch system (NFR) is calculated as follows:

NFR = 3600 / ( TTN + PT + ( CT / UC ) )

NRF = 3600 / ( 4 + 6 + ( 60 / 10 ) )

NFR = 3600 / 16

NFR = 225

The single order fulfillment rate (FR) in the example above was 120. With the new fulfillment rate of 225, the productivity increase is a whopping 187% (225 / 120)

Why batch pick? Because you are not running a gym!

Managing Equipment For Article Sorter Delivery

Download PDF

Most systems using article sorters to process orders also use automated equipment for product delivery. The automated equipment includes devices such as carousels, stackers, conveyance, sortation, queues, buffers, induction stations etc. Article sorters themselves are a batch-picking device that allows delivered product to fill multiple orders. VAS has a great deal of experience in the management of both the sorter and the equipment that is responsible for the delivering of product to the sorter. This paper identifies and discusses some of the interesting non-intuitive factors and concepts that should be addressed in article sortation systems.

When designing a delivery system for an article sorter there is one design factor that needs initial definition and consideration that will influence nearly all future decisions. That factor is the ability of the delivery system to control the sequence of the product arrival. The degree of sequence control will impact future decisions. This does not imply that either sequenced delivery systems or non-sequenced delivery systems are better or worse, it just identifies that many other design implications will be based on that factor.

Another factor is the determination if the sorter is to operate using a virtual wave and a related issue of the expected order completion rate. Sorters that are to operate using a virtual wave are more dependent upon product delivery sequence while sorters operating using multiple waves have some interesting order completion rate issues that need to be addressed.

Another factor is the determination if the sorter has a “drop station” and a separate “completed order queue”. This factor has significant sorter (and system) throughput implications.

A factor that many designs address is to “organize orders”—to group orders together that have similar SKU requirements to improve efficiency.

A final factor discussed is the consideration of sort rate and its relationship to the number of induction zones, product routing to the induction zones and tray rate.

Product Arrival Sequencing

This factor is primarily determined by the type of equipment that is used for product retrieval i.e. a manual selection process, a carousel, or a stacker. If a manual product selection process is used, the ability to sequence product arrival is inversely proportional to the retrieval efficiency. The same is true when using a carousel, however the inefficiency is normally expressed in a reduction of delivery throughput. Using a stacker, the throughput is not as adversely affected by product delivery sequencing and VAS Engineers have designed and installed systems using stackers that exceeded stacker manufacturers throughput rates by 30% or more while maintaining the same travel speed. The sequencing of delivery of product to a sorter allows a sorter to easily operate in a virtual wave mode. This mode increases sorter productivity and evens out the flow of completed orders.

Operation of a Sorter using a Virtual Wave

To operate a sorter in a virtual wave, if the product delivery system is capable of delivering product in sequence, the management of product delivery should be controlled by only one rule—the fastest completion of orders. This rule dynamically selects product for delivery that will complete the most orders. Of course, when the product is delivered, it is used for any and all orders that have a requirement filling the most complete first. If the delivery system is not capable or has limited product delivery sequencing ability, more complex rules are applied. The result of the application of these rules will lead to orders completing in bunches, with an initial period of time with no orders completing and then a group complete together. Picking without virtual waves and with limited product delivery sequencing the bunching of order completion is most significant.

Operating using Separate Drop Stations and Completed Order Queues

Sorters operating with a separate “Completed Order Queue” will have a significant throughput advantage over a sorter without such a queue. This is because the sorter is not able to start filling a new order until the previous order is removed from the drop station. The order completion bunching further impacts this situation further reducing the system capacity. To understand this, consider a sorter that picks static waves. Imagine that each delivered product (SKU) will normally be used for 3 orders. As the last SKU in the order arrives, the last 3 orders would be completed according to the example. The next to the last SKU arrival would also be used for 3 orders, however if the delivery sequence were not precisely controlled those three orders were not the same 3 as were completed by the previous SKU. That would mean that the next to the last SKU delivered also completed 3 orders that were most likely not the subsequent orders. The thought process goes on to the final 10 SKUs delivered. If the sorter had 300 drop stations (orders), the chances would be that nearly 30 orders would be completed with those 10 SKUs. Order completion is “bunched” at the end of the wave, resources for packing or completion of orders are thus backlogged due to the bunching and the sorter drop stations are not available for new orders, induction must stop and sorter efficiency limited.

Organization of Orders

Many sortation designs consider or attempt to “organize” orders grouping orders together that have similar SKU requirements to improve efficiency. VAS engineers have successfully implemented designs where groups or “categories” of product have been delivered to a sorter filling stock category orders. However, we have had no success in devising a means of grouping a particular group of orders together for picking. This type of a problem requires a technique called “linear programming”. In addition to requiring great computing resources, our experience is that the efficiency gained by “cherry picking” good orders to group together is short lived. You wind up with a bunch of bad orders and their pick efficiency is even worse together. The resulting net overall gain is absolutely nothing.

Sort Rate

The sort rate of a sortation system is determined by many factors, however realistic estimates can be made if the proper consideration is given. Probably the single most elusive factor to consider is the non-productive time. The sorter tray rate, the number of induction and corresponding drop zones, and the ability to select the induction zone for each SKU arrival will determine the resulting sort rate. VAS engineers are experts in the calculation of the sort rate.

Distinction between a WMS and a WCS

A note should be made on the distinction between warehouse control, and warehouse management. In the MHE industry, there has been somewhat of an inclination to create a layer between equipment control and warehouse management systems. Some call this layer a “Warehouse Control System” or a WCS. VAS feels that such a layer is not a good idea. Today’s systems are driven by data. This is particularly true with automatic article sorters and their associated delivery system. Good equipment control needs good data in order to make real-time decisions. The availability of the data necessary to make these decisions is embodied in the WMS. We feel that the WCS concept has arisen out inadequacies in software provider’s offerings and “software product packing”. Packaging of a WMS does not require that the WMS have all the features of any or all other WMS but only that it have all the features necessary for it’s intended application current requirements and a means to address future improvements. The Mandate® AWMS™ with its adaptive real-time nature is a WMS that is ideally suited for a facility that intends to use article sorters for order fulfillment.