Distributed order management systems

¶ … Management

Distributed Order Management Systems

Theoretical or Conceptual framework

Questions addressed

Data analysis, discussion and results

Including discussion of any limitation(s))

DDSN Characteristics

SPSS Regression Statistics on DOM Investment by Velocity of Pricing

Common Order Management Module Functions

Overlaying Business Process steps with order management components

Distributed Order Management Hierarchical Model

Distributed Order Management (DOM) Conceptual Framework

Distributed Order Management (DOM) Conceptual Framework Specifics

ATP

Available to Promise; is a measure of a supply chain's ability to report back when a product can be built

APS

Automated Planning and Schedule - a type of application used for planning production.

BTO

Build-to-order; a product strategy aimed at creating customized products where 30% of product content is custom. Appendix IV defines this concept graphically.

Configurator software application that is typically included in more complex ordering systems that is a constraint engine that makes it possible to create customized products automatically, based on selections from users configuring products on the website for potential purchase.

DOM

Distributed Order Management

Electronic Data Interchange

ERP

Enterprise Resource Planning System. Typically used for managing the production of products in factories.

ETO

Engineer-to-order; a product strategy aimed at creating customized products where 70% of product content is custom. Appendix IV defines this concept graphically.

MTS

Make-to-stock, which refers to products built specifically to mass customer requirements and are the majority of a company's inventory

OMS

Order Management System

Quote-to-order

The process that encompasses quoting through order fulfillment. This quote-to-order process is typically combined with BTO and ETO processes to create quotes for customized products tailored to specific user's needs. This is particularly relevant for Blueberry as they pursue the launch of new PDAs customizable by users online.

VMI

Vendor Managed Inventory, which is the coordination of inventory demand across a supplier and distributor most often - it is a method of ensuring lean manufacturing efficiencies

Part 1: Executive Summary

Order management functionality was first added to manufacturing resource planning (MRP II) systems in the form of order entry modules. As its name indicates, this module was designed to enter customer demand into the system to close the materials requirements planning (MRP) netting loop. Generally, order entry modules were designed for manufacturing, not for customer service support. As a result, most early order entry modules were cumbersome. These modules enforced a rigid process that required order numbers, customer IDs, item numbers, address IDs, remit-to addresses, etc. all to be predefined before an order could be entered. Although it inflicted all of these prerequisites on the customer order entry process in the name of completeness and integrity, the module was unable to provide customer service reps any real support for product information, pricing, or delivery dates. As if this was not bad enough, most order entry modules were created without any specific vertical industry application in mind. Over the last 15 years, software developers have attempted to add pieces of functionality to address a wider range of industry-specific issues. This has resulted in bloated and complex enterprise resource planning (ERP) order management modules that are still far from becoming the hub of the order management and customer service process. Nevertheless, the demand drivers for distributed order management systems continue to significantly expand the market for distributed order management systems, as is evidenced in Appendix a of this document, Global Order Management Market Sizing.

Figure 1 provides a graphical description of the order management function within manufacturing companies in the form of common order management module functions. Was is very clear from this graphical description is the pervasive need for integration between order management modules and the many systems it relies on for completing its critical tasks. The intent of this paper is to provide a thorough analysis of distributed order management systems, the key influences impacting them today, and the growth of the market overall.

The intent of this research is to first define how distributed order management systems are progressing from being ERP centric and more customer-focused. The unresolved question however in current research is the level of adoption for distributed order management systems across key industries and what the level of adoption translates into for transaction velocities. The major benefit of knowing if and by how much distributed order management systems increase transaction velocities has a direct impact on profitability. This research will deliver the size of the distributed order management marketplace globally, and also provide benchmarks of transaction velocities of distributed order management systems.

Part 2: Introduction and Background

An Order Management Revolution is Underway

If there is any one ERP module that is a victim of evolutionary functionality bloat, it is the order entry module. As mentioned earlier, it was never really designed to meet the needs of the actual users, usually customer service personnel. Five to ten years of scattered functional enhancements will add further complications:

Numerous order entry forms

Hundreds of confusing control fields

Pricing matrices that are virtually incomprehensible and impossible to maintain

An order entry process that is disconnected from many other critical supply chain processes such as planning, warehousing, and distribution

Graphical user interfaces (GUIs) that do not look any more like customer order entry forms than their character-based, green screen predecessors

So what is the answer? It may be that the order entry module needs to undergo the same level of revolutionary change as the MRP, capacity requirements planning (CRP), and master production scheduling (MPS) modules are currently undergoing as a result of advanced planning and scheduling (APS). APS is redefining the planning process to match the dynamic requirements of today's manufacturing environment. From the design perspective, APS started from a clean sheet and leveraged current technology to develop planning software better suited to meet a wide variety of real-world requirements.

Order Management Is Not a Customer Order Capture System; it Is a Synchronization System

The many research sources consulted to complete this report share a common theme, which is the progression order management system early adopters make from order capture first, then into synchronizing all their warehouses, distribution centers, and fulfillment functions globally. The order management function within most ERP systems, however, does not provide support for many of the requirements of these extended global fulfillment functions, which, in addition to order capture and processing, might include the following:

Operating 24-hour call centers

Distributing product information or discussing product features and capabilities

Using and understanding product catalogs

Performing price lookups

Supporting ongoing problem resolution dialogs with customers

Identifying spares and service parts

Reacting to special customer requests

In ERP systems, the customer service capability revolves around the order. Without first entering an order, there is usually little or no access to product information, prices, or a placeholder for customer requests. This is one of the primary market factors influencing the growth of distributed order management systems. Figure 2 shows the intersection of customer support, collaborative planning and replenishment, order management, order fulfillment, and order entry on the business process phases that distributed order management needs to successfully support.

Figure 2:

Overlaying business process steps with order management system components

While these process steps vary by industry, they do provide a common basis of comparison across industries. Appendix B, Distribution of Order Management Systems by Industry, provides a useful glimpse into the specifics of how each industry adopts distributed order management best practices.

Part 3: Literature Review

In completing this literature review, it became apparent of how intertwined order management and the broader aspects of supply chain management have become. Inherent in this literature review is the role of the supply chain in influencing the synchronization of orders throughout multiple distribution centers, fulfillment locations, warehouses, and secondary channel partners. A high percentage of companies -- around 30% -- live in a world based on the complexity of the demand chain and diversity of supply chain relationships. In the past, companies have organized the business structure around channels/segments, products/supply chains, and geographies to minimize complexity. However, the move to global processes and the demand from customers to have a more unified relationship is forcing companies to rethink the systems approach and organization alignment. The approach requires a new strategy, and ERP systems will provide local execution, but not the global integration and coordination. The approach is not about functionality; it is about achieving process flexibility and data rigidity to support a distributed process.

All of these factors are propelling distributed order management as one of the top priorities for manufacturing and service companies alike.

Systems architectures must be redeployed to deliver on an integrated order management strategy

While a single instance ERP system may not be the long-term solution to the extended order management vision, it will continue to be a critical building block, providing much of the master data and transaction processing. The question is not whether there is a role for ERP systems in the order management process, but rather is it the architecture to provide the integration and coordination across the extended internal and external network of suppliers, buyers, and customers. The monolithic design of all ERP systems requires that all channels, business units, and supply chain organizations come to an agreement on the configuration of the system and the data model. 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

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 inventory status. From an ERP perspective, this view may be limited or enhanced by available-to-promise (ATP) or capable-to-promise (CTP) functionality provided by APS. In some environments, such as traditional and virtual distributors, source may be tightly coupled with procurement.

Deliver

In deliver, the final product is picked, readied, packed and shipped to the customer. The basic theme of pick-pack-ship varies by product and channel. In some environments, an enterprise may add a great deal of value between pick and pack. For example, a Consumer Electronics manufacturer employing a postponement strategy may assemble final product against specific orders between pick and pack. On the other hand, the pick-pack-ship operation adds scant value in deliver for a Shoe manufacturer.

Settle

Settle uses the business rules and data associated with the order at capture and modified in source and deliver to drive all accounting and financial transactions such as accounts receivable, billing, and cost accounting needed to close the order. Settle applies these rules and data to heed the customer/order/invoice logic governing the transaction and to allocate discounts, credits, and allowances in conformance to the customer's organization structure and accounts payable business rules. Settle also uses the same information carried by the order for internal cost accounting by customer account and cost centers for various trade funds.

All these factors within a distributed order management system contribute to the growth of the Demand Driven Supply Chain (DDSN), which was defined by AMR Research within the last five years. The progression as it relates to distributed order management is illustrated by the Table 1, DDSN Leadership Characteristics.

Table 1: DDSN Characteristics

Part 5: Method and design

The method and design used for completing this analysis relies on the AMR Research order management hierarchical model and the Demand Driven Supply Network (DDSN) model as the basis for analysis overall. The hhypothesis is that distributed order management systems significantly increase transaction velocities. The variables used in this analysis include the market sizing for global distributed order management systems in key vertical markets, transaction velocities before and after system implementation (measured in inventory turns), and a definition of the size of the markets for sourcing, brokering, service lifecycle management, and reverse logistics applications acquired, installed, and used within each vertical market.