How to Select a Distributed Order Management System to Match Your Vision
10 April 2026 - ID G00822956 - 19 min read
By Chap Achen
Selecting the right DOM system is becoming more complicated as vendors add more features, provide increased customization and serve new markets. This research gives supply chain technology leaders guidance to ensure a successful DOM selection that fits their order promising and fulfillment vision.
Overview
Key Findings
- A distributed order management system is still a first-time purchase for many organizations. This results in leaders spending too much time understanding the functional capabilities rather than identifying the key business drivers for selecting a DOM.
- Organizations traditionally use only business requirements without further context on specific scenarios when looking for DOM vendors. This restricts a full comparison of how vendor approaches meet requirements.
- The DOM market is now addressing emerging trends in composability, low-code, embedded analytics and intelligence and extensibility frameworks. This shift brings new opportunities and challenges that buyers must consider in the selection process.
Recommendations
- Develop a vision that clarifies the most important promising and fulfillment requirements by stress-testing your fulfillment vision against the complexity of your downstream network.
- Obtain a comprehensive evaluation when comparing DOM applications by employing use-case scenarios in addition to functional requirements when comparing application capabilities.
- Assess your capacity and competency related to the feature management and composability of the vendor’s application by validating that your internal goals align with the application’s approach.
Introduction
Supply chain technology leaders charged with selecting a distributed order management (DOM) application face a vendor base that is offering more features and more flexibility in how leaders purchase and implement applications.
Since 2022, the profile of a company considering a DOM has shifted from large retailers to a more diverse set of users. Gartner research conducted between July 2022 and 2023 showed that:
- 29% of companies that purchased a DOM were small and midsize business organizations.1
- Distributors, wholesalers and third-party logistics accounted for 17% of DOM purchases.1
On the feature side, demands for specific estimated delivery dates (EDDs) have driven a number of DOM vendors to also offer EDD calculations as a new feature module. Based on fourth-quarter 2024 product offerings, 42% of DOM vendors now offer this capability.2
DOM vendors are now also selling microservices-enabled modules of their application components rather than only full stack, which enables customers to adopt an incremental development approach but makes purchasing more complex from a licensing perspective (see Figure 1). Such options require the supply technology leader to take a broader view and evaluate whether IT maturity is sufficient to work with the desired best-of-breed components.
This research addresses how to narrow the wide range of DOM application choices, enabling you to make a selection that meets your business objectives. It provides a process to focus your requirements and delivers concrete application examples.
Analysis
Develop a Vision to Target Your Critical Requirements
A DOM can drive down cost to serve and improve customer experience (CX) and inventory utilization. Supply chain technology leaders should be clear on the top business drivers they are selecting by following these steps:
- Determine the key components of vision, in other words, customer promise and fulfillment strategy.
- Assess the highest degree of complexity within this vision.
Determine Key Components of Your Vision
Create your vision by assessing your current and planned sales channels, supply network and fulfillment choices and deciding what changes or additions in that fulfillment model are most important to enable the business case that justifies the DOM purchase. See Figure 2 for a typical set of components a supply chain leader may evaluate during this phase, from order channel to order orchestration, including promise attributes, sourcing and decision criteria and point of fulfillment.
To establish your vision, address questions about how the DOM supports and achieves business growth objectives (see Figure 3).
How does the DOM support your business growth objectives? Establish the most important drivers for your business that the DOM should enable. Use the following common objectives as a starting point as you develop your own list of drivers:
- Increasing profitability through increased efficiency
- Opening new sales channels, such as via marketplaces or social selling
- Expanding into new international markets
- Increasing your geographic distribution footprint
- Offering increased fulfillment optionality and network speed
- Improving inventory flexibility with the use of stores or hubs in fulfillment
What are the biggest challenges to achieving these objectives? Assess and prioritize critical challenges then create a sequence for how they will be addressed. Gartner observes these typical challenges:
- Inability to make accurate promises on delivery and inventory availability across sales channels, leading to lost sales and excess unsold inventory
- Suboptimal order fulfillment performance causing poor CX and increased click-to-delivery time frames
- Higher-than-planned processing and delivery costs
- No strategy for sales credit across channels
- Lack of clear ownership for end-to-end order management
- Integration complexities with other enterprise applications like warehouse management systems and ERP
These questions and challenges should clarify the primary focus area that you assess in the DOM selection — your customer promise and fulfillment vision.
Consider the following example visions for inspiration as you create your own:
- Improve our digital commerce margins through maximum leverage of unified commerce offerings.
- Increase our revenue through deeper assortments, sales channels and suppliers.
- Improve CX and reduce cost to serve with highly automated and self-serve-enabled fulfillment experiences.
Assess the Highest Degree of Complexity Within Your Vision
Once you’ve established the vision, review each component of the network to assess where the most complexity lies:
- Promise complexity is defined by how many sales channels you support with the DOM and how much real-time inventory and order promise data must be shared and synchronized across those channels.
- Fulfillment complexity is related to how much optionality for receipt of product is available.
- Supply complexity relates to the number of inventory locations and the extent to which SKUs exist in multiple locations to service the same demand.
Table 1 provides an overview of examples and benchmarks you can use to evaluate your complexity.
Complexity Parameters
Complexity type | Parameters | Sample benchmarks for complexity |
Promise complexity |
|
|
Supply complexity |
|
|
Fulfillment complexity |
|
|
Source: Gartner
The key question to assess is where your vision has the most complexity across the network factors. The combination of vision and complexity creates the critical set of features you will assess further with scenarios. See Figure 4 for an example of putting these together.
Use Scenarios and Nonfunctional Requirements to Articulate Your Vision
Once you’ve identified your vision and complexity, animate your vision in scenarios that will support your initial assessment of the vendors in the market.
Create Business Scenarios Instead of Listing Functionality Requirements
Functionality questions alone do not represent real business requirements because, individually, they cannot create the context of the supply chain’s desired fulfillment operation. Business scenarios are more meaningful and relevant to both the organization and vendor, but they involve a deeper exploration of your planned future processes. By using scenarios, organizations can more clearly evaluate applications against their planned order fulfillment process flows. These scenarios also allow the DOM vendor to fully understand the context and demonstrate how the application supports it. In many cases, this dispels either party’s assumption that customization will be needed to meet certain requirements.
DOM vendors have extensive features and report that existing functionality meets most of their client requirements.3
Believing their business requirements to be unique, retailers often jump to an initial conclusion that they will have to customize a DOM application, without fully understanding existing capabilities.
Following is an example that compares a fulfillment scenario and series of functionality requirements. The retailer wishes to manage fulfilling an order from more than one location and consolidate it for shipment to the consumer: The consumer orders six products for home delivery in three days’ time.
A scenario would be constructed like this: No inventory-holding location has all six items in stock, so the optimal fulfillment strategy, taking lead time and fulfillment cost into account, will be to:
- Ship one product from a regional distribution center to the closest store to the consumer.
- Transfer a further two from a nearby store to the closest store to the consumer.
- Pick the remaining three products from the closest store to the consumer.
- Consolidate with the other three products shipped to the store.
- Ship all six items as a single parcel from the closest store to the consumer.
If the same requirement were written as a series of functionality questions, it would read as follows: Is your application able to:
- Fulfill a multiproduct order from more than one inventory-holding location?
- Pick products from both distribution centers and stores for the same order?
- Pick a product from one store and transfer it to another store?
- Consolidate products into a single store from distribution centers and stores?
- Ship an order from a store for home delivery?
In this example, had the retailer listed the series of functionality questions, most, if not all, vendors would say their application has the required capabilities, making differentiation among vendor offerings difficult, if not impossible. In combination with business requirements, scenarios articulate the business process much more clearly than questions and provide the vendor with increased clarity about the underlying business problems.
See Note 1 for more examples of what an effective scenario looks like.
Gartner recommends that retailers craft 20 to 30 scenarios that represent the various consumer shopping patterns and fulfillment methods and determine the business process required to manage those choices.
To be effective, scenarios must mirror real-life situations by adequately focusing on issues such as constrained inventory, split shipments, delays to ideal fulfillment lead times, back orders, preorders, order cancellations and amendments.
Articulating the required functionalities as scenarios obliges vendors to illustrate their functionality to the retailer in an application demonstration environment. This offers the retailer a chance to witness how the system performs in these scenarios, providing visibility into the user interface, screen navigation and layout structure.
Scenarios should be prioritized according to their importance to the vision you created in the first step. Some certainly will be classified as crucial or preferable, but include others that may seem more exploratory in nature to understand the functional boundaries of each application under consideration.
Develop Nonfunctional Requirements That Support the Scenarios
Create nonfunctional requirements (NFRs) to ensure that your scenarios will match your performance expectation. Given the added features around promising, be careful to not degrade your digital commerce experience when attempting to deliver promises or inventory data further up in the shopping experience, such as the product detail page or product list pages. Developing these NFRs also will prepare you for the DOM vendor licensing evaluation where you will be asked for order volume and throughput requirements to create pricing proposals.
Table 2 provides examples of NFRs. Assess these metrics at peak and nonpeak loads based on historical site analytics and order data.
Nonfunctional Technical Requirement Examples
Promise | Orchestration | Fulfillment |
Available-to-promise response time (millisecond response time per transaction per second) | Peak orders per hour throughput based on a typical distribution of order sizes | Full-sync inventory load time based on SKU/node expected volumes |
EDD response time on product detail pages/cart | Node selection response time based on expected network variables | Number of SKU/node combinations supported |
Inventory reservation performance in cart/check-out | Average page load time in customer care portal based on average order size | Store fulfillment pick wave creation execution time based on expected concurrent users and wave size |
Source: Gartner
Assess Your Capacity and Competency Related to the Vendor Application
After you’ve turned your vision into a set of business scenarios and NFRs, assess your capacity and competency related to the feature management and composability of the vendor application. Doing so ensures your alignment in these two areas with the vendor’s offering.
Determine the Importance of Feature Management
Gartner interactions with DOM vendors suggest that most are ahead of their customers in feature availability versus feature need.3 The complexity of using these features partly explains this. When multiple factors, such as inventory age, capacity utilization and proximity, are used to select the best node for fulfillment, the configuration and explainability become complex. Although superusers can configure the changes, how to do it and how those changes will manifest themselves in production is not always clear.
DOM vendors are attempting to remediate this with low-code configurations, improved UIs and explainability and simulation feature sets. This follows the broad market trend of low-code applications. For more research, see “What should I know about Enterprise Low-Code application platforms.”
Consider these three factors when determining the importance of feature management:
- Define your sales, network and CX change rate. If the elements across your sales channels, promises, supply and fulfillment ecosystem will change frequently, feature management will be critical. For example, if you support a constantly changing set of drop-ship vendors, third-party marketplaces or available locations for fulfillment, then ensure the DOM vendors demonstrate the ease of adding or changing these. A strong integration framework and/or prebuilt integrations will accomplish this. Most DOM implementations require more than five integrations to go live.3
If cost-to-serve improvements are a significant part of your ROI, assume that you will need continual iteration of your node selection rules. It is very rare that Gartner sees a client achieve all the cost-to-serve benefits in an initial implementation. Routing rule options should be accompanied by features that explain the decisions the application made and by reporting tools to measure effectiveness. The accompanying features should have the ability to simulate the rule changes’ impact of using historical inventory and order data and then easily promote them to production.
Conversely, if the level of change is not expected to be high, a strong integration framework or set of configuration UIs for sourcing rules will not be critical to your selection. - Determine your level of ongoing support. Most mature DOM clients have dedicated analysis personnel to measure the performance of the promises they are making to consumers and the associated costs of executing them. Part of the gap between feature usage and feature availability that exists today is due to supply chain technology leaders’ underestimating the amount of resources required to optimize a DOM running a complex network. Don’t select a DOM with a large amount of optimization dials unless you plan to fully staff the analysis required to manage them.
- Decide on a business or IT support model. As feature management usability improves, it is feasible that business users with advanced application knowledge will be able to own the implementation of the changes that come from performance analysis output. However, supply chain leaders should align with IT stakeholders on the expected IT support model for the application (see How to Identify and Implement IT Operating Models in Retail). The resources with “hands on keyboard” will determine how important business-facing usability is to your selection. You should also pressure-test the vendor’s claims of low-code configuration changes by including a scenario regarding this.
Evaluate the Importance of Composability
Market trends seen in digital commerce have been related to MACH architecture principles, which comprise microservices, API-first, cloud-native SaaS and headless architecture. The trends now are moving into DOM applications. If your organization is adopting a composable architecture, carefully consider the DOM’s claims of composability. For further research on how to apply composability, see Apply the Principles Behind the Future of Applications to Digital Commerce and How CIOs Use Application Composability to Unlock Business Agility.
Gartner is aware of four DOM vendors that have become MACH-certified in the last year, and 14 DOM vendors now make claims of composable architectures.5 In theory, this will allow the purchase of feature modules at a more granular level than previously available and provide flexibility in choosing the best-of-breed application or, at a minimum, increased flexibility in the implementation strategy. For example, if you have promising complexity related to inventory but not in fulfillment orchestration, you may decide a DOM with a strong inventory module is all you require. Another example could be purchasing a sourcing model to augment your current order management system to enhance order routing decisions.
Recent DOM vendor inquiry shows that while the majority of deployments are still full stack, over the last year component deployments have increased in usage.3
If your organization has already begun a composable journey, you are likely well aware of the necessary IT maturity required to execute this. When you are selecting a DOM and composability is a factor in your decision making, assess the following:
- Has the vendor actually deployed a component of its application with another vendor’s application?
- At what functional level are components deployable, and does this create the implementation or commercial outcome you are seeking?
- Do the client case studies involving composability give you the full picture of the impact to the total cost of ownership or agility gains?
For this research, Gartner interviewed 12 leading DOM vendors to obtain their insight and advice as to best practices in DOM selection processes. This input was married with feedback and experiences shared from over 50 Gartner clients, all of whom had completed DOM software selection programs.
1 Data was collected in September 2023 as part of the data gathering process for the Market Guide for Distributed Order Management Systems. There were 31 respondents. The findings and conclusions are representative of those who completed the survey, not the market as a whole.
2 Gartner secondary research conducted in October 2024 of 31 DOM vendors that responded to the 2023 Gartner Distributed Order Management Market Guide Survey.
3 Based on direct interviews and interactions with vendors listed in Market Guide for Distributed Order Management Systems.
Note 1: Scenario Examples
The following four descriptions provide examples of good scenarios that can be used in conjunction with functional requirements.
Scenario 1: Variable Lead Times in One Order
A consumer orders four products for in-store pickup. At the time of ordering, the lead time for collection for each product needs to be communicated on the web product page. Two items are available for same-day pickup, and the other two will be available in one and three days, respectively. The consumer completes the order for all four items, accepting the varied lead times. Reserve the two items in store and reduce store-available inventory. Request a pick and dispatch to store from one or more distribution centers for the other two items. On arrival in store, consolidate the two received and two reserved items. Alert the consumer that their completed order is available for collection.
Scenario 2: Searching for Products Based on a Delivery Date
A customer is building an order of multiple items and wants them to be delivered together. They search for a primary product and can see delivery date information and store inventory data within the product listing pages results of 20 products matching their search. For each product they view at the product detail page, they are able to view a specific estimated arrival date (08 Jan) for three fulfillments options: ship to home, ship to store and buy online and pick up in store (BOPIS). The customer can see “order by” times to maintain the estimated delivery date being shown. The delivery date is informed by the following: inventory, carrier transit based on customer ZIP Code, fulfill from location, time of day, time of week and node performance. They search for other products using a “get it by” filter and end up adding four items to their cart. The cart dynamically updates delivery date information based on the four items. The best node for fulfillment for all four items adds two days to the delivery time frame and the promise is updated to reflect 10 Jan for all items. The customer is able to delete items from the cart and see the impact to the overall promise. The customer is offered a free shipping promise, a faster ground promise with shipping charges and an expedited promise. The customer selects a faster ground promise, and this is fed to the DOM as a constraint on the order.
Scenario 3: Sourcing Rule Modification
An analyst uses a DOM-supplied report that shows them that the capacity utilization for a group of stores in the Northeast region is higher than the target of 75%. The analyst wants to move the capacity utilization back in line with the target while keeping the transit time flat. They select order and inventory data from the previous two weeks and review the sourcing configuration used. They modify the capacity penalty by 10% for the region of stores impacted. They run a simulation of historical orders against the rule, and the system provides them with a set of KPIs across the orders that includes average transit, capacity utilization and cost per order. Seeing that the capacity change has improved the utilization and has an acceptable impact on speed and cost, the analyst modifies the sourcing rule on their own and selects a start date on the rule change.
Scenario 4: Modify Picking Strategy for a Group of Stores
A retail operations analyst sees that units-per-hour picking performance has dropped by 20% at a group of stores for which they are responsible. In reviewing the DOM-supplied report, the analyst sees that the average volumes have increased by over 30% at these locations during the past month. The analyst uses the DOM to compare other stores’ units per hour at similar volumes and sees they are running a four-times-daily batch process to group orders in picking waves. The analyst communicates with the retail store group’s district manager about changing their pick process to a wave-based process, suggests they review the DOM training module on wave creation and sets a date to go live. Using the DOM configuration, the analyst updates the picking strategy in the system and sets its deployment for the agreed-upon go-live date.