Let's call the hypothetical system described in the preceding section, the "Real-Time In-Store Reordering System" (RIRS). Traditional IT methodologies call for developing business requirements for such a system and then going through a build vs. buy analysis to find a suitable IT solution. A buy analysis examines commercial off-the-shelf (COTS) packages that provide the requirements needed for RIRS. To be commercially and financially viable, developers of COTS applications have to ensure that their offerings address a wide range of industries and problems. A buy analysis leads to a short list of products that have much broader functionality and features than called for by the business requirements of the RIRS.
Nevertheless, if a packaged COTS application is available, the prevailing wisdom is to buy and implement that solution instead of developing an in-house custom solution. I have personally experienced numerous situations where this approach leads to failure. First, the features and functionality of the COTS package tends to be extensive, spanning hundreds of screens and menu options, while the need for the RIRS may be for two screens and three menu options. The in-store manager or back-office order entry staff may find the application difficult to navigate and use properly. Just think of how feature laden office productivity applications are and how few features the average user uses!
Another challenge is the application, data, and process integration needed to deploy the COTS package. Despite IT vendor protestations to the contrary, integrating a COTS package within existing SCM and POS technologies is a difficult challenge. The integration process can lead to situations where the real-time nature of the RIRS can be compromised due to data and application integration challenges. After working through these challenges, the result typically tends to be a COTS package that is riddled with workarounds and doesn't deliver on the stated business goals!
A general-purpose RIRS, while compelling, isn't feasible as the distribution channels differ significantly across different retailers, manufacturers, and product categories. Wholesalers, manufacturer, retail or category management distribution centers, or contract logistics providers perform the actual process of "breaking bulk" from manufacturers, sorting and customizing to different market needs, and shipping to retail outlets. Every entity that performs a market distribution function has its own unique business processes and supporting IT systems. For RIRS to function, successful solutions need to work seamlessly with the retail distribution process and systems already in place. Clearly, this integration dictates the deployment of a custom business process that works with the existing supply chain.
This approach calls for an IT solution that is narrow in functionality and features (addresses the in-store reordering needs and nothing more), but broad enough to coordinate the reorder activities across the supply chain. RIRS can never be fully automated and will require in-store interaction. For example, when the fall season is over, you wouldn't want the RIRS ordering more fall fashions because of a potential OOS situation. There are situations where the store manager may deliberately seek to discontinue sales of a particular product category.
Having a simple RIRS with focused functionality (two screens and three menus) has a better chance at reducing the OOS situation. The traditional training and methodology imparted to IT professionals (including myself), leads us to overanalyze and overengineer solutions to business problems. Simple solutions that solve a specific business problem (no more and no less) in a timely and reliable fashion can deliver business value not only in OOS situations but across the entire enterprise as well.
DECOMMODITIZE IT SOLUTIONS!
Take an inventory of successful IT solutions that are running your corporation's key business processes. An unbiased assessment may reveal certain legacy systems with limited functionality that have been around forever. Numerous attempts to replace this clunker of a system with more elegant, integrated, state-of-the-art technologies have failed over the years. The main reason for disliking the legacy system is often that it's too simple and limited in what it does. Finding a COTS substitute may prove to be difficult as the legacy application supports a business process unique to that particular retailer and supporting supply chain.
This is an example of an IT solution that is not a commodity. The clunker of a legacy system provides a unique competitive advantage to that company and is difficult to imitate, as it enables a business process specific to that company and supporting supply chain. Simple solutions tend to decommoditize IT solutions by supporting unique business processes that are difficult to imitate.
As an IT discipline, if we set aside our natural bias to solve "enterprise-class" problems, we'll realize that "simple" solutions with narrow functionality have delivered tremendous value to corporations over the years. The frustration with these simple solutions stems from having to manage a diverse set of custom solutions, built on diverse technology platforms.
My response to the problem of managing multiple simple solutions is, if a simple custom IT application can deliver business value, the long-term maintenance costs should be evaluated within the ROI context for that business project, not within the conventional wisdom of the total cost of ownership (TCO) approach or a common IT budget. In my opinion, the TCO approach swung the pendulum to the other extreme to standardize and commoditize IT functionality. The simple solution approach (narrow feature set and deep integration across the supply chain) not only delivers immediate and compelling business value, but also decommoditizes IT applications. Most important, the focus of simple solutions is on keeping the customer satisfied by ensuring fully stocked store shelves, as opposed to enterprise solutions seeking to reduce TCO.