Getting to AI-Powered OMS Sourcing: The Crawl, Walk, Run Approach

Traditional sourcing tools often get stuck with predefined cost sets, like shipping and processing fees. While these may seem convenient at first, they struggle to adapt to the ever-changing world of logistics and fulfillment. New carrier models and innovative local distribution strategies constantly emerge, introducing new cost structures that predefined sets can’t handle. For example, new local carrier models may have new or different costs the sourcing engine should consider like cost per stop vs. cost per package. A retailer may wish to define the holding cost of an item in addition to processing cost and the way these costs are assessed by 3PL’s may be different. As more innovative approaches to local distribution evolve you need an application that will grow with it. This further means that when new costs are required, there is typically a feature request or customization effort to add it.

In addition, these costs may or may not be on actuals. Because the cost in traditional approaches is simply a user input, while it is expressed in cost, it can be a proxy for a set of actual costs being tracked elsewhere. Our approach is to source the actual data so these costs represent real costs to the retailer. While proxy costs may seem easier to manage, having a data source representing real costs forces the discipline of the business to ensure these costs are accurate and have a business process to stay updated. Ultimately you want the decision making of your sourcing engine to be as close to what the accounting team is going to use when they produce monthly P&L. Where we see this typically breakdown is in carrier rates. Retailers will model a set of carrier costs based on two attributes like weight and zone. Meanwhile there is a more complex set of rate tables that governs the actual contract that includes dimensional weight, minimums, surcharges and accessorial costs.

- Nextuple approaches cost definition in an entirely different way.

Costing always begins with data. While we offer multiple standard costs, all of these are enabled through a two-step process. The first step is acquisition of data fields that represent the costs. For example, for a given type of carrier service you may have four data fields such as item weight, zone of shipment, service level, and peak vs non-peak. Once these pieces of data are set up, how you define the costs are up to you. In our approach, this is the only development effort required. Once the data type is defined, it can used in any number of ways to define cost without development.

For example, the cost structure for item processing at nodes may be formulated on weight ranges and if the item is conveyable and if the store node has a full backroom operation. But let’s say you add in the capability to do gifting, and this becomes a new element in the processing cost formula. With our sourcing engine, the addition of data type “gift service” is the only thing you’ll need to code. How the cost is formulated with this new capability is handled through user configurations.

The formulation of penalties follows the exact same construct. Again, here we recommend using real world penalties costs vs proxies.

The standard approach to penalty estimation has been to allow retailers to attach penalty “costs” associated with other factors in the sourcing process such as capacity utilization, markdown avoidance, possible SLA miss or node performance. The retailer again must pick from a set of penalties and attach a proxy value associated with this penalty. For example, if a node is out of capacity a processing cost penalty of $500 might be added to the total cost of processing forcing the sourcing engine to avoid that node for selection. However, there are usually more factors involved in this decision. For example, what is the item type? The capacity penalty for small conveyable items is not equal to a large ship alone item. In addition, our approach is to model the real world incurred “Cost” of the decision. With our solution, we allow retailers to define multiple penalty types and define the attributes that are required to formulate the penalty. For example, going back to capacity the following approach could be used.

Typically, node capacity is planned over a horizon for days (say 2 to 3 months). The capacity is planned demand backwards. Since the capacity is sunk cost, sourcing optimization should be able to apply a penalty when actual capacity consumption is deviating away from planned capacity. Example: If a store’s N+1st day capacity is consumed, that indirectly means Nth day planned capacity of another store is wasted (100% wasted). Also using up N+2nd day capacity of a store means Nth & N+1st day capacity is wasted (200% wasted). The penalty is modeled as markup percentage on outbound processing costs.

With a combination of real-world costs and penalties, the ability to add new ones or change definitions of existing ones, you will have a full set of tools to make a more informed sourcing decision.

What this also does is ready you for the next step in journey. As you begin to think about AI/ML to solve these problems - Any ML model you choose to deploy will require a quality set of data. By forcing you to get the data right in step one you’ll have far more confidence in deploying one of our models.

While retailers have been using safety stock as a way to protect some store inventory and deal with inventory accuracy issues – this model looks at offline and online sales data by fulfillment type and then predicts the needed quantity at the SKU/node to protect walk in traffic sales that day. This is not a binary “store off/store on” but rather a penalty-based input to the sourcing decision. This model can look at replenishment schedules, promotional or seasonal inputs as well.

The model looks at several factors such as item, discounts, type of traffic, customer profile, time of day, payment option, etc. and then attempts to predict the conversion probability. From here the levers can be shipping discounts, shipping upgrades (faster EDD) all while considering a minimum gross profit threshold at the cart level.

From there this model can be enhanced with markdown optimization goals and offline vs online sales goals. Our goal is to provide a framework for enabling these ML models as components when you are ready with the data as an “and” not an “or” approach. Of course, the testing framework is there to assist you as you mature.

If penalty and cost estimation were not hard enough, today’s solutions have no framework for controlled testing of these changes. Retailers must deploy the changes across a full set of orders and the only mitigation strategy they have is to deploy changes at lower volume times. Of course, this many times defeats the purpose because sourcing decisions don’t really get challenging until there are constraints such as capacity and inventory.

We believe a retailer should have a far better tool kit in this domain, which is why we offer two different approaches for testing configuration changes.