Dan Wood - SAP SCM: Applications and Modeling for Supply Chain Management (with BW Primer)

For Gerald

New technologies for supply chain management and flexible manufacturing imply that businesses can perceive imbalances in inventories at a very early state-virtually in real time-and can cut production promptly in response to the developing signs of unintended inventory building.

Alan Greenspan

Former Chairman of the Federal Reserve Testimony to the U.S. Committee on Banking, Housing and Urban Affairs

February 13, 2001

xiii

xv

Consider boats. Let us imagine that we are a tropical tourist outfit and we have at our disposal a variety of small boats: a canoe, a speed motorboat, a double-sail schooner, and a catamaran. Imagine too that we have a body of boatmen and sailors who are trained and competent to maintain, navigate, sail, and otherwise put our small boats to good use and that they do in fact do just that on a daily basis, employing our small flotilla in some manner of productive economy, but economy that is limited to the scope and capabilities of small vessels, probably extending its reach no further than local seaways. Finally, imagine that we have recently paid for a rather nontrivial upgrade to the fleet, having just purchased several large yachts.

Obvious to everyone will be the fact that the yachts enable us to expand our economy as never before possible when we were limited to the small boat flotilla. The yachts have radar and satellite linkups to avoid bad weather, fuel stores to enable long journeys, and mass to handle tough waters. The yachts are big and can comfortably carry more people-scientists, merchants, diplomats, vacationers-all of whom may add value and opportunity to our oceangoing journeys. The yachts are not an upgrade of quality, such as a sturdier canoe, a speedier speedboat; rather, they are an upgrade of class. Most important, that the yachts constitute an upgrade in class, such that both a retraining of our entire staff and an expansion in the scope of our operations is necessary to fully exploit them, is an inescapable reality made obvious by the simple physical presence of the yachts themselves.

In the manner of their physical presence, we must say that boats have something over software. I studied decision and information systems at the university level for some five years in the early 1990s and had the fortune of working as a research assistant with one of my professors, which further exposed me to the state-of-the-art research of the day. At that time academic research in advanced decision methodologies was approaching a nexus with advancements in computer technology that promised to make a new class of products available to organizations and commercial interests with capabilities that had previously been limited to the ivy walls of research journals and the academy. Something was in the oven, but it was still baking.

So, in 1997, when SAP AG released Advanced Planner and Optimizer (APO), I understood that this was something different. In some ways, at the time, SAP had been perceived as behind the curve in decision support systems for supply chain planning. Other companies had already produced highly effective products for forecast and demand management, and SAP was coming from behind. Planned or not, there was something strategic to SAP's timing. Other companies had been, and to this day largely continue to be, content to offer single-problem solutions: a tool for demand management or a tool for shop-floor control. SAP APO was not just one more toolset alternative for forecast and demand. Like all of SAP's products, APO was integrated: integrated with supply planning, procurement and production planning and execution, reporting and advanced data analytics, and, as a decision support system itself, integrated with SAP's transactional data management product, R/3, in such a way that it could be used to largely control R/3 transparently without requiring that the end-user move back and forth between tools.

As it was an integrated, complete planning product, I understood that APO constituted what we were anticipating in the early 1990s: a software product that leveraged off of faster, smarter microchips and operating systems with large memory wells to combine all the best-known methods of the various supply chain planning disciplines into a potent package for total supply chain planning. In APO was found tools for conducting univariate analysis and multiple linear regression as well as lifecycle planning for demand forecast and management; heuristics, priorities, and linear programming for supply network planning; specialized heuristics for the combined needs of procurement execution and production planning; and specialized optimization algorithms for shop floor control. All of this was in one tool.

If previous applications that had been applied for supply chain planning were littoral boats, APO was a veritable blue-water, oceangoing ship. To the trained eye, APO represented a whole new class of supply chain planning software. I was impressed. To my mind, on seeing APO, I understood that this was the "it" that had been in the oven. The problem was that having primed for APO in college, I was ready to be impressed-I was prepared to recognize APO for what APO is: a whole advance in class not unlike the upgrade from speedboat to yacht. What I could not be prepared for was that everyone else was not so well primed. What was evident to me was not apparent to everyone else in a position to adopt or effect the adoption of APO.

That mattered. Upgrades of class are not trivial. We would not assign our speedboat crew to a yacht without substantial up-training. Furthermore, we would not limit our new yacht to the shipyards and littorals of a speedboat; we would let it get out and sail! Alas, APO is software, and software is not like a boat or ship. The yacht by its mere physical presence makes both its superiority and superior demands known to all who gaze upon it even if they have no specialized knowledge of ships and boats. Though one software application may display cool graphics and do some quick math, while another comprehends entire global supply chain networks using the same mathematical features previously limited to weather simulators running on supercomputers, both applications present on the same compact diskettes and both applications are reduced to the same 12-by-16-inch monitor when employed by the end-user. How are end-users, executives, and in many cases even developers to know that something more than evolution has occurred?

The failure of organizations to culturally adapt to the change in class represented by APO has at times led to occasion for disappointment. In the time since APO's release, I have watched or heard of organizations whose labors to adopt APO proved frustrated or for naught. The reasons for failures are manifold. Sometimes we have end-users who are insufficiently trained because the difference between APO and their previous legacy software tools was not appreciated by executives and project planners who sought to keep training costs low by limiting training exposure to project teams rather than project customers. In other cases, developers and project managers have advanced knowledge of technical features of APO but insufficient knowledge of the underlying supply chain disciplines or the essential points of integration of those disciplines to successfully bridge the gap between technology and application. We find managers, executives, and whole organizations whose perceptions of the software overcame the facts about the software and who in turn found their way into strategic decisions that torpedoed projects. Such false perceptions hamper the software with expectations it was never meant to rise to (i.e., even yachts cannot fly and even APO with its global model of the supply network cannot think). Those perceptions may also lead to the misapplication of modules either for expeditious reasons (i.e., it is thought to be cheaper to apply one module to two problems rather than two modules to problems appropriate to their competence) or out of literal ignorance.