I was speaking with a colleague recently about WMS implementation projects and the challenges in managing the various stakeholders in these initiatives. Our conversation progressed (devolved?) into a discussion on the history of warehouse management software and the maturity of the market and I thought this would be an interesting topic to open up for discussion with the community at large.  I believe that by viewing the history and current state of the solutions and the vendor practices we can discern a direction for the future.

 

In the beginning there were custom developed applications that were developed by the large enterprises to support their specific needs and practices.  These large companies were able to develop extremely robust, and highly customized, applications to support the individual and specialized needs of the individual enterprise.  At the same time consulting organizations came about to provide the specialized and industry experience (along with additional bodies to support the short term needs) that they gained by supporting different enterprises in their initiatives.  The nature of these initiatives and the focus of the requirements and applications were on the based and designed around the specific individual needs and specialized requirements of each enterprise.  These specialized needs included product handling, building configuration, material handling equipment integration, supplier requirements as examples.   At this time each enterprise looked at the ‘way’ they performed activities as differentiating factors.

 

As time progressed and the software and automation market grew, the consulting organizations that specialized in supply chain management realized they could reuse many common modules for different clients, with client specific modifications, of course.  This concept provided a differentiating factor for their services.  While the end result was still a custom application, it started with a framework of common processes as its base.  This progressed as consulting organizations matured and developed a library of best practice modules to offer to their clients.  After a period of time some of the consulting organizations marketed their best practice modules as software packages.  When these software packages were initially offered there was still a high level of customization that was provided by the vendor to support the individual customer needs.  The advantage of the software package model was that the software would be continuously improved by the new features requested by other customers to meet the needs of their business.  This also brought about a shift in the enterprise focus to ‘exemplary execution’ of the activities; it wasn’t the way they performed the activities, it was the efficiencies in the performance that made the differentiating factor.

 

I suggest that ‘software package’ is almost a misnomer in supply chain management software because of the high level of customization that is still required/supported and even encouraged by the software package vendors.  Each customer requires custom services to ‘tailor’ the package and capabilities to the individual and specific requirements of the customer.  Granted, the level of feature customization has been dramatically reduced when compared to the initial releases of the software packages, but every implementation requires a certain level of customization and configuration to support the client requirements. 

 

Don’t get me wrong, the progression of capabilities and maturity of the software ‘package’ has been dramatic in both features and functionality along with ease and speed of implementation.  I’m saying though we still have a way to go to get to a state comparable to the shrink-wrapped photo customization software as an example.  I suggest that one way to measure the maturity of the software package is to measure the contribution of services to the revenue of the software package vendors.   In other words, as the services revenue shrinks for the software package vendor, the maturity of the package increases.  This maturity level is also mirrored by the maturity level of the clients that implement the software, the customer maturity has progressed from absolutely requiring customization of the package to fit the customer requirements; to a current state where many customers will revise their business process to fit with the package capabilities. 

 

I believe there is a ‘test’ coming from the capabilities and promise of cloud services that could bring a major upheaval to the SCM software package market.  As I mention in an earlier article (https://community.kinaxis.com/blogs/TBrouillette/2011/06/29/the-perfect-storm--the-legacy-applications-landscape) the potential for upheaval will be similar to the introduction of the ‘office’ software package.  Our test in technology is how we will handle the integration, collaboration and communication challenges, and promise of benefits, provided by cloud services.  This upheaval will also drive initiatives to increase the maturity level of both the SCM software packages and the capabilities and practices of the customers implementing the software and cloud services.

 

Now for the audience participation portion of this program……

 

What is your experience with the market and implementation?  Have you seen a progression of maturity?  How do you see the cloud services impacting the software vendors and the consumers of this software and services?

 

How can this community help you to move the conversation forward in your organization? 

 

Tom Brouillette – President & principal Consultant

Monarch Supply Chain Management, LLC

www.monarchscm.com

‘the logical choice’