Smart Sourcing
Smart Sourcing
Smart Sourcing
Document number
© 2014 IBM Corporation
Smart Sourcing
Agenda
To improve performance, smart sourcing can be used to dynamically determine the nodes to
consider for sourcing product items.
The current distance based sourcing has performance implications as all the nodes have to
have distance calculated to the address before they are filtered out for consideration.
Reducing the nodes manually can cause situations where an two items will be fulfilled from
two different locations, but they could ideally be fulfilled from a single node. There needs to
be a method of reducing the nodes processed, but still achieving the best option
Example,
Consider a scenario where you have to source product items for 3,000 stores based on
regions and distribution groups. In case of normal sourcing, the distance for all 3,000 stores
has to be calculated to the address before they are filtered out to be considered for sourcing.
Therefore, there might be certain level of performance implications. Reducing the nodes
manually can cause situations wherein same two items will be fulfilled from two different
locations, but they could ideally be fulfilled from a single node.
Advantages
Smart sourcing helps in reducing the nodes to be processed for sourcing, but still provides
the best possible option.
Configuration
Configuration
Configuration
Both Realtime Availability Monitor (RTAM) and node-level RTAM for all nodes considered for
smart sourcing must be running.
Backend Changes
RTAM will insert records in YFS_INVENTORY_ALERTS table. Above three columns will
play key role in determining node/nodes to be selected by smart sourcing.
For example,
Assume that smart sourcing is enabled for 10 nodes; Item1 is sourced from a distribution
group that has 5 nodes and Item2 sourced from a distribution group with 15 nodes. Based
on data provided in YFS_INVENTORY_ALERTS, sourcing will first determine the 10 best
nodes to read inventory for Item2. So, when determining the best options, Item1 is
considered for 5 nodes and Item2 is considered for 10 nodes. If for some reason (either
through constraints, inventory picture, and so on) it cannot find all quantity for Item2, smart
sourcing will be expanded for Item2 to use only nodes that have inventory. Item1 will not be
expanded (2nd sourcing rule detail will not be considered; procurements will not be
expanded, and so on).
Source: If applicable, describe source origin
Smart sourcing uses data provided in the YFS_INVENTORY_ALERTS table to identify the
nodes that must be considered for smart sourcing
If optimizing on cost, then the alert data will be sorted based on the ESTIMATED_COST and
the first configurable number of nodes will be used to determing the sourcing nodes.
For any other optimization type, alert data will be sorted based on internal distance
calculation. The first configurable number of nodes will be used to determine the sourcing
nodes.
Scenarios
Low Availability
The goal of the smart sourcing is to avoid reading and processing inventory for nodes that
do not contain inventory. To do so, the number of alerts with available quantity will be
compared to the configurable number of nodes. If that count is less than or equal to the
configured NUMBER_OF_SMART_NODES, then only those nodes whose corresponding
inventory will be considered. Inventory will read and cached internally to determine which
nodes should be considered
Assume that NUMBER_OF_SMART_NODES is set to 25. Given the alert picture above,
when findInventory is called for Item1, it will check availability for Store001, Store002, and
Store003 only.
Scenarios
High Availability
In this scenario number of alerts in YFS_INVENTORY_ALERTS table will be much more
than configured NUMBER_OF_SMART_NODES.
When the item is available at many nodes, determination of the nodes will be based on the
optimization type.
1. If optimizing on date, then alert data will be sorted based on ONHAND_AVAILABLE_DATE
and FIRST_FUTURE_AVAILABLE_DATE and the first configurable number of nodes will
be used to determine the sourcing nodes
2. If optimizing on cost, then the alert data will be sorted based on the ESTIMATED_COST
and the first configurable number of nodes will be used to determine the sourcing nodes.
3. For any other optimization type, alert data will be sorted based on internal distance
calculation. The first configurable number of nodes will be used to determine the sourcing
nodes
Scenarios
Sourcing Rule consideration
Sourcing Rule Details can be configured to consider only nodes that have onhand inventory,
inventory within the next few days, or all types of inventory.
When all inventory is considered, alert data will be read for nodes that have
ONHAND_AVAILABLE_QUANTITY > 0 or FUTURE_AVAILABLE_QUANTITY > 0
When only onhand inventory is considered, alert data will be read for nodes that have
ONHAND_AVAILABLE_QUANTITY > 0.
When considering within the next few days, alert data will be read for nodes that have
ONHAND_AVAILABLE_QUANTITY > 0 or FIRST_FUTURE_AVAILABLE_DATE <= few
days from now(configured in sourcing rule details).