Analogistical

Concept and percept within the context of third party logistics. Showing my work.

  • Order Allocation vs Shipment Allocation

    With both an Order Management System (OMS) and a Warehouse Management System (WMS), we have two stages of allocation: Order Allocation -> which creates Shipping Orders/Shipments from Orders; and Shipment Allocation -> which creates Shipping Containers from Shipments and allocates specific units of inventory to a given Shipment and Shipping Container.

    Order Management just needs to know there are available qualifying units for a given item in order to allocate and create a shipment for that item. And the OMS won’t allocate more than is available to ship. Units available for allocation, however, is not necessarily a straight forward answer. We’ll get into the dimensions of this question in another post.

    Having established, however, that there are sufficient units of inventory for a given order, the resulting shipment must also pass through an allocation step in WMS. The Shipment Allocation assigns specific units in specific locations to a given Shipping Container. The Shipment Waving process allocates these units to a Shipping Container setting which Units in which Locations in which IUM configurations are going to be picked and shipped in a given Shipping Container.

    In contrast to the OMS allocation, the specificity of the WMS allocation is vital. While the OMS just needed to know that there was sufficient inventory, the WMS assigned (and will decrement) units of inventory from specific locations. If the picker on the floor disregards the Work Instructions from the WMS, your location inventory figures will be in disarray, even if the summary figures back up to OMS still hold true.

    , ,

  • Item Units of Measure and Operations

    Item Units of Measure (IUMs) encapsulate different configurations of item groupings. Each IUM has a set of Attributes, among them:

    • Length
    • Width
    • Height
    • Weight
    • Quantity Unit of Measure (Each, Inner-Pack, Case, Pallet)
    • Conversion Qty (the number of Eaches for the Given Quantity Unit of Measure)
    • Does this IUM need containerization or is it ready to ship?

    An IUM might be associated with an Item Class or with a distinct Item. And an Item or Item Class might have one to many IUMs – the Case for an Item has different attributes than a single unit of that item.

    What is important, however, is that the digital configurations of your IUMs match the actual dimensions and attributes of your products on the floor. IUMs provide the dimensions for shipping containerization, inventory putaway, materials handling for inventory movement. They provide the specs needed to validate location capacities and shipment rating with carriers. They can prove the difference between being charged for 1 pallet pick vs 800 Eaches picks from a pallet location. If your IUMs aren’t accurate and/or consistent among your actual physical products, then all of these processes devolve into disarray. At best, you might need to split some t-shirts across two forward pick locations because you missed a decimal place in the height of your case. At worst, you might be in a world of hurt because you shipped 10,000 identical shipments that weighed 0.4 lbs having bought postage at 4.0 lbs.

    , , ,

  • Data Objects and Physical Objects

    Fundamental to digital / physical agreement is confirming that your data objects correspond to the physical objects that you are working with. For example, as a Third Party Logistics (3PL) company, when evaluating a Warehouse Management System (WMS) or Order Management System (OMS), one of the first things we look for is the notion of a Company or a Catalog within the system – a Data Object that will correspond to the fact that, as a 3PL, we have more than one client (hopefully) under roof, each with their own sets of items, orders, configurations, etc. It’s not sufficient to have Company or Catalog be an attribute of an order and/or an item. We need Company or Catalog to be an object in its own right, allowing for its own appropriate sets of attributes and methods on the Company/Catalog-level.

    It’s also important to be thorough in declaring new Data Objects when something might appear to merely be an attribute. In our work, one of the areas we see this in high resolution is the distinction between Orders, Shipments and Shipping Containers.

    We receive Orders from our Clients. The OMS associates Orders with a given Client and their Product Catalog of Items. In addition to its header information (sender, recipient, catalog, ship method), an order has Order-Item information – instances of Items from the Client’s Product Catalog. These Order-Items both inherit attributes from its associated Item and also carry Order-specific information for that given item – maybe a sale price or a revised description.

    Orders allocate in our OMS when there’s sufficient inventory in our WMS to fulfill the order. The Order Allocation process in our OMS creates one to many Shipping Orders for a given order. An Order might have more than one Shipping Order for any number of reasons – perhaps some lines of the order are in stock while others are backordered, so you ship-ahead the Order-Items that are ready to go; or maybe some lines qualify for media mail and others are better suited for a light-weight shipping method – Ship Method is actually a Shipping Order-level attribute. An Order could have multiple Shipping Orders each with a different Ship Method.

    Our OMS hands its Shipping Orders off to our WMS where the corresponding Data Object is called a Shipment. Just as an Order can have one to many Shipping Orders/Shipments, so, too, can a Shipment have one to many Shipping Containers. As a consumer, you see this when UPS delivers a set of Shipping Containers and the Ship Label has 1 of 3, 2 of 3, etc. The tracking number / label, then is an attribute of the Shipping Container, but, also, a Shipment might have a Master Tracking Number which is then a Shipment-level attribute. Postage, Weight, Dimensional-Weight is an attribute of the Shipping Container, but Total Postage, Total Weight, etc would be a Shipment-level attribute. At the same time, it’s not sufficient to take the sum of the weight of the Shipping Containers for a given Shipment and do a Rate Table lookup – the lookup must happen on the Shipping Container-level, and the summation is the summation of the Rate Table calculations for each discrete Shipping Container.

    Finally, it’s important not to lose this resolution as you report activity back up the chain of your data objects. For example, consider an Order where your Client’s Customer ordered two collectible figurines and two vinyl LPs. The figurines are over-sized and are already packaged each in its own shipping container. The Order allocates in 2 Shipments – one for the figurines shipping UPS Ground and the other for the LPs shipping Media Mail. The figurines containerize separately resulting in two Shipping Containers, each with their own UPS tracking number, and the two LPs ship together in the same Shipping Container with one Media Mail tracking number.

    What’s needed, then, is for our the message chain all the way back up to the Order to handle the reality that an Order with a “Standard” Shipping Method and two lines of Order-Items resulted three Shipping Containers with two Ship Methods among them, in the case of one of the lines, splitting a qty 2 Order-Item line into two qty 1 Shipping-Container-Item line, each with its own tracking number. The correct, informed understanding of the physical flow in our warehouse allows for correct, well-architected Data Objects that maintain the required resolution of information up and down the chain of Data Objects.

    ,
    , , , ,

  • B2B Inventory Movement Strategy

    Generally we want B2B allocation to happen out of storage, allowing for Pallet, Case, and Inner-pack level allocation before allocation of Eaches. We don’t, however, want shipment allocation to wait on the needed Eaches to make their way to Forward Pick (FP) if they aren’t already there. Additionally, for inventory with regular movement, we prefer not to have loose Eaches in Storage.

    Strategy:

    1. Anticipate B2B need – move in Case or IP qty from Storage to FP according to unallocated B2B need (if there is an expectation for FP need for a given item over the next couple of months)
    2. Allocate B2B Shipments preferring FP for Eaches quantities, but overflowing to Storage such that B2B shipment allocation does not have to wait on inventory movement or require movement for otherwise non-moving items.
    3. Clean up non-urgently; moving resulting less-than Case or Inner-Pack quantities of active inventory out of Storage and into FP.

    Result:

    Maintain sealed Pallets, Cases, and Inner-Packs in Storage, but the importance of house-keeping doesn’t constrain the urgency of important B2B order fulfillment.

    , ,
    , , , ,