Order Management Systems

Forrester evaluated order management hubs in 2010 against one hundred and twelve criteria.

The Q1 2025 evaluation uses twenty seven for current offering.

Between those two numbers sits a market that stopped being an integration problem and became a decision problem, and understanding what the system actually decides is the most useful thing to establish before comparing anything.

What an OMS is actually for

Strip away the feature lists and an order management system answers one question repeatedly: given this order, from where should it be fulfilled?

A customer in Utrecht orders three items. The retailer holds inventory across four hundred stores, five distribution centres, and three supplier locations that can drop-ship. Some of those nodes have all three items, most have some, and the inventory figures for each are of varying reliability.

The system chooses. It weighs shipping cost, delivery promise, margin, inventory position, store labour capacity, the risk of stranding a partial order, and whether that item is about to be marked down anyway. Then it does it again, thousands of times a day, as inventory moves underneath it.

That is order orchestration, and it is the product. Manhattan's maximum scores in the current evaluation cluster around exactly this: inventory segmentation and allocation, store inventory management, omnichannel order management, and order orchestration rules.

Everything else in an OMS, the customer service tooling, the returns handling, the appeasement workflows, exists to manage the consequences when that decision was wrong.

Why stores changed the problem

The category became strategically important when retailers started fulfilling from stores.

For most of retail history, online orders shipped from a distribution centre. One node, one inventory position, a solvable routing problem.

Ship-from-store, collect-in-store, and curbside pickup turned every location into a fulfilment node. That was commercially necessary, since it puts inventory closer to customers, uses stock that would otherwise be marked down, and defends the store estate's economics.

It also created an optimisation problem that did not previously exist. Four hundred nodes with different inventory, different labour capacity, different shipping costs, and different local demand cannot be routed by a rule somebody wrote. It requires a system making a cost-and-service trade-off per order.

And it introduced a failure mode that is specific to this model. Promising an item that the store does not actually have produces a cancelled order, a disappointed customer, and a store associate who now distrusts the system and starts hiding inventory from it.

Omnichannel arrived and left

The category's name history tracks the arc precisely.

The Forrester Wave: Order Management Hubs, Q3 2010, authored by Roy Wildeman, evaluated vendors against one hundred and twelve criteria. Its Leaders were Oracle E-Business Suite, Sterling Commerce, SAP, Oracle Siebel, and Microsoft, with Manhattan Associates, Amdocs, and JDA as Strong Performers.

That vendor list describes what an order management hub was: middleware sitting between ordering systems and fulfilment, and the Leaders were enterprise application vendors whose products already held the order.

The Q3 2016 edition was titled Omnichannel Order Management, evaluating nine vendors against forty criteria: Aptos, IBM, Jagged Peak, Kibo, Manhattan Associates, NetSuite, Oracle, Radial, and SAP Hybris, authored by Brendan Witcher with Adam Silverman.

The Q3 2018 edition added Systems to the name and evaluated ten providers against forty criteria, introducing Digital River and Magento.

The Q2 2021 edition dropped Omnichannel, evaluating seven providers against thirty eight criteria: Aptos, enVista, IBM, Kibo Commerce, Manhattan Associates, Oracle, and Radial.

The Q2 2023 edition scored eight providers against thirty four criteria, and the Q1 2025 edition scored eight against twenty seven current offering criteria, with Körber among those evaluated.

Omnichannel entered the name in 2016 and left by 2021, which is the same pattern visible when Forrester dropped augmented from its business intelligence category. The adjective survives exactly as long as its absence is plausible. By 2021 an order management system that could not handle cross-channel fulfilment was not an order management system.

Inside the Q1 2025 evaluation

Manhattan Associates placed as a Leader with maximum scores in twenty of the twenty seven current offering criteria, spanning inventory segmentation and allocation, store inventory management, omnichannel order management, order orchestration rules, and pre- and post-purchase customer experience.

Kibo also placed as a Leader with the highest possible score in eighteen criteria including enterprise inventory management, fulfilment automation, usability and configuration, customer service, and omnichannel order management, and received above-average customer feedback. Forrester's note on its references is unusually direct: customers expressed more satisfaction with Kibo than with any other vendor evaluated, and felt heard in a way they believed extended to all customers.

That last observation deserves attention, because in a mature market where capabilities converge, the vendor relationship becomes the differentiator that capability scores cannot capture.

A market where nobody is switching

Forrester's companion report on lessons from the evaluation contains the finding that matters most for anyone approaching this category.

Most reference customers are happy with their vendor partners and are focusing on small-scale functionality augmentation to meet evolving business needs, while the market has expanded functionality to fit broader customer use cases.

That describes a settled market. Customers are not replacing systems, they are extending them, and the vendors are competing on adjacent capability rather than on displacement.

Two things follow.

If you already have an OMS that works, the case for replacement is weaker than a capability comparison suggests, and the incremental gain is likely available through configuration or a module rather than a migration.

And if you are selecting for the first time, the relevant differentiators are the ones that show up over years rather than in an evaluation: how the vendor handles change requests, whether the roadmap reflects customer input, and what support looks like during peak trading when a routing rule misbehaves on the busiest day of the year.

The criteria contraction from one hundred and twelve to twenty seven says the same thing from Forrester's side. Most of what these systems do stopped distinguishing them.

The dependency nobody solves

Everything an OMS decides rests on knowing what inventory exists and where, and that knowledge is worse than most implementations assume.

Distribution centre inventory is generally accurate, because it is a controlled environment with disciplined processes and cycle counting.

Store inventory is not. Items get moved, mis-scanned, damaged, stolen, put in a fitting room and never returned to the floor, or sitting in a stockroom nobody has searched. Published research on retail inventory accuracy has consistently found meaningful discrepancy rates between recorded and actual store stock, and the discrepancy is worst for exactly the fast-moving items customers order.

The OMS inherits that error. It routes an order to a store showing one unit, the store cannot find it, the order cancels or gets re-sourced, and the customer experience degrades.

Vendors respond with probabilistic approaches: availability thresholds that hold back the last unit or two, confidence scoring per location, and learning from historical fulfilment success by store. Those are sensible mitigations and they are compensating for a data problem rather than solving it.

Which produces a practical evaluation question worth more than most feature comparisons. Ask what the system does when a store cannot fulfil, how quickly it re-sources, whether the customer is told, and how the store's reliability score adjusts. The answer describes how the platform behaves in the situation that actually occurs.

It also produces a sequencing observation. An organisation whose store inventory accuracy is poor will get less from a better OMS than from fixing the counting discipline, and the second is cheaper.

Where AI is actually landing

Forrester's lessons report covers which generative AI use cases are live in the evaluated solutions, and the plausible near-term applications in this category are narrower than the general enthusiasm.

Customer service is the clearest. An agent handling a where-is-my-order enquiry, a return, or a partial shipment question is working from structured order data with a bounded set of outcomes, which is a well-suited problem.

Exception handling is the second. Orders that cannot be routed, addresses that fail validation, and payments that fall out are a queue of edge cases, and triaging them is exactly the sort of work that consumes disproportionate human time.

Sourcing optimisation itself is a different matter. That decision is already made by algorithms and has been for years, using operations research techniques well suited to the problem. Machine learning improves the demand and availability inputs to those algorithms rather than replacing the optimisation.

The distinction is worth holding, because vendors describe both under the same heading and only one of them is new.

Where this sits in the stack

For anyone mapping the commerce technology estate, the OMS sits between the systems that capture demand and the systems that satisfy it.

Upstream are the commerce platform, marketplaces, point of sale, and call centre, all creating orders. Downstream are the warehouse management system, transportation management, store systems, and suppliers. Alongside sit the enterprise resource planning system holding the financial record and the inventory positions the OMS depends on.

The reason the category exists as a distinct product rather than a module is that the sourcing decision needs a view across all of those simultaneously, and none of the neighbouring systems has it. A commerce platform sees demand and not fulfilment capacity. A warehouse system sees one node. An ERP sees inventory in aggregate and rarely in real time.

That positional advantage is why the OMS became the system of record for the order and, in several implementations, the de facto system of record for available-to-promise inventory across the enterprise.

It is also why replacing it is difficult, which brings us back to Forrester's finding that customers are augmenting rather than switching. A system that everything else depends on for the answer to where things are gets replaced reluctantly, and usually only when it cannot support a fulfilment model the business has already decided to adopt.

Forrester does not endorse any vendor named here, and tier placement should not be read as a recommendation to buy.