The word “real-time inventory” is getting kicked around a lot these days. Retailers and brands that were first hit with supply disruptions, and now contending with overstocks, are looking for ways to optimize their enterprise inventory management and network fulfillment.
The first time I heard “real-time inventory” was over 10 years ago, when I was working on a multimillion-dollar, multi-year digital transformation project at a direct-to-consumer (DTC) consumer packaged goods (CPG) company with an e-commerce ordering channel. The systems being introduced were an enterprise e-commerce platform (ECP) and an enterprise resource planning (ERP) system, which, at the time, were both leading companies and systems in their respective categories.
One of the issues the company wanted to rectify with these systems when placing online orders was stockouts. The legacy systems that were being replaced had no mechanism to stop anyone from ordering an item that was out of stock. The result of this was two-fold: disappointed customers that only found out when they received their order that there were items missing and manual workarounds to ship these items when they did become available. The decision was to implement an available-to-promise (ATP) system depicted as “real-time inventory.” If a product was out of stock, the ECP wouldn’t allow you to order it. Makes sense, right?
Being assigned the task of communicating and promoting this new state-of-the-art feature, I wanted to learn more about how it worked. I remembered hearing that it’s not quite real-time inventory since the ERP cannot update the ECP in real time; it would take too long for the site to refresh. So, what it really was doing was providing a point-in-time snapshot of ATP inventory (perhaps every hour). Was it better than the system it was replacing? Most definitely. Was it really real-time inventory? The answer to that is ... maybe.
I know what you’re thinking, “how can it be labeled real-time inventory if it’s not real-time inventory?” Because even after 10 years, this is still the same way that some order management systems, ERPs and ECPs update inventory. It’s not a live feed — it’s a point-in-time snapshot. Some even call it “near, real-time inventory.”
Real-world Impact
If you order a pair of jeans and you just happen to be in that in-between time when the site says the item is in stock but in reality, it wasn’t updated, then your order might get cancelled down the line. Alternatively, you may go to the store expecting to find the item, and it’s not there. Let’s take the example of a retailer promotion, say there’s a 50% off sale on a popular item. The higher the demand for the item, the higher the likelihood of a stockout. If the shopper is unaware that the product is actually out of stock when it’s ordered (or when they leave to go to the store), the result is a bad customer experience and the potential loss of a future customer. The more critical the item for customer satisfaction, the higher the need to ensure a shopper knows whether it’s available or not before taking purchasing action.
The data in the order management system (OMS), which feeds the ECP, is only as good as the data it receives from its feeder systems. If store inventory, which can be consumed by online orders or by the point-of-sale (POS) system, is primarily fed to the OMS by an ERP, the POS system needs to update the ERP first before the OMS gets it. That means there’s a lag between the time the POS consumes inventory, transfers it to the ERP and then the ERP transfers it to the OMS. That lag could be minutes, hours or even a day. Plus, it’s usually a clunky file-based data transfer. Does this current arrangement work? Yes, for the most part it does. Is it optimized for frictionless commerce? Not anymore.
Real-time Inventory APIs
With the integration of representational state transfer (REST) application programming interface (API) architecture within an OMS, we can now achieve true (not near) real-time inventory that can be displayed on any one of your selling channels or fed to any other back-end system (e.g., planning and allocation, replenishment, workforce management, etc.)
The reason for this is an API can update inventory as it is consumed. That means if an order is fulfilled at the warehouse, the warehouse management system (WMS) can call the OMS API and consume the stock, which will be updated in the OMS inventory hub, instantaneously. If an item is purchased at the store, the POS can call the OMS API and consume the stock, which will be updated in the OMS inventory hub, you guessed it, instantaneously. There is no longer an ERP middleman slowing things down.
This is how you get true, real-time inventory. But of course, there’s a catch: Depending on your sales and order volumes, having true real-time inventory could mean more API calls than your system is used to. If you’re ready for this, by all means, go for it (with an OMS vendor that can provide real-time inventory APIs). If you’re not sure, there’s always a balanced approach, with either bulk API updates or instantaneous updates only for select stock keeping units (SKUs) (e.g., your best sellers). With bulk updates and/or select SKU updates, you still eliminate the middleman and clunky file-based data transfers but these updates can be planned out based on your schedule and business needs.
Conclusion
Whether you go for true, real-time inventory with instantaneous updates or a more conservative bulk approach, REST APIs are the future of order management and inventory visibility. They provide flexibility, speed, accuracy and the ability to seamlessly integrate with other systems in your retail tech stack to provide a frictionless commerce experience.
