Enterprises don’t have to rip and replace more than two decades of sunk costs in ERP systems, which represent immense investments in standardizing and automating record keeping processes. ERP data is also the foundation for regulatory and operational reporting. Machine learning-based applications from a new generation of ISVs can leverage the processes and data in legacy applications so that the combined applications can connect strategic objectives with thousands or even millions of everyday decisions that can be automated.
Machine learning has been the focus of a lot of attention now that many large enterprises have accumulated big data repositories and want to convert that data into actionable intelligence. But two core limitations on the wider use of this technology are the scarcity of data scientists and the investment tied up in maintaining legacy systems. Customers can turn both limitations to advantage, however. Vendors of machine learning applications “package” both data science and subject matter expertise. And they build on the data and automated execution of transactional decisions in legacy systems. This non-sponsored report focuses on Blue Yonder, a SaaS-based application for retail analytics and a Wikibon client, as representative of the first wave of ML-based apps. In this case, Blue Yonder’s first application focuses on optimizing grocers’ replenishment process. This category is especially challenging because of the short shelf life of perishable products. Blue Yonder shows concretely how to:
- Add new inputs to ERP in the form of quantified business objectives.
- Operationalize the objectives with more informed, completely automated decisions.
Add New Inputs to ERP in the Form of Quantified Business Objectives.
ERP and similar systems of record are about monitoring and controlling business processes such as order-to-cash and procure-to-pay. In order to monitor and control effectively, these applications have to standardize business processes. Once the processes are standardized, customers can leverage data feedback loops in order to optimize those processes for a range of business objectives. Grocers, for example, might run a daily demand forecast in order to place orders to replenish their inventory. Grocers may want to optimize procurement for different objectives, however. Objectives can be increased sales vs. profit, minimized spoilage vs. stock outs, and product availability vs. markdowns. In addition, those objectives may differ based on location or product.
Ordering the exact right amount given a complex set of drivers and competing objectives is a much harder problem than looking at simple trends over time. Traditional systems of record don’t offer this type of prescriptive analytics. ERP systems provide a superficial answer to the problem, typically in the form of trend lines based mainly on tracking historical sales. Blue Yonder, by contrast, forecasts demand nightly and then optimizes its recommended order quantity around the business objectives any given grocer has chosen. Under the covers, Blue Yonder forecasts demand for each stock keeping unit (SKU) for each store based on many factors including promotions, local competition, TV ads, online ads, seasonality, holidays, brand, and weather forecasts, among other inputs (see figure 1). The demand forecast isn’t in the form of a single answer for each SKU for each store, however. Rather, it is a range of quantities with different probabilities (see figure 2).
Having this statistical distribution of probabilities is critical for the optimization process. The application can’t just generate the daily order quantity based on the order quantity that is the highest probability. Rather, the application has to optimize the answer based on constraints representing the business objectives. The constraints get translated into costs, so that the cost of write-offs rises as the chosen order quantity rises. Similarly, the cost of stock-outs rises as the chosen order quantity declines. The following four figures illustrate how to optimize for a specific objective by applying cost constraints to a demand forecast:
- The range of likely demand for a given SKU. Demand is shown as a statistical distribution of probabilities (see Figure 2). Each level of demand, in units, has a different probability of being correct. The probability curve for different products or different periods of time can also be different. A wide and low curve means the highest likely level of demand is less than when the curve is narrow and tall. Wide and low means less confidence in a forecast. Narrow and tall means higher confidence in a forecast.
- The optimal order quantity balancing the cost of stockouts and the same range of likely demand. This probability curve adds an out of stock constraint where the cost is losing sales and less customer satisfaction (see Figure 3). Optimizing solely for stock-outs means the optimal order quantity is where the red cost curve intersects the second black bar.
- The optimal order quantity balancing the cost of write-offs and the same range of likely demand. Separately, this probability curve shows write-off costs, which include liquidation, capital lockup, and waste (see Figure 4). Optimizing solely for this constraint means the optimal order quantity is where the green curve intersects the black bar fifth from the right.
- The optimal order quantity balancing both stockout and write-off cost constraints and the same range of likely demand. This probability curve shows an objective of optimizing to minimize write-offs but holding stock-outs to a low but not zero level (see Figure 5). The blue line shows the optimal order quantity for these constraints. Note that this optimal order quantity is not the highest probability for demand. It reflects cost constraints that yield an optimum answer for one grocer for one SKU in one store.
Operationalize The Objectives With More Informed, Completely Automated Decisions
Legacy ERP applications can accelerate standardized business processes such as continual quarterly closes or order-to-cash. These processes provide automated insight into the business. But customers can go further and automate the execution of their business objectives by implementing machine learning applications on legacy ERP. A grocer using Blue Yonder can translate a top-level goal of attracting upscale customers by carrying a broader assortment of exotic and hard-to-find fresh food such as vegan baked goods; ultra-fresh items such as a variety of fish; while minimizing stock outs of these long-tail items. In other words, a grocer would have to modify their assortments of long-tail, hard-to-find items and deal with more spoilage in those products in return for ensuring that customers won’t find empty shelves. We’ve seen how to optimize replenishment orders based on cost constraints (see figure 5).
The Blue Yonder application lets customers optimize for their objectives at multiple levels: firm-wide (grocer), geography, store, product category, individual SKU. This enables flexibility in implementing strategy at a fine-grained level. Today grocers have to tell Blue Yonder to encode these objectives in the customer’s version of the machine learning model. In the future, grocers should be able to use sliders or knobs on a dashboard to “dial-in” the appropriate optimizations. For example, stores in Munich should optimize their replenishment to avoid stock-outs of beer in October. By specifying these constraints, grocers can minimize or prevent decentralized decisions based on intuition and rules of thumb. In the not-too-distant future, pricing, like demand, will be a value the application calculates. The application will combine decisions about how many units to buy with how to change their price to influence demand – for multi-channel retailers as well as brick and mortar retailers with electronic signage.
Machine learning models improve their accuracy over time, given enough feedback in terms of data about the models’ performance. But if a firm needs to introduce a new product for which they have no history, they can use the data for a similar product that has a correlated history. For a grocer adding a new category of specialty breads, they can use historical data from products coming from another baker. The first demand forecasts will have higher uncertainty and a wide probability distribution curve. The best approach is to make the first order, then observe sales and get better feedback about the predicted demand. Later demand forecasts will have a narrower probability distribution and you can use pricing to influence it. This is particularly important in industries such as fashion where new products are introduced frequently and there are even more variations for each item, including size, fit, color, and style. If you find anomalies in some of your historical data, don’t scrub it out just because it might look like an outlier. Review it with your software vendor. If it’s statistically significant, they will incorporate it into the model. That’s a key way for the model to continue evolving and improving.
