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...

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

Community definition

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:

Capture

Validate

Source

Distribute

Settle

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.

Capture

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

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.

Product by SKU, SKU extensions, or attribute in non-SKU environments

Customer by stand-alone account or multi-organization rules

Substitutions by product life-cycle, customer-defined rules, etc.

Design in an engineer-to-order environment

In certain make-to-order environments, where committing to a customer due-date requires finding available capacity and inventory, validate can be tightly coupled to advanced planning and scheduling (APS) functionality. In other environments where delivery date and delivered cost are transportation-sensitive, such as bulk chemicals, metals, textiles and paper, validate may be tightly coupled with the reservation of transportation capacity, concurrent with capture in best practice.

Source

Source entails the steps necessary to commit inventory, work-in-process (WIP) or capacity to an order. This may be as simple as product reservation against on-hand finished goods or more complex, such as soft and hard allocation against a time-phased view of…