Optimizing node capacity

The node capacity feature provides the capability to optimize your workforce while meeting customer service goals. The requirements for the node inventory capacity are highly dynamic. For instance, when multiple distribution centers (DCs) are available to fulfill an order, you can aim to avoid overloading a particular DC solely due to proximity or cost considerations. You might choose to utilize a DC until it reaches its quota of Pick or Ship tasks for the day, and then switch to other DCs, even if they are not the most optimal choices from a sourcing perspective. Many fulfilment centers already have contracted hourly labor and fixed operating costs. The cost of idling the workforce can exceed shipping costs.

Similarly, in the ship-from-store scenario, you must prevent overloading store associates with direct-to-consumer orders. If not done correctly, it takes away the store associate’s time from assisting in-store customers and also depletes store inventory that is available to walk-in customers.

The node capacity significantly influences shipment dates because inventory managers can configure the total units, releases, or order lines that can be shipped from a node within a specific timeframe (for example, one day or one time slot).

• Unit: Each ordered quantity adds one unit of capacity to the consumption for an order or reservation.
• Release: Based on the release consolidation template that is defined for an order, consumption adds one unit of capacity for each potential release.
• Line: For an order line, there is a fixed and variable capacity that is based on rules or item definitions.

If you are a System Integrator (SI), and your organization imposes a limit on the number of orders that can be shipped or picked, the IBM Sterling Order Management System offers flexible configuration options to align with your business requirements.

Enabling a node inventory capacity

The IBM Sterling Order Management System begins to factor the shipping capacity as soon as an inventory resource pool is established at a node.

To enable the capacity for a specific node, complete the configuration steps as depicted in the following image.

If you define a resource pool for the Ship delivery method, it is important to also define a resource pool for the Pickup delivery method. Failing to do so might result in order lines with the Pick delivery method being assumed as unavailable at a specific node.

Note: The resource pools for delivery lines are not available because they fall under the product support services.

Availability considerations

The capacity updates in the IBM Sterling Order Management System are driven by the changes in order status and demands. Processes that check capacity availability and update them accordingly are illustrated in the Capacity Updates column of the following table:

Note: After scheduling an order, if you modify the estimated shipment date of a product that belongs to the order, the application updates capacity consumption for a new date, as shown in the table, regardless of the availability.

Optimize node capacity

There are several properties and rules that are available for configuring a node capacity. This article discusses the following case studies and the necessary configurations.

• Nodes with a very low capacity (less than 25)
• Nodes with a medium-high capacity (25-100)
• Nodes with very high capacity (more than 1000)

Case study 1. Nodes have low capacity

Business objective

• Nodes do not have individual capacity limits that are based on the Ship and Pick delivery method.
• Nodes cannot handle extra orders beyond the standard capacity.
• Redirect excess orders that you receive on the current day to a different node with the available capacity, or schedule capacity for the next day.

Design consideration

To meet your business requirement and prevent overallocation, it is recommended that you configure the following properties:

• yfs.nodecapacity.lock=Y
• yfs.nodecapacity.threshold=101

These configurations ensure that the application always locks capacity to check for availability and to prevent overallocation at a given node. This approach is particularly effective when the standard capacity at a node is very low, such as 10 releases per day.

Note: If you configure the yfs.nodecapacity.lock property, the application locks the ShipNode-Date resource pool consumption record. This might result in performance degradation if the order load is concentrated on a few ship nodes. This is because any other transaction for the same combination waits for the previous transaction to release the lock.

Case study 2. Nodes have a medium to high capacity

Business objective

• Nodes do not have individual capacity limits that are based on the Ship and Pick delivery method.
• Nodes cannot handle extra orders beyond the allocated capacity.

Design consideration

To meet your business requirement and prevent overallocation, it is recommended that you apply the following design considerations.

• Capacity locking and thresholds.
  • To prevent the application from sending orders beyond the allocated capacity, set the value of the yfs.nodecapacity.lock property to Y.
  • To ensure that the application locks capacity only when the capacity falls below the specified threshold, configure the yfs.nodecapacity.threshold property. For example, use 20 to 30 for medium- to high-capacity nodes to ensure that the application locks capacity only when it falls below the specified threshold.
• Asynchronous capacity calculation.
• Enhance the Promising API performance by calculating the capacity asynchronously.
• Use a time-triggered agent to calculate capacity in advance and store capacity in the YFS_CAPACITY_AVAILABILITY table.
• During promising calls, you can access data from the YFS_CAPACITY_AVAILABILITY table.
• Cache handling.

To prevent overallocation, configure the following properties.

• yfs.nodecapacity.ignoreCacheForLowAvailability: If you set the value to true, the application reads capacity from the database and ignores the availability that is cached if the capacity falls below the defined threshold.
• yfs.capacityAvailablity.ignoreCacheForUpdateMode: If you set the value to true, the Promising APIs that require capacity availability and intend to update, for example, the scheduleOrder API, reads capacity from the database and ignores the cached availability.
• yfs.capacity.IgnoreCacheBelowThreshold: If you set the value to true, while reading the capacity availability from cache, any capacity below the defined threshold is ignored, and the actual capacity for the resource pool is read.

These considerations ensure that the application efficiently manages capacity allocation and prevents overallocation.

Case study 3. Nodes have a medium to high and locale-based capacity

Business objective

• Nodes do not have individual capacity limits that are based on the Ship and Pick delivery method.
• Nodes cannot handle extra orders beyond the allocated capacity.
• Nodes operate in a different time zone other than the application installation time zone.

Design consideration

Because there isn't an exact limit on the number of orders that the application can send to a node, which can handle extra orders, you can avoid locking of capacity during availability checks. The SI does not need to modify the yfs.nodecapacity.lock property.

For faster capacity availability reads, you also can enable a time-triggered agent to calculate the capacity upfront and store the capacity in the YFS_CAPACITY_AVAILABILITY table, from where the data can be read during promising calls.

To consider a store locale for capacity consumption, set the value of the yfs.useNodeLocaleTimeForCapacityCheck property to Y.

Note: For the yfs.useNodeLocaleTimeForCapacityCheck property to work, configure the Node Shipping Calendar and Resource Pool Service Slot to be in sync. Also, enhance the Calculate Capacity Availability agent to calculate and update the capacity in the YFS_CAPACITY_AVAILABILITY table as per the node's time zone.

Case study 4. Nodes have a very high capacity

Business objective

• Nodes do not have individual capacity limits that are based on the delivery method.
• Nodes can handle a high volume of orders.

Design consideration

In accordance with the business requirements, a node can effectively manage many orders. To determine the average number of orders, the SI should analyze the historical data and the expected demand. If the number is below the business-configured capacity for a day, there should not be any capacity constraint for the node.

Tip: If a capacity is defined for a specific node and due to a significant surge in the demand, the business needs to increase the capacity substantially. The SI should remove the capacity constraint for that specific node by disabling the capacity resource pool record for the node to avoid any contention.

Disable the node capacity

• Do not adjust capacity to infinite.
• To disable capacity, call the usechangeResourcePool API.
• Use the DISABLE_NODE_CAPACITY_FOR_ENT property to disable capacity at the enterprise level.
• If capacity is set to 0 (zero), the capacity consumption record is deleted from the YFS_RES_POOL_CAPCTY_CONSMPTN table.
• To delete the 0 capacity records, run the Purge Capacity agent.

Asynchronous capacity availability calculations

To populate the capacity availability, a background agent keeps track of the capacity definitions, capacity overrides, and capacity consumption. The capacity availability data is stored in the JVM cache to facilitate faster retrieval when needed. This evaluation process is crucial for operations such as RTAM, findInventory, inventory reservation, and scheduling because it allows quicker responses because the capacity availability calculations occur asynchronously.

To ensure accuracy of the capacity availability information, it's essential that the CALCULATE_CAPACITY_AVAILABILITY agent runs continuously to update the YFS_CAPACITY_AVAILABILITY table.

Due to the asynchronous nature of capacity updates, there might be a delay of 30 seconds to one minute, which potentially results in stale records. By configuring these properties, the data gets refreshed every 30 seconds.

Ensure that you configure the following properties.

• yfs.capacityAvailablity.jvmcache.enable=Y
• yfs.capacityAvailablity.jvmcache.refreshInterval=30 seconds

In the update mode, the application provides the capability to use asynchronous availability for non-update API calls with the option to ignore cache. Ensure that you configure the yfs.capacityAvailablity.ignoreCacheForUpdateMode=true property.

Additional consideration for improved performance

Reduce capacity locking

The capacity updates are triggered when Promising APIs are called in the update mode, such as reserveAvailableInventory and ScheduleOrder APIs. By default, the application updates capacity whenever a change is detected during order processing. When a capacity update is necessary, a lock is acquired for the resource pool consumption during calculation and released on the commit event of a transaction. This locking mechanism can lead to prolonged waiting times for other processes that also need to update capacity for the same resource pool.

To improve capacity locking and reduce contention, configure the following properties.

• yfs.persitCapacityAdjustments: The yfs.persitCapacityAdjustments property controls whether capacity adjustments must be persisted immediately upon determination. By default, the value is set to true. It is recommended that you set the value to false. If you do not change the default value, which is true, the capacity updates are pushed to the end of the transaction that reduces the lock contention on the resource pool consumption table.

• yfs.capacity.useMassAdjustCapacityDriver: To further optimize the capacity updates, set the value of the yfs.capacity.useMassAdjustCapacityDriver property to true. The database updates for capacity consumption are pushed on the commit event of a transaction and reduce the lock contention on the YFS_RES_POOL_CAPCTY_CONSMPTN table. Ensure that you set the value of the yfs.persitCapacityAdjustments property to true.

By making these adjustments and configuring the recommended values, you can reduce capacity locking and improve the overall performance of processes that require capacity updates for the same resource pool.

Note: If you modify the default value of the yfs.persitCapacityAdjustments and yfs.capacity.useMassAdjustCapacityDriver properties, ensure that you restart the application and agent servers.

To reserve capacity, the manageCapacityReservation API acquires a lock on the YFS_RES_POOL_CAPCTY_CONSMPTN resource pool consumption table. When the manageCapacityReservation API is part of a large transaction, to minimize the duration of the lock, it's recommended to place the API at the end of the transaction sequence. This locking mechanism prevents parallel processing for transactions that involve capacity updates for the same date and for a given resource pool. Furthermore, when you set the yfs.persitCapacityAdjustments property to true, and the PersistCapacityAdjustments attribute of the manageCapacityReservation API is set to Y, the capacity updates for the manageCapacityReservation API are only applied during the transaction commit phase, and reduces the contention for locks.

Orders with pre-reservations

When the order capture flow is defined as Reserve > Create Order > Schedule, it is recommended to use a unique reservation ID for each reservation call. To use different reservation IDs for different order lines requires more capacity updates during both the reservation and create order processes.

Do not consider capacity for specific Resource pool or Enterprise orders

• Enterprise Rule: To exclude capacity considerations for specific enterprise orders, you can use the DISABLE_NODE_CAPACITY_FOR_ENT enterprise rule. This rule temporarily disables the capacity availability and consumption updates for a defined period for the specified enterprise.
• Resource pool: To disable the capacity consideration for a specific resource pool, use the changeResourcePool API with the flag, IsActive="N". The application considers a node contains infinite capacity and does not check or update capacity for the same node.
• RealTime Availability Monitor: To disable the capacity consideration in the RTAM process, set the IGNORE_NODE_CAPACITY_FOR_RTAM rule for an inventory organization.

Additional consideration for capacity consumption

Distribute load versus consume sequentially

In scenarios where multiple nodes qualify for sourcing an order and each node has potential shipping options, the application typically consumes capacity starting from the highest priority node. The application continues to do so until the capacity for a given node is completely used and later considers fulfilment from other nodes. This approach prioritizes capacity consumption over multiple nodes rather than distributing the load sequentially.

To distribute the load among nodes depending on the fulfilment strategy, the following options are available.

Option 1. Cost based Shipment configuration (Landed Cost > Node Attributes Cost > Capacity Cost > Factor X)

When you select nodes for fulfilment, the capacity consumption is considered. Therefore, a node with high-capacity availability is prioritized over other nodes. This approach automatically distributes the load among nodes within the same distribution group.

Option 2. Consider nodes based on the capacity available percentage

In a multisequence sourcing rule, each sourcing sequence can have an incremental capacity limit. Within the same distribution group, you can configure multiple sequences with the following capacity constraints for each sequence.

• Sequence 1: Consider only nodes that have at least 75% of their capacity available in the next five days.
• Sequence 2: Consider only nodes that have at least 50% of their capacity available in the next five days.
• Sequence 3: Consider only nodes that have at least 0.01% of their capacity available in the next five days.

Until a certain percentage of orders are assigned to a node, the application does not consider other nodes for fulfilment.

Consider reservation as a final capacity consumption

In situations where you want to reserve capacity during reservation and to remain final and unaffected by any subsequent order changes, you can add OrderLineSrcCtrl and suppress any capacity changes. This line-level control suppresses capacity updates during order processing. However, if the order is scheduled by using a different node and capacity consideration is needed, specify Node Control for that specific node.

Additional resources

• Configuring capacity
• Node capacity locking feature
• IBM Sterling Order Management System 20.1 release notes
• Holiday Readiness series webcast