Skip to content

Hey, I'm Gyanesh Samanta, a Product management professional based out of India, I work at the intersection of Data, Product and AI.

0
0
0
0
Product Management
Loading 000%
All editions
Gyanesh on ProductJan 1, 200013 min read

A detailed look into OMS (Order Management Systems, post purchase)

In today's hyper-complex commerce environment, characterised by proliferating channels and escalating customer expectations, the ability to seamlessly orchestrate the entire order lifecycle is paramount. For enterprises navigating this…

In today's hyper-complex commerce environment, characterised by proliferating channels and escalating customer expectations, the ability to seamlessly orchestrate the entire order lifecycle is paramount. For enterprises navigating this landscape, a robust Order Management System is not just beneficial, it's foundational. This newsletter edition takes a deep dive into one of the industry's powerhouses: IBM Sterling Order Management System (OMS).

We'll move beyond generic concepts and explore how Sterling OMS specifically tackles the challenges of modern commerce. Drawing directly from its architecture and capabilities, we will dissect the intricate journey of an order within the Sterling ecosystem, unpack the intelligence behind its Distributed Order Management (DOM), demystify critical processes like scheduling, sourcing, and reverse logistics, and understand the configuration levers that allow businesses to tailor the platform to their unique needs. Whether you're actively working with Sterling OMS or seeking to understand its strategic value, join us as we explore the engine driving sophisticated commerce operations.

Check out more about Sterling OMS here: Sterling OMS

IBM Sterling OMS: The Enterprise Nerve Center

IBM Sterling OMS is engineered to manage the complexities inherent in businesses serving buyers across multiple channels while simultaneously supporting diverse fulfillment processes. It acts as the central nervous system, providing a unified platform to connect disparate systems (e-commerce, POS, WMS, ERP, logistics partners) and orchestrate the flow of orders with intelligence and precision.

Key business applications enabled or enhanced by Sterling OMS include:

  • Distributed Order Management (DOM): The core intelligence for network-wide fulfillment.

  • Global Inventory Visibility: Real-time (or near real-time) view of stock across all locations (warehouses, stores, suppliers) – crucial for accurate promising (ATP - Available to Promise).

  • Catalog Management: Managing product information relevant to the order process.

  • Logistics Management: Interfacing with shipping carriers and managing transportation details.

  • Supply Collaboration: Facilitating interactions and order flows with suppliers/vendors.

  • Reverse Logistics: Efficiently managing returns, exchanges, and refurbishment processes.

  • Application Platform: Providing the tools and extensibility to configure and customize workflows.

Tracing the Order Journey Within Sterling OMS

Let's follow an order through the typical states and processes managed within the IBM Sterling framework, understanding the specific purpose and capabilities at each step:

  1. Draft Order State: An order captured via any channel (Kiosk, POS, Web, App) often enters Sterling as a draft. This initial state, before confirmation, allows crucial flexibility for modifications or abandonment scenarios, managed within Sterling's configurable pipelines.

  2. Order Created / Confirmed: Once confirmed, the order is formally created in Sterling, containing essential data like customer details, order lines (items, quantities), and payment information. This triggers rigorous Order Validation rules configured within Sterling: Basic Checks: Verifying seller/buyer identities against enterprise definitions, validating customer/vendor IDs, ensuring items belong to the correct catalog/assortment. Additional Sterling Checks: Configurable rules can check customer blacklist/greylist status, validate online payment transaction IDs, and perform initial stock serviceability checks. This robust validation ensures data integrity before the order progresses.

  3. Scheduled: This is where Sterling's intelligence shines. The system determines which fulfillment Nodes (Sterling's term for locations like warehouses, stores, etc.) have the inventory/capacity. The Schedule Order Transaction executes rule-based logic to assign order lines optimally and determines the Promised Delivery Date (PDD). Scheduling runs can be configured as manual or time-triggered events.

  4. Released: Sterling transitions the order line to 'Released' when it's formally assigned to a specific fulfillment Node. This signifies a commitment to fulfill from that location.

  5. Sent to Node: This state indicates that the order release details have been electronically transmitted from Sterling OMS to the designated Node's system (e.g., a WMS or store fulfillment app), instructing it to commence physical processing.

  6. Shipped: The Node updates Sterling once the order physically departs, completing this phase of the Sterling-managed lifecycle. (Delivery confirmation is typically handled via carrier integration).

Managing Change: Order Modifications in Sterling

Customer requests for changes are inevitable. Sterling OMS provides configurable Modification Rules to govern how and when orders can be altered. Common modifications include changes to quantity, attributes (color/size), payment method, shipping address, delivery dates, or shipping mode.

  • Modification Type: Defines the nature of the change (e.g., adding an order line).

  • Modification Level: Specifies where the change applies (Header, Line, Release, etc.).

  • Modification Status: Tracks the processing state of the modification request.

Firms configure these rules within Sterling to define permissible changes (often allowed until 'Shipped' or an earlier status) and associated processes, balancing customer flexibility with operational stability and cost control.

The Engine Room: Sterling DOM, Scheduling & Sourcing

Sterling's Distributed Order Management (DOM) capabilities are central to handling modern fulfillment networks. It excels at:

  • Orchestrating Fulfillment: Coordinating across warehouses, stores (enabling BOPIS/SFS), 3PLs, and suppliers.

  • Providing Inventory Visibility: Offering that crucial single view of ATP across the network.

  • Intelligent Sourcing: Determining the optimal fulfillment location(s) using sophisticated logic.

Order Scheduling in Sterling: Considers constraints like inventory, resource capacity, node locations, and customer requirements to fulfill orders efficiently. It’s the brain making the initial fulfillment plan.

Order Sourcing in Sterling: This process determines where products should ship from or be delivered. Key considerations configured within Sterling include:

  • Item being shipped, destination.

  • Real-time availability across potential nodes.

  • Minimizing shipment splits (respecting "ship complete" constraints).

  • Node prioritization rules.

  • Capability to perform services or Value-Added Services (VAS) like gift wrapping.

Configuring Sourcing Logic: Setting up sourcing in Sterling involves careful consideration:

  • Leveraging or modifying existing sourcing rules.

  • Ensuring accurate inventory data feeds (internal or external).

  • Defining Distribution Groups: These are crucial Sterling constructs that group Nodes (by region, enterprise, capability, supplier status, etc.) and are linked to sourcing rules to streamline fulfillment assignments for different item types (product, service, procured).

  • Setting Notification Rules: Sterling uses a hierarchy to determine how far in advance an order should be scheduled before its expected ship date, ensuring nodes have adequate processing time: Item Level Notification (Highest Precedence) > Node Level Notification > Organization Level Notification (Lowest Precedence) Formula Example: Notification Date = Expected Ship Date - Max Working Hours - Advanced Notification Time.

Keeping Watch: Monitoring & Exception Handling in Sterling

Sterling OMS provides robust tools for Order Monitoring to proactively identify and manage exceptions:

  • Status Monitors: Configured to flag orders that remain in a particular status beyond a defined time limit (e.g., 'Scheduled' for too long).

  • Process Monitors: Set up for specific pipelines to check if order documents meet defined conditions, alerting to potential process deviations.

  • Holds: Functionality to manually or automatically prevent order processing or specific modifications based on defined criteria (e.g., fraud review).

  • Alerts: Direct notifications to users or designated alert queues when an order requires manual intervention.

These tools empower users to manage by exception, ensuring orders flow smoothly and issues are addressed promptly.

Financial Flows: Payment Processing in Sterling

Sterling OMS integrates payment functionalities, typically including:

  • Payment Authorization: Verifying funds availability.

  • Settlement: Capturing funds.

  • Invoicing: Generating invoices based on configured rules (e.g., upon shipment, upon collection). Organizations can configure Payment Rules within Sterling to align these processes with their financial policies.

Closing the Loop: Reverse Logistics & RMA in Sterling

Managing returns effectively is crucial. IBM Sterling provides dedicated Reverse Logistics capabilities:

  • Return Cycle Management: Handling the process where delivered items are returned (due to cancellation, damage, exchange, etc.).

  • Return Merchandise Authorization (RMA): Sterling manages the authorization process, allowing sellers to approve return requests based on defined policies and customer-submitted details.

  • Return Process Orchestration: Sterling guides the returned item through inspection, disposition (restock, refurbish, scrap), and financial reconciliation (credit memos). The platform provides visibility into each step of this often complex reverse flow.

Applying Sterling: The Reusable Beverage Bottle Scenario

How might one configure IBM Sterling OMS to handle the reverse logistics of reusable beverage bottles?

  1. Modeling Returnable Assets: While perhaps not serialized, configure a specific item type in Sterling for "empty bottles" or "returnable crates." Inventory tracking would monitor quantities of these empties at different nodes (retailer backrooms, collection centers, cleaning facilities).

  2. Return Orders/RMAs: Utilize Sterling's RMA functionality or create specific "Collection Order" types, potentially linked to deposit values, initiated by retailers or collection agents.

  3. Logistics Integration: Configure Sterling to interface with logistics partners specifically for planning and tracking efficient empty bottle pickup routes.

  4. Node Workflows: Define processes within Sterling (or integrated WMS/Node systems) for receiving, validating counts, sorting, and processing returned empties at designated facilities.

  5. Financial Adjustments: Configure Sterling to trigger appropriate financial transactions (e.g., deposit credits back to retailers) upon successful return validation.

  6. Inventory Updates: Ensure processes are in place to update the "empty bottle" inventory upon receipt and, crucially, update the "sellable filled bottle" inventory after cleaning and refilling, all tracked within Sterling's inventory visibility modules.

This demonstrates how Sterling's flexible data modeling, configurable workflows, and robust inventory management can be applied even to unique circular economy challenges.

Conclusion: Sterling OMS as a Strategic Enabler

IBM Sterling Order Management System is more than a tool for operational efficiency; it's a strategic platform for enterprises aiming to thrive in complex commerce environments. By providing deep visibility, intelligent orchestration, robust exception handling, and extensive configurability across the entire order lifecycle – from initial capture through fulfillment and reverse logistics – Sterling OMS empowers businesses to:

  • Deliver superior, consistent customer experiences.

  • Optimize fulfillment costs and network efficiency.

  • Increase profitability through accurate promising and effective inventory utilization.

  • Enhance brand loyalty by reliably meeting commitments.

  • Support sustainability goals through effective reverse logistics management.

For organizations leveraging IBM Sterling OMS, mastering its capabilities and configurations is key to unlocking significant competitive advantage in the demanding world of modern commerce.

IBM's sterling order management manages the complexities of businesses serving buyers that use multiple channels and those supporting the fulfilment processes simultaneously. Some common business applications:

  1. Distributed Order Management

  2. Inventory Visibility (in-stock, stock outs)

  3. Catalog Management

  4. Logistics Management

  5. Supply Collaboration (Vendor relations)

  6. Reverse Logistics (Returns and Exchanges)

  7. Application Platform

Role of OMS in supply chain and commerce in positively impacting an array of different industries:

A typical Order Lifecycle looks like this:

On the other end, a order fulfilment cycle consists of all the actives from draft order to shipped order. This order document can be a sales order or a service order.

Order Fulfilment Lifecycle:

What exactly is a draft order state?

Orders created through any channels as Kiosk, POS, Web, app which is the first stage of the order until it is confirmed, generally this order can be modified until it is confirmed.

Once the order is confirmed, it moves to the "Order created" stage. Here the order contains all necessary information as customer details, order lines (items and requested quantity) and payment info.

The system further determines which Nodes have sufficient inventory or capacity to fulfil the order, here the order is "Scheduled". A rule based scheduling system decides where to source the inventory. At this stage the PDD (Promise Delivery Date) is assigned.

When the order is released to a node, it is marked as "Released"

Before the order can be shipped it is marked with the "Sent to Node" state, stating that the order is sent in the form of an order release to the node.

Finally, the order is shipped to the customer from a specific node, based on the mode of fulfilment (delivery, in store pickup) the node fulfils the order, once the order is shipped this state is achieved.

Note, order shipped is not equal to order delivered.

What is a Distributed Order management system then?

When a system has the capability to configure all types of customer orders (whether product or service).

CTAs in a distributed order management system:

  1. Manage and Monitor orders from all channels and coordinate the fulfilment process across the firm.

  2. Inventory availability

  3. Rule-based dynamic allocation across fulfilment nodes/locations.

  4. Single order repository for customers, suppliers to get real-time order information through the lifecycle.

  5. Flexibility to handle multiple order fulfilment processes in a single instance

  6. Handle order processes with event-driven and rule-based order coordination.

What makes up a Sales Order?

Order Header: All of the order lines in an order. Contains information pertaining to attributes as billing address and payment information. Attribution as order identification, creation, shipping and financial information.

Order Line: Information about each individual order line

Order Release: All of the order lines that were released to ship node.

Line Relationship: Group order item lines together in an order. Generally used to group order item lines with same item but different fulfilment rules or items that are closely related to each other in a kit.

Order Validation:

Criteria definitions for basic order validation:

  1. Verify seller on the order document by the one allocated by the firm.

  2. Verify the buyer on the order document is the same as the order document by the enterprise

  3. Validate that the customer ID on an order is defined

  4. Validate that the vendor ID on an order is defined

  5. Validate that product items on the order belong to the catalog / assortment offered.

Additional Checks:

  1. The customer ID hasn't been blacklisted / greylisted by the organisation for excessive returns / cancellations

  2. If transaction was made through an online payment procedure, the transaction ID is valid.

  3. The stock levels are serviceable for the order quantity associated in the order line.

Order Modifications:

Most orders would flow through an order management system without the need for intervention from a Customer service rep, however at times modifications might be requested by the customer, some of the most commonly requested modifications are:

  1. Change in order quantity

  2. Change in order attribute (different colour / size)

  3. Change in payment method

  4. Change in shipping address

  5. Change in Delivery dates

  6. Change in shipping mode (1-day, standard, 7 day, scheduled delivery)

Generally an order modification is allowed until the order is shipped to the customer.

Firms may decide to have a set of modification rules governing the modification of a placed order. This reduces the number of requests in terms of modifications and allows to firm to reduce costs associated with a cancelled order / modified order.

Modification type: Details the modification on the order document, for e.g adding an order line to an order.

Modification level: indicates the level at which the modification type is carried out, levels include but are not limited to: header, line, release, release line, negotiation, negotiation line, shipment, and receipt.

Modification status: generally outlines the particular processing status of the modification request.

Order Scheduling

Order scheduling is typically implemented in 2 forms: Manual runs, time-triggered runs.

Some other popular types of scheduling might be around inventory levels or seasonal demands or demand forecasts.

Scheduling generally considers all possibilities and constraints as:

  1. Inventory

  2. Resource

  3. Geographical Location of Shipment nodes

  4. Customers to fulfil an order

A Schedule Order Transaction:

Order Sourcing

Sourcing is the process of determining the location from which a product is shipped or delivered. It is generally used to determine the locations from which a product can be replenished to a particular delivery node from which the final delivery is to be made.

Selection of the shipping location is typically based on:

  1. What is being shipped

  2. Ship to location

  3. Availability at different locations

  4. Total number of shipments required to complete the request

  5. Prioritisation of nodes

  6. Customer specified constraints (ship together)

  7. Ability to perform services for a work order

  8. Ability to perform VAS (Value added services) as gift wraps

Sourcing Rules: A set of rules governing the procurement / shipment / delivery of a product / service

What should you consider before setting up sourcing rules?

  1. Are there any existing sourcing rules?

  2. Is inventory information available to the system?

  3. Is the inventory maintained externally?

  4. Have you defined a default distribution node group?

Distribution Groups: Set of nodes or even organisations that are defined for the distribution of products or services. These are in turn associated and held up to the sourcing rules to fulfil orders. Generally they are grouped on the proximity of the shipping locations but can also be grouped in terms of belonging to the same enterprise or even grouping all supplier nodes into one distribution group. These are used to group product items, service items or procured items.

Notification types:

  1. Organisation Level: Number of days before the expected ship date that you want the order to be scheduled to a node. In deeper understanding, say your typical time taken to process an order (order received at the node to delivery to customer) is around 4 days, and you received an order on 10th of March and the promise delivery date is 18th of March, so typically the organisation level notification would float at 14th of March.

  2. Node Level: If order notification or promising rules are defined for individual nodes, this takes precedence over the organisational notification.

  3. Item Level: If notification is defined at the item level, then this takes the highest precedence

Item Level Notification > Node Level Notification > Organisational Level Notification

Order Monitoring

Components used to measure and report unexpected conditions and delays in any order document's lifecycle.

Types:

  1. Status Monitors -> Monitor orders that stay in a particular status for a set amount of time.

  2. Process Monitors -> Setup for specified pipeline within a process. Determines whether the order document meets the conditions that are specified in the rule set.

Example of Status Monitors:

Orders on Hold: Preventing an order document from being processed by certain transactions and preventing certain modification types from being applied.

Alerts

Whenever a transaction needs manual intervention, an alert is directed to a user or an alert queue.

Key Abbreviations:

Payment Processing in OMS:

  1. Payment authorisation

  2. Settlement

  3. Invoicing

Similar to sourcing rules, organisations can also choose to setup payment rules. The payment rules could specify when to publish the invoice for example, in time of creation or collection.

Reverse Logistics

Strategy of managing and controlling orders that are returned from customers to refurbish and be placed back into the status of a sellable product.

Return Cycles:

The process of reverse logistics where a delivered item is returned back to the supplier / shipment node upon order cancellation or in case of a derived order (e.g customer exchanges for a different size of the product)

RMA is the authorisation process where the seller approves the return cycle for a delivered product based on the return request details submitted by the customer.

Return Process:

Share this piece