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.

« Energy Sector and the Supply Chain | Main | Globalization trends in Supply Chain … Its just getting riskier! Are we seeing a turn-around in supply chain thinking? »

Warehouse consolidation: managing effectiveness

Consolidation has been traditionally looked as a mechanism to bring in economies of scale. Of late, organizations that operate across geographies are investing to standardize processes, execution models and technology in the warehouses. The context of warehouse processes and information resident in there, has changed in the supply chain architecture. Warehouse level information now is being "consumed for efficiency and better customer response" correlating to order/demand and inventory position information in more real time. Consolidation programs that embed process, technology and operational standardization therefore can greatly simplify journey towards this "enhanced warehouse awareness" in their supply chain and help differentiate the fulfillment execution.

As an architect, I have been involved with a number of such programs and have seen that warehouses being execution centric, a standardization approach needs to consider factors specific to every warehouse like working policies, use of automation and robotics technologies, handling of specific goods and delivery of value added services apart from warehouse layouts. Given such local dependencies, WMS consolidation initiatives must allow reuse or adoption of local mature practices while conforming to the template of global practice and design.

Standardization approaches that cross-pollinate the local and global best practices through a productized platform assumes importance since rollout of such initiatives across the organization could incur cost and time overruns in the absence of a well defined structure or "template" across the layers of process and operation.

A number of package vendors indeed address this need by providing a multi-WMS modeling capability through their products. The rationale being to introduce a product model that digitize local and global concerns and then uses one set each for every warehouse as its WMS application. All such WMS are logically within a single product container or instance, creating a cluster of WMSs. I have seen interesting words been used to describe such a collocation like "nWMS". While such products do provide foundation to streamline processes while minimizing technology sprawls, interesting new practical problems crop up in this equation.

As an example, it is very common to have WMS information flows interleave with material handling equipment through automated interfaces to execute a local move operation. In a centrally hosted model where the WMS application resides in a remotely accessed datacenter, network latency can cause material handling equipment to halt. For any fairly distributed fulfillment network, a network infrastructure to support coordinated floor level automated execution from a centrally hosted WMS container is quite a capital expense implication. Additionally given today's fulfillment approach of integrating fulfillment centers beyond organization control boundaries (that of a 3PL or of a drop ship supplier), it is not easy to realize such a level of investment across the board.

As a counter alternative, hosting the WMS application within the warehouse network would cause TCO of consolidation to exponentially increase given the server capital expenditure implication. Additionally rooling up to the multi-WMS product model would need additional information technology costs and lead times in terms of investment of additional extraction and load mechanisms to the central store. In terms of supply chain architecture, the "enhanced warehouse awareness" starts getting into an increasing cost spiral.

On top of this, there is also a need to factor in change effects that creep in over time such as acquisition of a fulfillment company to expand network reach (this would just set back consolidation progress by a few quarters considering the WMS which comes along it!!) or changes in physical technologies that were used in the warehouse floors following end of life. We have been grappling with this challenge of addressing the right "physical location" for the multi-WMS product based programs few years back and realized that "instance strategy" needs to be in control for consolidation programs to keep moving ahead.

Considering the many moving parts to the puzzle, Girish, Gopi and I attempted to create a equation that helps to assess and more importantly "control" instance location decision at a given point in time taking relevant organizational, business process and information technology dimensions as inputs. 

With emergence of SOA, benefits of mega consolidation initiatives have been challenged as an alternative route has emerged. SOA directly solves warehouse information integration within supply chain architecture in a shorter lead time and help track metrics of operations across warehouse facilities. The separation of service consumer from service provider through a well established relationship infrastructure (called contracts and policies) helps to stop worrying about the option (and the underlying cost and change implication) of standardization to achieve "enhanced warehouse awareness"

SOA, although appears disruptive to consolidation, in my view, can be applied to de-couple the consolidation programs from the "need to deliver results immediately" pressure. As an example, consider acquisition of a fulfillment player by another, a SOA based architecture can ensure that acquired WMS landscape is not altered and therefore avoid operational disruption while allowing information integration to "feed" the network. This loose-coupling allows consolidation programs the latitude to choose the right time to bring the acquired ecosystem within consolidation's focus probably coinciding this with technology refresh or end of life trigger. In effect we would be giving the much needed time to change the enterprise building blocks (at business, technology, operation) one at a time and avoid physical and information technology realities from disrupting the consolidation by reducing moving parts and their complex effects. 

Interestingly, we are seeing two key trends in enterprise technology space. One is the adoption of streaming as a concept in enterprise operations. Today desktops are streamed from a central location to aid what kind of work an individual requires to undertake. Second key trend is increasing emergence of a culture of business driven IT configuration; web2.0 and enterprise mashups are the case in point. Streaming as a concept lends well to the WMS consolidation where the WMS for a specific warehouse having intelligence and configuration for of its local "realities" is streamed to the facility promoting a local execution but central governance model. Mashup culture can invade the local process configuration subject and make the warehouse become a center for operational innovation driven by on-ground experience getting centralized in the unified configuration repository. While it is quite obvious that such concepts require lot of agility in infrastructure and information technologies, the fundamental need of managing effectiveness balancing impacts and end objective becomes even more crucial. 

Instance strategy looks to be one of the right control levers as the pursuit of standard common ecosystem for "WMS"s across the enterprise and supply chains continues to become realities from utopia.....


Hey Sat - This ties in nicely to the paper we wrote on this along with Girish (available at scm whitepapers for those interested). From an overall standpoint, the essence of consolidation or even deciding what to consolidate and what not to has to consider all the three key axes - maturity of processes, maturity of software systems and maturity of capex investments like MHE and advanced picking systems, dock level automation and other instrumentation aspects.

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