The Infosys global supply chain management blog enables leaner supply chains through process and IT related interventions. Discuss the latest trends and solutions across the supply chain management landscape.

« Parameters to design your supply chain organization | Main | How to define boundaries for Supply Chain Operations between EAM & ERP »

Distributed Order Orchestration implies channel reduction?

The other day, a colleague of mine sent me the brochure of Oracle's fresh pitch to the multi-channel world titled "Oracle Fusion Distributed Order Orchestration - The New Standard for Order Capture and Fulfillment". While the DOO terminology is a slight tweak on the more popular Distributed Order Management (DOM), I read through and noticed a fundamental difference in the pitching of the offering. The text goes thus:

Today, almost all companies manage multiple order capture and order fulfillment systems. In fact, studies show that the average company has 5.2 order capture systems and 4.3 order fulfillment systems. These overlapping and redundant systems create inefficiencies in terms of cost and service. Gathered through channel growth and acquisition, reducing the number of these types of systems is an extremely difficult endeavor with a high degree of risk. For that reason alone, not many organizations are willing to undertake projects that rationalize or retire these systems. Oracle's solution to this dilemma is Oracle Fusion Distributed Order Orchestration, a key component of Oracle Fusion Supply Chain Management. Unlike any order capture and order fulfillment platform in existence today, Oracle Fusion Distributed Order Orchestration seeks to normalize processes and data across multiple capture and fulfillment systems, yielding a single view of order and fulfillment information and decisions.

Right off the bat I was wondering whether Oracle is saying "thou shalt reduce your order capture and order fulfillment system"? Noble objective for sure and quite simplistic, but it does come with a bunch of qualifiers. A step back into understanding why these systems came in the first place could illustrate why the DOO argument is not so much of a can-DOO in all situations. Order capture channels proliferated because customers wanted those choices - to walk into a store to touch/feel stuff, to click a promo email & buy through the net, to search & compare from a mobile phone, to rant & rave by calling up a call center (regardless of the 1-800-WAIT-ING lines). Most of the order capture channels were a reaction to customer behavior, so its no use saying we're going to reduce it.

The second part of the story is in the fulfillment side of the house. If the objective is to pick up inventory wherever its lying around (store warehouses, distribution centers, factory warehouses, 3PL storage etc), ship it to the customer and support suppliers via multiple fulfillment models (supplier to end customer or to any hops in between), why would a retailer want to lose that flexibility? The challenge to supporting these order fulfillment models is that in most cases, they exist in their own splendid isolation without even providing visibility into what they are holding let alone more complex asks like supporting split fulfillment.

In summary, the objective regarding "distributedness" should be around "managing" (rather than reducing) these channels. That would mean regardless of from where orders are coming in or items are going out (or how orders are getting split across fulfillment channels), back-end operations remain transparent to the customer. Consequently, there should be no heartburn in all the three primary super-cateogories of order management metrics - customer experience, inventory utilization and cycle time.

Where does channel reduction make sense? If there are half a dozen systems all for capturing orders from stores (for instance, based on geographies, product categories or brands), then there may be a possibility of making life a wee bit simpler for the hapless folks tasked with capturing all those orders (assuming the burden is outside customer's responsibility!). Also, due to M&A, if the acquired company's processes & systems are at divergence to those of the parent company, there would be possibilities in cutting down redundancy. Ditto with under used facilities and too many cross-links from suppliers to various holding points. Where there is duplication, there does exist a case for reduction of channels, but where an organization is catering to multiple forms of order capture and fulfillment, that would be part of the competitive advantage. And one really wouldn't want to reduce that I suppose.


Very valid points raised in the blog. However I wonder if Oracle is really positioning this product as a "channel reduction" tool. I suppose this is more of a dash-board which orchestrates the processes and data across multiple capture and fulfillment systems. This dash-board, I believe, can give a real time visibility across the supply chain- and the channel redundancy identification and possible reduction/ rationalization of channels can be an added benefits/outcome of such a visibility.

Helped design and validate the use cases for DOO early on, with the notion that DOM’s do not support or monitor the full life cycle of a transaction and are one more system to maintain in the Order to Cash cycle.
As you point out, once use for DOO is supporting phased front and back office consolidation, but the real value is in supporting rapid assimilation of newly acquired order management systems and providing a centralized order management tool to monitor and evaluate order transactions from front office to back office. This includes jeopardy management and transactional change or delay cost modeling and evaluation across multiple sources.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter