AMR Research (2005) believes that companies must begin developing and redeploying current order management architectures with the focus on delivering more flexibility rather than a strategy that delivers far less. The move toward customer-driven fulfillment processes requires the ability to build and adapt channel-specific, product-specific, and customer-specific order flows quickly without an army of developers creating custom code.
However, the days of big bang, rip-and-replace implementations are over, and any significant it project must have two key attributes: the ability to use existing investments in data and business logic and the ability to be deployed iteratively. Both of these require thinking about the order management applications in terms of architectures, rather than a laundry list of features and functions. The users that are good candidates for the various types of Distributed Order Management (DOM) applications that are defined in this analysis should place significant emphasis on the architecture support across the following four key levels which are graphically presented in Figure 3, Distributed Order Management Hierarchical Model as defined by AMR Research (2003). Data Services anchor the model, followed by Application Services, Presentation Services, and a separate Presentation Services specifically for Internal and External Constituents. This model is very useful for organizing the literature review for DOM systems.
Distributed Order Management (DOM) Hierarchical Model
Data services: Construction of a shared and consistent repository of analytic and operational data is the single biggest challenge in effectively deploying distributed applications.
Master data services -- Normalized and synchronized data on customers, products, accounts, and suppliers is the primary building block. There are several techniques for building a system of record from database consolidation to the development of virtual objects that are a composite of various systems. Regardless of the overall data management strategy, the DOM architecture must be message centric and have a metadata-driven data model. These capabilities allow the system to understand where key data resides, how to get it, and how to transform or normalize the data.
Analytical data services -- in addition to transaction or operational data, the system must either support the creation of its own logical analytical data model, or feed a customer-specific data warehouse in order to measure and manage the performance of the entire process and create visibility to all stakeholders.
Application services: There are three critical components of the application services layer, which are all shared services required to manage a distributed environment.
Event and state management -- This is a persistent engine that monitors the state of the order throughout its lifecycle as it travels between disparate systems, both internal and external. Coupled with the state management engine is event management, which monitors the order cycle to identify issues related to time and quantity in order to identify and manage exceptions proactively.
Order broker (integration framework) -- in addition to the reliable and scalable messaging found in leading Enterprise Application Integration (EAI) systems, the systems must be specialized to deal with the way orders are decomposed and processed. First, it must have a universal order object that has several key attributes: order line independence, ability to translate a single order and order lines into all of the required activities including the generation of purchase orders, service orders, manufacturing order and distribution orders, and ability to define dependencies between the individual order lines. The order definition is then connected to the order broker, which can be based on a standard EAI system or a vendor's own messaging layer that prepares the instructions for the various parties and defines the format of the business documents and communication methods.
Business Process Management (BPM) -- This is the ability to graphically design processes and workflows inside the application and across multiple applications to enable and manage an end-to-end process. The application should enable users to define custom order processes and types based on almost any dimension, but specifically based on the customer, geography, and/or the product. Without the flexibility inherent in a BPM engine, users will struggle to support the level of customization required in all order management environments.
Process services: There are currently 12 key modules that provide the business logic to assemble and configure a complete DOM system. Few companies will require all, since priorities will be highly dependent on need and current environment. The key modules are as follows:
Configuration and quote -- Including support for simple rules-based configuration to more complex attribute or parametric configurations
Pricing and contract management -- Including support for global taxation
Global credit management -- Including the ability to aggregate credit information from multiple internal and external sources
Product catalog -- Including the ability to support, aggregate, and manage multi-vendor catalog. Columbus (2001) points to these tools specifically as leading to greater levels of closed sales throughout indirect channels.
Order promising -- Including Available-to-Promise (ATP) and Capable-to-Promise (CTP), which is critical according to Sourcing and allocation -- Including support for substitutions and inventory reservations
Order visibility -- Including the ability to track orders internally and through logistics or contract manufacturing partners
Inventory visibility -- Including the ability to synchronize all item data across system
Automated replenishment -- Including support for Vendor Managed Inventory (VMI)
Delivery management -- Including the ability to track delivery through logistics partners and normalize data
Service management -- Including the coordination of aftermarket processes, such as parts, returns, repairs, and field service
Consolidated settlement -- Including the ability to create a single invoice and all the necessary credit and debit transactions between business entities in order to settle order process
Presentation services: The key capability is to provide relevant user-specific content, data, Reports, and Alerts to support the consistent and efficient execution of the CF process. The key requirement of vendors is developing the ability for the application to be run with or without presentation services, allowing users the flexibility to leave existing user interfaces in place and use the business logic and data for application. The key enabling technology is a portal framework that includes the following services:
Role-based or context-based presentation and navigation
Identity and security services
Content management and taxonomy services
Part 4: Theoretical or Conceptual framework for order management
From the customer's perspective, the order management cycle extends from inquiry to account settlement and includes order processing and delivery.
Figure 4 provides an example of this process, and the specific steps below describe them. From the enterprise perspective, the order management cycle involves five aspects of functionality:
Distributed Order Management (DOM) Conceptual Framework
Order management plays a key role when the enterprise interacts with its customers. At inquiry and order, order management captures all relevant business rules governing the sale. These rules are defined by the following factors:
In the transaction itself (e.g., quantity and delivery date)
By a hierarchy of precedents involving such items as contract, commodity, customer, customer class, customer credit condition, country, and currency
By the enterprise's and customer's business rules
Information captured at order time governs downstream activities in sourcing, delivery, and settlement. Figure 5 illustrates the more advanced aspects of each of the distributed order management cycle, including the key process areas that both order management and order fulfillment interact with.
Distributed Order Management (DOM) Conceptual Framework Specifics
Scope and Requirements of Order Management
Figure 5 defines the functional scope of order management from capture to settle. Complementing order management, customer asset management aids in the acquisition of customers and tracks issues and resolutions to ensure customer retention.
In capture, the enterprise acquires the customer's demand signal (item, quantity), attending requirements (delivery, value-added processes), and specific terms and conditions. This functionality also supports inquiries, quotes, and changes.
This includes the ability to support different streams of order entry:
High-volume electronic data interchange (EDI)
Customer-direct via the Web
Telemarketing supported by customer service representatives
Direct sales supported by a field sales force
Validate ensures that attributes and content of the order conform to all relevant business rules between the enterprise and its trading partners. In most instances, these rules derive solely from the enterprise/customer relationship. They may also derive from the supplier/enterprise-customer relationship if the supplier controls the channel. This is often the case in Industrial Products where the original equipment manufacturer (OEM) may define terms and conditions between supplier and customer. Validate can be executed in real-time within capture or in nightly batch runs after the fact, depending on the implementation and business rules shared by the enterprise and trading partners. Supported by technology, best practice is pushing toward real-time validation at capture. Depending on channel, customer, and enterprise requirements, validate may include some or all of the following:
Customer credit check by any organization attribute associated with the customer
Customer order authority by commodity, order value, etc.
Pricing standard or by channel, contract, transaction-level negotiated discounts, etc.
Promotion affecting pricing, item, packaging, etc.