By Chris Veli, Principal Consultant, Rizing

As the world changed, so did your company. Your planned digital transformation project went from “nice to have” to a “must have now”.

It is important to bear in mind that this digital transformation journey that you’ve just embarked on does not stop at the web shop, but is rather the first step to becoming your greatest asset.

In this article we will focus on two key aspects of digital transformation, namely, omnichannel inventory visibility and sourcing. A combination of these two fundamental areas will vastly improve your customers’ online experience as well as following through with a cost-effective and timely delivery.

All of this can be done utilizing your already implemented SAP solutions by introducing an add-on that will very quickly provide value and return on investment.

Omnichannel Inventory Visibility

First, let’s define omnichannel inventory visibility. It could be said that omnichannel inventory visibility is a prerequisite for a profitable and sustainable digital presence. This is the ability to know when and where your stock is, in near real-time, across your organizational channels. Let us look at a few examples of how integral omnichannel inventory visibility truly is.

A customer places an order online instead of going into their local store. When the item is delivered, the customer realizes that the item was not shipped from their neighborhood store, but rather from a different country. With the increasing social awareness of environmental impact, this results in a negative customer experience. Additionally, this scenario has negative revenue impacts. Instead of shipping the product a short distance to the customer, resulting in a faster delivery, as well as being cost effective, the order was fulfilled by an offshore distribution center.

Let us step back for a moment and consider the replenishment strategy for brick-and-mortar stores. Replenishing the stores would be either directly from vendors or distribution centers. This model is simple because your store’s locations are fixed, therefore you would likely need to determine only once where best to replenish any given store from. For example, the closest distribution center would reduce transportation costs, or possibly the vendor might be a better option than the distribution center depending on location.

In the case of online sales, your customers’ locations vary from order to order and even item to item. Therefore, this means that the sourcing strategy that worked perfectly for brick-and-mortar stores is not a viable solution for your web shop.

Ecommerce introduces a brand-new set of challenges. There is the need to facilitate the online sale with the lowest impact to both the web shop and backend systems, while providing the customer with relevant information at the right time to create the best customer experience. Next, you must fulfill the customer’s order as fast as possible while also meeting revenue targets.

How is omnichannel inventory visibility achieved?

First let us run through your existing architecture. SAP S/4HANA is implemented and is responsible for your replenishment and logistic process. Next, SAP CAR POSDTA (Point of Sale Data Transfer and Audit) has been implemented and is responsible for Sales audit and near-real time operational analytics. Finally, the SAP Commerce (previously SAP Hybris Commerce) platform supports your ecommerce solution.

How it Works

Please refer to the below diagram to assist in visualizing the system landscape.

Source: Blogs.sap, 2021

First, the inputs must be defined for the Omnichannel Article Availability calculation. The below inputs are all replicated to SAP CAR, which can be done in near real-time.

Store stock

Starting with the easiest, the SAP S/4HANA replicated start-of-day inventory figure is used as the bases. Next the near-real time omnichannel sales (POS and web shop) are interfaced into CAR and used to calculate the near real-time store stock.

Distribution Centre (DC) Available to Promise Stock

SAP S/4HANA is responsible for all logistics, namely:

• Inventory Management
• Replenishment
  • Incoming orders or shipments
  • Allocations
• Reservations

As these processes are all being executed in real time, SAP S/4HANA is in the best position to determine what stock is available when, this is termed “time series”. The determination of the item’s time series is a product of the Available to Promise check (ATP) function. An example of a time series would be 10 units in stock today and 110 units in 3 days, due to an inbound delivery of 100 units.

On a side note this function has been optimized through parallelization.

Vendor Stock (3^rd Party)

SAP S/4HANA has an innate API that the vendors use to post data, and as a result, this will provide S/4 with the available stock that the vendor can supply, including a time series.

SAP CAR’s Omnichannel Inventory Availability calculation

Let us first recap which data SAP CAR now has on hand:

• Near real-time Omnichannel sales
• Near real-time web shop reservations
• Near real-time Store stock
• Near real-time DC ATP
• Near real-time Vendor stock with time series

The SAP CAR’s Omnichannel Inventory Availability calculation will now apply data source determination per article to identify the relevant data source. For example, Category X is only set to be fulfilled by DC’s, therefore CAR will only include DC’s inventory into the calculation. Next, temporary reservations are added into the calculation to determine a final available quantity.

Omnichannel Inventory Availability and your web shop

Inventory information is provided to SAP Commerce from CAR’s OAA, to ensure the lowest impact to the web shop as well as backend systems. This is achieved by supplying inventory and time series data, as well as the introduction of Rough Stock Indicators (RSI), a kind of traffic light for the SAP Commerce. SAP CAR determines the RSI by using the available inventory and sales to determine stock coverage or sales ratio. For example, a slow selling product with large quantities will have a green RSI verses a fast seller with low quantities represented as a red RSI. Included in the IDoc sent to SAP Commerce is the aggregated inventory figure.

SAP Commerce is now equipped locally with the inventory availability. Although this is data queried within the web shop, performance issues are still a concern. Due to this, SAP Commerce additionally replicates this data into the search index. Now the data is directly available in the search engine therefore optimizing the web shop’s performance. On a side note, it is not recommended to expose a transactional system like a backend SAP S/4HANA or SAP CAR to the webstore for inventory information, this is due to the potential query volume and subsequent system impact.

Additionally, SAP CAR provides an API to expose the near real-time Omnichannel Inventory Availability. This would be used when the web shop executes an availability check.

Real-world example

Let us walk through the process with the customer.

First the customer starts with browsing the online catalog. At this point only the relevant information is presented to the customer whereby the RSI sent from SAP CAR has enabled the web shop to indicate whether the item is in-stock or not.

Next, the customer adds an item to their cart, and at this time more detailed inventory information is required. SAP Commerce will now execute a call to SAP CAR’s Omnichannel Inventory Availability for an availability check. This information upgrades your customer’s experience in your web shop as well as avoiding lost sales scenarios due to out-of-stock situations.

The approach of having the inventory information become more detailed as the customer moves through the online purchase process improves the web shop’s performance. The calculated inventory information displayed to the customer should represent all sellable stock, excluding items already in other customer’s online baskets as well as above mentioned cross channels. This ensures that you as the retailer have positioned your products in the best possible position to make the sale.

The last step in the customer’s journey is the check out, this step is the trigger for sourcing. The fulfillment of the customer’s orders online is more complex than fulfilling brick-and-mortar store orders. The complexity is not only due to the customer’s ever-changing locations, but also ensuring customer satisfaction through quick delivery times while achieving financial objectives.

Before we dive into sourcing, let us review what has been discussed thus far:

• Facilitate the online sale with the lowest impact to both the web shop and backend systems.
• Provide the customer with relevant information at the right time to create the best customer experience.

Next, we will look at: Fulfilling the customer’s order as fast as possible but also meeting revenue targets.

Fulfilling web shop sales – Sourcing

The last area we will focus on is ecommerce sourcing. This is simply the method of how the customer online orders are fulfilled.

The Click and Collect scenario is where the customer would choose to collect the item in-store and the SAP Commerce function, “Store Locator”, will provide the customer with the store-specific available stock. This is done by SAP Commerce executing an API call to SAP CAR’s Omnichannel Article Availability (OAA). OAA will determine the specific product availability at the specific store selected by the customer and this information will then be presented to the customer in the web shop.  Here, the Availability calculation is leveraged, ensuring only available inventory is presented to the customer.

Still following the customer’s progress online, before checkout, SAP Commerce executes a final validation availability check to SAP CAR. This is required for customers that take time finalizing their purchase, which could be hours or even days.

Next, sourcing is triggered by the customer checking out, although this is not true for every order type. In the Click and Collect scenario, the customer selects the source, such as a specific store, therefore the sourcing function is not triggered. It is important to note that regardless of the source, the items in the customer’s basket are set as temporarily reserved, so as to ensure that the same quantity cannot be sold more than once. Once the customer has placed the order, this temporary reservation is released, and the items are flagged as sold.

Now let’s dive into sourcing and start with understanding its components. Each sourcing component is created and managed in SAP Fiori applications. Sourcing will be used for the Click and Ship scenario.

Sourcing Network

First, we define the sourcing network. This network encompasses the available sources defined that are authorized to fulfill an online order. This could mean stores, dark stores, distribution centers or even vendors. Keep in mind that each sourcing network is assigned to a sales channel.

Sourcing Strategy

The sourcing strategies are assigned to a sales channel as well as a sourcing network. This is where sourcing strategies can become relatively complex, so we will stick to the key features.

The building blocks of the sourcing strategy are the following:

• Data sources
  • Stores, dark stores, DCs
• Filtering
  • Exclusions, e.g., exclude a DC that is temporarily closed
  • Source type, e.g., store/DC
  • Max Distance, e.g., the source can only fulfill orders within a 50-mile radius
• Sorting
  • Source type, e.g., first DC then store
  • Distance, e.g., closest source to fulfill
  • Priority
  • Capacity
• Business Objectives
  • Once consignment today
  • As few consignments as fast as possible

 

These concepts in combination quickly become complex, so let’s walk through a simple example:

Customer places order

ORDER
Ship to: Customer’s home
Item A	10
Item B	3

 

Step 1 – Determine Data Sources

Here we can see DC 1, Store 1 and Store 2 can fulfill the full order. We all see that DC 2 and Store 3 can only partially fulfill.

Step 2 – Filtering

The rule configured in this example is to exclude sources that are more than 50 miles from the ship to address, additionally Store 2 has been excluded as this store is temporary closed due to renovations.

Step 3 – Sorting

Here two sorting rules have been applied. We can see that the DCs are first and second source priority. Store 3 is the highest priority store, because this is the largest store within the strategy, then followed by Store 2 and then Store 1.

Step 4 – Business Objectives

This now brings all the above measures into context with the addition of the Business objective to only allow one consignment to be shipped to reduce shipping costs.

Looking at the above table and system logic, it becomes clear not only as to how at a high level the different rules operate in collaboration but also the real value this functionality can deliver.

With that, the final objective can now be checked off:

• Fulfill the customer’s order as fast as possible while also meeting revenue targets.

Conclusion

Going live with a web shop is only the first step in a larger journey. Adding OAA into your SAP landscape by capitalizing on systems and process already implemented adds to return on your investments in both OAA and your existing SAP environment. These functionalities will better help achieve business objectives and keep your consumers engaged and your bottom line in the black.