Migrate IBM Sterling from Global Inventory Visibility to Inventory Visibility

Background

As IBM Sterling™ moves away from monolithic applications to independent, scalable microservices, a new integration paradigm between the legacy system and the born-on-the-cloud system emerges. This article describes key differences between Sterling Global Inventory Visibility services and Sterling Inventory Visibility inventory services. This article also describes Inventory Visibility (IV) replacement services and APIs and how they work.

Global Inventory Visibility

The Global Inventory Visibility (GIV), a component of IBM Sterling Order Management, provides a consolidated view of inventory. GIV helps to coordinate your global inventory across multiple sites, enterprises and participants. Supply chain practitioners can track inventory anywhere, at both internal and external ship nodes. GIV shows a synchronized real-time availability view of virtually all supply and demand from multiple systems, including in-store, in distribution centers, at distributors, at suppliers, and in transit.

image1

Sterling Inventory Visibility

IBM Sterling Inventory Visibility (IV) is a cloud solution that provides a single, real-time view of your inventory that is available to promise your customers. It adapts to your ever-changing environments that have high volumes of simultaneous inquires and reservations from multiple systems requiring mass inventory updates. This highly scalable system improves the accuracy of your customer promises. Being able to provide accuate customer promises helps to increase customer advocacy, grow revenue, and provides faster time to value.

Solution

The following table compares the functionality of Inventory Visibility and Global Inventory Visibility. The remainder of this article describes how to configure and invoke the functions.

Functionality GIV stand-alone IV stand-alone
Custom availability Yes No
Supply types Yes Yes
Demand types Yes Yes
Availability dates Yes No
Time-sensitive availability Yes No
Safety stock Yes Yes [
Availability for purpose Yes Yes
Supply by tag Yes Yes
Availability by tag Yes No
Availability by segment Yes Yes
Vendor managed inventory / Inventory consignment / GTIN Yes No
Multiple inventory organizations Yes No
Inventory sync Yes Yes
Publish availability changes externally Yes Yes
Publish availability snapshot externally Yes Yes
Reservations Yes Yes
Inventory lock contention Yes No

GIV vs. promising

GIV consists of all possible inventory operations, such as synchronization, adjustment, inquiring, and monitoring. GIV does not handle sourcing and optimization. APIs such as getATP and adjustInventory are under the GIV umbrella as they allow you to perform the operations needed to ensure that your availability is accurate and up to date. Promising APIs, such as findInventory, getPossibleSchedules, and scheduleOrder, take into account inventory availability, capacity, sourcing/procurement rules, optimization, shipment date calculations, routing, and many other factors. Together, sourcing, optimization, and promising APIS provide informtion about the optimal fulfillment path for an order.

To identify the API type, look at the package name or the subinterfaces.

Example: findInventory

findInventory-javadoc

Example: getATP

getAtp-javadoc

The findInventory API is part of the OMPApi subinterface under the package com.yantra.api.omp.promising.

The getATP API is part of the INVApi subinterface in the package com.yantra.api.inv.

The APIs in INVApi are part of GIV.

Availability calculation

In general, availability is how much supply is available against known or unknown demands for fulfillment. A supply of items is good only while the items are consumable and some items degrade over time. Supply life span is defined as the time window in which current supply can be used to fulfill demand. Demand also has a life span.

Life span of supply and demand

An important aspect of inventory management is managing the life span of supply and demand. A demand is fulfilled if, and only if, the following conditions are true:

  • The quantity of the supplies is sufficient to fulfill demand.
  • The life span of one or more supplies overlaps the life span of the demand.

Generally, IV and GIV provide the same high-level functionality. The solutions differ in configuration and behavior details.

To ensure that availability calculations are correct, make sure that there is no over-selling. Over-selling is defined as taking more orders than you have inventory. Results of over-selling include backorder and customer appeasement costs.

In GIV, you must configure ATP rules. The rules define forward-consumption, backward-consumption, past-due demand, and past-due supply days. The default values reflect 2 years of searching for inventory. When checking availability, a demand one month from now can consume from supply one week from now. This is because the ATP rules allow for consumption backwards for 730 days. A configuration error might cause demand to not consume from supply. The result is over-selling. In IV, these complexities do not exist. A demand can match to any supply (Figure 1), so long is it does not expire before the demand ship date (Figure 2).

Figure 1 figure1

Figure 2 figure2

Supply-demand type matching

In GIV, when creating a demand type, determine the commitment-level of the demand and which supply types it can consume. A configuration error might cause too much availability and over-selling.

In IV, a new demand or supply type is an extension of an existing type. The new type behaves in the same way as the type that was extended. For example, to represent backroom inventory to be sold online, extend the ONHAND supply type. This ensures that the new type behaves like the ONHAND type without configuring supply-demand matching. Extending the SCHEDULED demand type results in the new demand type being treated the same as SCHEDULED; a promised demand type that can match to both ONHAND and PO_PLACED supplies.

Date breakup

In GIV, availability is presented as availability dates change. For example, a PO arriving next week results in an availability change next week. An on-hand supply that expires next month results in another availability change. These changes over time are calculated upon request. You can observe a date breakup.

In IV date breakup is simplified to how much is available on-hand and in the future, and the earliest and latest dates for each.

GIV and IV handle time-sensitive inventory differently. As time progresses, inventory expires and availability is reduced. In GIV, every API call performs availability calculations in real time based on the data in the database. In IV, availability is precomputed for quick lookup during API calls and only presents the availability at the time when things were computed. IV does not support time-sensitive availability.

Safety stock

In GIV, safety stock is configured for on-hand inventory, or as a percentage for on-hand or future. Configure safety stock at the following levels:

  • Item classification
  • Item classification and delivery method
  • Item
  • Item and delivery method
  • Item and node
  • Item, node, and delivery method

In IV, safety stock only exists as a quantity. It is applied to both on-hand and future, in case of spill-over. IV does not support configuring safety stock at the item classifications or item and delivery method.

In GIV, the on-hand safety stock percentage quantity is not intuitive. To illustrate, consider a scenario in which at the start of the day there is 100 ONHAND inventory and a safety factor percentage of 10%. You might assume that with a safety stock percentage of 10%, you would capture 90 orders. Over time, the on-hand quantity reduces, resulting in a reduced safety stock value. Eventually, the safety stock level becomes 0 or 1. For example:

  • First request, availability was reported as 90. After an order for 10 quantity is captured and fulfilled, there are 90 on-hand.
  • Second request, availability is 81. After another order for 10 quantity is captured and fulfilled
  • Third request shows availability as 72.
  • The cycle continues until 10 ONHAND at which point availability shows that there is 9 available.
  • The last order can be captured for 9 quantity, essentially allowing you to take all inventory but 1.
  • Finally, the 1 on-hand inventory will show that 0.9 is available. Since most retailers do not deal with fractional quantities, this would be truncated to 0 available.

Overall, 99 of 100 units were captured for this item even though 10% was configured as safety stock. If this behavior is acceptable, set the safety stock quantity to 1 in IV.

In GIV, an item can be marked as fulfillment not allowed for picking, shipping, or delivery. However, this has no effect on inventory availability. It only affects whether the order can be captured for that delivery method. In IV, this affects whether the item is available. This configuration can be made at the item; item and node; item and delivery method; or item, node, and delivery method.

Checking availability

In both GIV and IV, supplies and demands can come in various dimensions. Examples of basic dimensions are the item identifier and the location identifier (ship node). Examples of complex or dynamic dimensions include tag-controlled and segmentation. Availablity request checks are always made in the context of the demand that is going to be placed for that check. For example, when checking availability on a website, the context is placing an OPEN_ORDER demand. Therefore, availability is based on how much is available for that demand type.

In both GIV and IV, demands come with a commitment level. Availability is provided for three purposes:

  • Available to sell
  • Available to schedule
  • Available to release

Based on the purpose, certain demands are ignored. For example, available to sell includes all orders that are captured, back ordered, scheduled, and released. Available to schedule include orders that are already scheduled and released, but ignores demands for back ordered or created orders.

In GIV, you can customize availability calls, but the default demand and supply type configuration support most cases. The following table shows input demand type by purpose.

Purpose GIV IV
Available to Sell OPEN_ORDER OPEN_ORDER
Available to Schedule SCHEDULED SCHEDULED
Available to Release DEMAND_FOR_RELEASE DEMAND_FOR_RELEASE

The GIV getATP API defaults its input demand type to OPEN_ORDER. The equivalent IV API, POST availability/node, also defaults its input demand type to OPEN_ORDER. In GIV, any demand type can be used as input. The configuration of that demand determines availability. In IV, the supported tyes are: only OPEN_ORDER, SCHEDULED, and DEMAND_FOR_RELEASE. These types reflect the different tiers of availability needed for order capture (OPEN_ORDER), scheduling an order (SCHEDULED), and releasing an order (DEMAND_FOR_RELEASE).

Tag-controlled and segmented inventory

In GIV, you can request availability for a specific tag. Availability is calculated based on how much is available for that specific tag. If no tag is specified, then availability is calculated across tags. Segmentation is a little different. The segmented inventory inquiry is the only inventory that’s considered with the exception of whether that availability should also include unsegmented. In IV, checking availability for a specific tag is not supported. Only availability across tags is supported.

Depending on the Sterling Order Management version, the system might update supplies/demands to represent untagged inventory with tagNumber as “||” or ” “. Keep this in mind when syncing supplies to IV. If you use the phase 1 adapter, where GIV inventory is replicated to IV, then GIV is the master inventory record. In this case, there should not be any issues. If you are using a different phase or a custom implementation, such as external inventory, consider how the tagNumber is used by GIV. To change the tag number generation GIV, implement the YFSGetTagNoUE user exit.

Also, segmentation only is supported for that specific segment and does not consider unsegmented or across segments.

Multiple inventory organizations

In GIV, inventory is maintained at an inventory organization. At that organization, all inventory is shared to itself only. Inventory from another organization is not considered. In IV, there is no concept of inventory organizations – all inventory is visible. The result is identical to having one inventory organization in GIV. The GIV getATP and adjustInventory APIs take OrganizationCode as input. IV APIs only use the tenant identifier.

Only use multiple inventory organizations in complex scenarios such as when two organizations share itemIds or shipNodes.

Inventory consignment is a concept in which inventory availability of one inventory organization can be accounted for as part of inventory availability of another inventory organization. The inventory organizations participating in the inventory consignment program are called consumable inventory organizations and consuming inventory organizations. Products are linked to each other based on their Global Trade Identification Number (GTIN). In GIV this functionality is fully supported, IV offers limited support.

To support inventory consignment in IV, you can use the relationship API. For example, assume Vendor1 has a product with id of 1024 with a GTIN of A10. Vendor2 has a product with id 3829 and a GTIN of A10. In IV, the definition of A10 (the GTIN) has children 1024 and 3829. Whenever supply/demand changes for 1024, the availability is updated for A10. The only limitation is that reservations are not supported for A10. The relationship functionality is intended to represent items with variations. Orders are not placed for the product, order are are placed for SKUs. This example is a conceptual means that you could use – is not a recommended approach.

Inventory synchronization

Typicallya with inventory synchronization, a file is produced that is grouped by 100 items. In GIV, a field called YantraGroupID represents the entire batch, which could reflect hundreds of thousands, or millions of items. Each grouping of 100 items is processed for synchronization. Each batch of 100 items is passed along to GIV loadInventoryMismatch API which dumps the data into an internal temporary table. At the end of the file, a GIV syncLoadedInventory API call is made for that YantraGroupID. Then, the supply and the temporary tables are compared. The results of the deltas are processed asynchronously in batches of 1000 to GIV. The adjustInventory API performs the adjustments. In GIV, the data is provided by using IBM MQ. In IV, the data is provided using REST API calls. In most cases, the delta between what’s in the input versus the database is less than 10%.

In some implementations, where the delta might be more than 50%, the GIV adjustInventory API is invoked directly with AdjustmentType ABSOLUTE. This can give better throughput as the time spent to compare and create deltas is longer than the time required to apply them immediately.

Regardless of whether you use GIV syncLoadedInventory API for 10%, or you use GIV adjustInventory API for 100% of changes, the IV PUT supplies API can handle both types of requests. The same chunks of 100 items can be passed to IV directly, where each supply input has a source to represent the time the snapshot was taken for that supply.

A challenge faced in GIV is the potential contention with changes that occurred during the sync operation. For example, the snapshot process started at 1am and completed at 1:30am. This snapshot is fed to GIV right after and let’s assume it took until 5:30am to complete. Between 1am and 5:30am, there may have been inventory changes made in the order management system that is not reflected in the snapshot. To address this, a PublishedTime field exists in the input to syncLoadedInventory. If any supplies were updated after this time, then the sync will not perform an update for that supply and raise an event instead. Since the snapshot takes a period of time to even generate, the integration has to make a decision to be optimistic and pass 1:30am or pessimistic and pass 1:00am. When IV starts receiving the synchronization calls at 1:30am and completes by 5:30am, IV knows when the sync was exported due to the source’s attribute in the input. When actually processing the sync, any changes that happened after that time are replayed on top of the sync ensuring that no reprocessing needs to happen manually.

Publishing to external systems

In GIV, to publish to external systems you must enable the Realtime Availability Monitor (RTAM) agent. The OMS agent framework collects jobs to work on in batches, then executes the jobs. When the jobs are complete, the next batch is collected. If nothing is collected, the agent sleeps for a configurable amount of time and then restarts. Configure the RTAM agent using either Activity or Sync mode.

In Activity mode, all processes in GIV that change inventory create a database record to notify the agent of work to be done. RTAM will analyze this table for work and calculate how much is available at the nodes and distribution groups. Through OMS’s event framework, an event is raised which can have the message put into an external queue. In sync mode, RTAM will fetch all the data it already calculated and republish the data.

In IV, a similar concept exists. IV publishes availability changes as and when they happen. Unlike OMS agent framework, there’s no polling of a system to detect changes. As changes are made the data is streamed into the external systems. That external system can be a Cloud Object Storage (for example IBM COS) or a https webhook. An IV publish_all API allows on demand publishing of existing data to the same external storage. Both GIV and IV provide availability at a node and distribution group level, sometimes referred to as network level.

Reservations

In GIV, all reservations are made against a node. During reservation calls, availability are checked before placing the reservation for the item-node, but capacity is not checked. After a reservation is placed, a demand is placed on its behalf to affect availability. That reservation may have expiration date associated to it, but it does not expire automatically. A separate Inventory Reservation Purge Agent must be run that will clean up the reservation and update the demand it created.

Node level reservations

In IV, reservations can be made against a node or a distribution group. When made against a node, availability at the node and the distribution groups are always checked. Capacity is not included in this, much like GIV. Partial reservations are always allowed. If that’s not desired, the partial reservation can be deleted by id or reference using the IV DELETE reservations API. IV reservations do not affect demands and they expire automatically. This node-level reservation affects the availability of the node and the availability at the distribution group.

Distribution group level reservations

If a distribution group level reservation is made, only the distribution group is checked for availability before allowing the reservation to go through. However, distribution groups sharing nodes may cause undesirable behavior. Distribution group level is best used when the node is not determined up front and sourcing is not required. This may be useful in simple cases. For example, you have a distribution group that represent Germany and another than represents France. For customers shipping from France, the France group is used.

If there’s a need for taking into account capacity or sourcing optimizations, then OMS provides a Promising API that does both: reserveAvailableInventory. This promising API will check sourcing, product availability, node capacity, shipment date constraints, optimization, and determine the node to reserve. With OMS using GIV, the inventory reservation is created for the most optimal node. With OMS integrated with IV, the reservation is made against IV.

Reservations impact on available to sell

One of the major differences between IV’s reservations and GIV’s reservations is how they impact the availability for scheduling. The default commitment level of GIV’s RESERVED demand is that of a promised demand. Without getting into the nitty-gritty of what that means, it’s the equivalent of a SCHEDULED demand. This means RESERVED demands affect how much is available to sell and how much is available to schedule. In IV, reservations by default only affect how much is available to sell. It does not impact how much is available to schedule.

This is best explained in an example. Let’s assume there’s only 1 ONHAND inventory, and therefore only 1 available to sell and schedule. Assuming an order is captured for this item without a reservation against the ship node, both GIV’s and IV’s available to sell is 0, the available to schedule is 1. Where things may behave unexpectedly is when a reservation is made. During GIV reservation, availability is considered as 1, since it’s the same as how much is available to schedule. A completely different customer may make a reservation and have it succeed. At this point, the available to sell will remain 0 and available to schedule will now be 0. The existing order when attempting to schedule will back order. What this illustrates is that GIV prefers giving availability to reservations over orders that are already captured. During IV reservation, the reservation would fail since its availability is checked against available to sell.

The GIV reservation APIs default the DemandType to be RESERVED, however IV does not provide the availability in that manner. You’ll need to provide either OPEN_ORDER or SCHEDULED DemandType in the input to the GIV API. It’s recommended to use OPEN_ORDER so reservations are taken against how much is available to sell, but if prefer the GIV behavior of having reservations steal inventory from orders already captured, you can provide SCHEDULED.

Avoiding lock contention

In order for GIV to provide optimal shipping location when determining fulfillment of an order, GIV will place a lock on YFS_INVENTORY_ITEM to block any other thread for this item from seeing the availability. This ensures the decision made during scheduling/reservations to stay the same by the end of the transaction API call. As a result, when a hot selling item comes into the system, OMS as a result can come to a crawl due to lock contention across multiple threads for the same SKU.

GIV has a complex system of Hot SKU properties, whose goal is to avoid locking when there’s plenty of inventory. The rule of thumb is if there’s plenty of inventory, avoid locking and take the risk of over-scheduling. This document will not go into the details of all the controls that Hot SKU properties provide, but there are many controls around when to avoid locking and what to do in certain situations.

IV deals with over-scheduling in a completely different way. IV does not perform any kind of locking or blocking of threads. Each change to inventory is performed as a delta change and not an absolute change to avoid contention. More specifically, reservations will check availability and block that inventory with a reservation. If the availability before placing the reservation is below the high threshold, then after placing the reservation availability will is rechecked including the newly created reservation. If the availability goes negative, the reservation is considered a failure and is rollback.

For example, a single unit is left at a node. Two customers make the reservation call to block the last unit. Each will check availability which at the time of the check it was there. And then both will block and recheck. If the recheck shows 0 (maybe for the first order), that will succeed. If the recheck shows negative, then it will fail. At least one will fail in this example. There may be an edge case where within the same 10ms both calls are being made where both will fail.

Migrating to Inventory Visibility

Phase 1: Copy of inventory

Given the similarities and differences between the two systems, migration is pretty straight-forward. A phase 1 adapter had been released in 2018 which replicates data in OMS to IV. With phase 1 enabled, you continue to use the GIV APIs to synchronize inventory, monitor availability, check inventory and so on. You can slowly move away from GIV APIs to perform inquiries or to publish.

In this phase, IV has a copy of the inventory picture. OMS APIs will continue to use GIV internally, which will fetch data from the YFS_INVENTORY_SUPPLY and YFS_INVENTORY_DEMAND tables in GIV. However, for your different selling channels instead of relying on RTAM publishing and keeping up caches, you can move to making realtime IV API calls for your selling channels and/or using the IV publishing mechanisms.

This phase also provides an inventory synchronization agent that takes the data from GIV and calls the respective PUT API in IV. This can correct any situations where inventory goes out of sync either due to loss of messages or other failures. This agent can only functionally work if the Inventory Purge agent is configured to honor purge window. If the respective supply or demand of 0 quantity gets purged, the sync agent will not be able to sync IV to 0 for the respective row. It’s important to have a purge criteria large enough to support a window of syncing. For example, if purge criteria is 1 day, but the sync agent is configured to sync once a week, those rows that get purged for 0 will never be re-synchronized in IV. This is only an issue if this particular row happened to be out of sync.

oms-iv-phase1

Phase 2: Inventory replacement

After data is replicated in both systems and you is ready to switch, a phase 2 adapter can be enabled which will cause OMS to stop using GIV internally and invoke IV APIs instead. The overall goal of the migration for phase 2 is to allow you to continue using GIV APIs for the short-term, as those APIs will just proxy the request to IV. For example, calling getATP would proxy the request to IV to produce the output of getATP. But ideally, those calls should have changed to IV calls before moving to phase 2.

Scheduling in this phase will check availability for the nodes configured in sourcing rules without any locking and make its decision on the most optimal location. Upon deciding the final node, a temporary reservation is created in IV to block the inventory. If there are two orders being scheduled at the same time for the last unit, one order will have their reservation fail. In this case, OMS will choose to backorder this order, and after 30 minutes the scheduling agent can try this order again with latest availability picture.

Regardless of whether GIV or IV is used as the inventory service, promising APIs such as findInventory and reserveAvailableInventory will continue to work.

oms-iv-phase2

Configuration replication

Transactional data is replicated automatically from GIV to IV in either phase. However, not all configurations are not automatically replicated. Such configurations must be customized to replicate automatically by utilizing the IVInvokeRestAPI Service.

GIV entity Phase 1 automatic replication Phase 2 automatic replication
Ship node No Yes for production and pre-production environments. No for all others.
RTAM distribution groups No No
Satey stock No No
Supply types No No
Demand types No No
Inventory node controls No No
Capacity depleted No No

Conclusion

The migration from GIV to IV is intended to have the least impact possible. As discussed, IV provides the same functionality as GIV but in different ways. After reading this article, you should understand the key differences between GIV and IV. Not all implementations can use f IV due to the limitations described in this article. Consider opening a request for enhancement, if you need a specific GIV feature that is not yet available in IV.