SAP SCM E-Book

Dan Wood

• Herausgeber: John Wiley & Sons
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 641

Veröffentlichungsjahr: 2007

Beschreibung

SAP SCM: Applications and Modeling for Supply Chain Management empowers you to capitalize on the sophistication of SAP APO. This book provides clear advice on the inevitable, critical decisions that can lead to project success or failure and shows you, wherever you are on the supply chain management staff--buyer, planner, ground controller or analyst--to fully exploit the agility SAP APO offers.

Leseprobe

CONTENTS

Preface

Acknowledgments

Table of Abbreviations

Part 1: Cultural Background: The Business and Technical Context for SCM

Chapter 1: How to Use This Book: APO as a Mind Map

One Book, Many Curriculums: Custom Recommendations for Reading Order

Included and Excluded: Scope of this Text

Chapter 2: SCM Architecture

Enterprise Landscape for Planning in SCM

SCM Applications and Components

Simulating the Supply Chain

APO Tools for Users

Chapter 3: Supply Chain Landscape

Supply Chain Landscape

Planning Supply Chain Disciplines

Supply Chain Data Pipelines

Integrated, Wall-to-Outside-the-Wall Supply Chain Solution

Chapter 4: Advice to the Executive Considering SAP APO and SCM

Six Short Executive Lessons in ERP

Profile of an SAP SCM Project with a High Likelihood of Success

Part 2: Stocks and Bases: Master Data SCM

Chapter 5: Supply Chain Management Master Data

Locations and Calendars

Products

Resources and Work Centers

Production Process Models and Run Time Objects

Transportation Lanes

External Procurement Relationships

Quota Arrangements

Models and Planning Versions

Transactional Data

Master Data Recipes

Chapter 6: Analytical Master Data: BW Primer Part I

SCM versus “Analytical” Master Data

Star Schema

BW, APO, and Analytical Data Objects

BW in the SCM Data Mart

Setting Up Analytical Master Data

Chapter 7: Core Interface

When R/3 Is Not the Transactional Data Management System

Using R/3 with APO

Basic Integration Model Configuration

Part 3: Entrees: APO Planning Modules

Chapter 8: APO User Interfaces and the PP/DS Module

General APO User Interfaces

PP/DS Context

PP/DS Master Data and CIF

Using PP/DS

Configuring PP/DS

Detailed Scheduling and PP/DS User Interfaces

Chapter 9: Demand Planning Module

DP Master Data and CIF

Using DP

Configuring DP

Univariate Forecast

Demand Planning Configuration Recipe

Chapter 10: Supply Network Planning

SNP Master Data and CIF

Using SNP

Configuring SNP

SNP Configuration Recipe

Part 4: Beyond Planning: Analytics, Collaboration, and Keys for Success

Chapter 11: BW Primer Part II

Not Just a Data Warehouse: Reengineering ERP

Using BEx

BW Enterprise and BW Data Mart

Profile of a Full-Powered APO Deployment

Chapter 12: Inventory Collaboration Hub and APO Collaboration

B2B Context of ICH and Collaboration

ICH Master Data

Using ICH and APO Collaboration

ICH Data Pipelines

Chapter 13: The Lucky Chapter: Of Boats and Software—Four Keys to Unlocking SCM

“Keys”: To Neuter a Cliché

It’s Only a Key If You Know It’s a Key

The Keys

What Would You Pay For Wal-Mart’s or UPS’s Supply Chain?

Index

Copyright © 2007 by John Wiley & Sons, Inc. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400, fax [phone], or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone].

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services please contact our Customer Care Department within the U.S. at 877-762-2974, outside the U.S. at 317-572-3993 or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print, however, may not be available in electronic format.

For more information about Wiley products, visit our Web site at http://www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Wood, Daniel C., 1972-

SAP SCM : applications and modeling for supply chain management (with BW primer) / Daniel C. Wood.

p. cm.

Includes index.

ISBN: 978-0-471-76991-0 (cloth)

1. Business logistics–Computer programs. 2. Production management—Computer programs. 3. APO. I. Title.

HD38.5.W66 2007

658.70285′53—dc22

2006029337

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

PREFACE

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.

In the former case, where some exaggerate the ability of APO to plan a network independently of qualitative, human management of planning, we find that two kinds of resistance emerge. The first is from employees who feel threatened and are (rightfully) unwilling to cede final judgment of supply planning over to a computationally smart but qualitatively stupid computer; and the second is from reality: APO, properly applied, enhances the human judgment of buyers, planners, and controllers in the same way a weather simulator enhances the judgment of meteorologists. APO is not an artificial intelligence (AI) product that replaces people.

In the latter case we have seen where developers trained in one module such as Demand Planning (DP) or Supply Network Planning (SNP) have made biased recommendations, assuming, for example, that the Production Planning/Detailed Scheduling (PP/DS) module is strictly a shop-floor control product without useful application for subcontractor planning when, in fact, only the DS part of PP/DS is for shop-floor control and the rest is expected, by the product’s designers, to take over from SNP wherever the procurement execution horizon starts. Such ill-advised decisions result in the attempt to apply relatively strategic modules like DP and SNP to tactical problems that they were not designed to manage but for which PP/DS is explicitly intended.

The failures of some notwithstanding, APO is still an oceangoing ship and the competition, whether from outside providers or internal, legacy products, remains limited to the lagoon. APO, especially today in 2006, with even more powerful features of the Supply Chain Management (SCM) package in which it comes, packs a powerful punch. I believe that APO can change the economy. Aggregate, macroeconomic efficiency gains in demand and supply planning that result in less of the wrong inventory, more of the right inventory as well as the right product at the right place at the right time, multiplied by thousands of organizations and millions of products, may materially affect the gross national and international economy, increasing efficiency and productivity. The nice thing is that we do not need to reinvent the wheel: Academic researchers have been studying and proving the methods packaged in APO for years, and SAP has already coded the product for us. The challenge is in adoption and the obstacles to adoption appear to be both psychological and practical. Psychologically, we need to get a handle on what we are working with. Practically, we need an easier way to master the learning curve associated with this powerful new tool. SAP SCM succeeds for organizations when teams understand the strategies necessary to make it work. What is necessary is a common map that meets the needs of all the stakeholders who come to SCM: developers, project managers, executives, and end-users alike. I hope that this book rises to become that map.

Daniel C. Wood

January 2007

ACKNOWLEDGMENTS

In considering the variety of people who’ve contributed directly or indirectly to the development of the book, its seems to me that most fall into any of three categories: those who introduced me to the world of SAP and SAP SCM, those who taught me SAP products including SAP SCM, and those who in one way or another helped directly in bringing about this book. Considering the first, I should express thanks to Mark Zinsli, who, back in 1996, long before it ever was really relevant to my job role, allowed me to take courses in SAP R/3 architecture, data models, and ABAP programming. I must further thank Janet Kerby, who deserves credit for bringing me officially into the world of SAP, “under false pretenses,” as she artfully puts it. Thanks, too, to Bob St. Louis for the early seeding of this book by exposing me to the state-of-the-art research at a time when APO was probably still just a glimmer in SAP’s eye.

As regards those who have at one time or another taught me something of the uses of SAP products, particularly planning products, here I know for sure that I’ll go amiss as there are simply too many to remember, let alone mention. Thanks to Peter Kaiser, my very first SAP instructor. Thanks to David Wiley and Gautam Bhattacharya, my very first APO instructors. Thanks also to Bharad Wuppalapati and Steve Blair, who, though never formal instructors, brought me to pace on master production scheduling and materials requirements planning. Hilmer Hintz deserves mention as hands down the best SNP and PP/DS instructor one could ask for, which, as someone who took each class two or three times, I feel well qualified to assess. And among that wide variety of people who never taught a course (at least for me) but who at one time or another engaged with me on one feature or another of SCM that increased my knowledge with bits and pieces that may have found their way into this book, thanks go to Justin Weyand, Chak Tongsak, Jennifer Newman, Rammohan Basineni, Michael Hawkins, Brian Lyles, Tajinder Singh, Chandrasekhar Reddy, Sunil Chebiyam, RJ Ramirez, Bryce Duck, Anupama Velayudhan, and my intro-to-SCM co-instructor, Kamlesh Porwal.

Finally, there are several who provided direct support to critical tasks, decisions, and approvals that led to the production of this book. Thanks first to Steven Miller for the early managerial endorsement, and later to Carl Muppaneni, who inherited me. Exact etymological history is unknown but somewhere between Steven Miller and Steve Blair there lies credit for perhaps one of the most critical pieces of advice found in this text: the “98% solution” in Chapter 4. Thanks many times over to my editor, Sheck Cho, who believed in the project and who exercised mythical patience while obstacles of familial crises followed by byzantine organizational approval processes by no less than three companies and by my infrequent but often-enough writer’s block got in the way of expeditious authorial output. Thanks to Greg Valdez, without whose managerial imprimatur this project would never have gone forward; thanks to Robb Gordon, without whose legal shuttling this project would never have gotten off the ground; thanks to Joel Levinson, without whose celestially timed intervention this project would have surely died an ignoble bureaucratic death; and thanks to Andrew Benton of SAP AG, without whose lawyerly approval from SAP this project would be but for naught. Thanks, of course, to Patara Yongvanich of SAP AG for connecting me with the critical and indispensable Ricardo Poli, also of latter company; and last but absolutely not least, thank you several times over to Ricardo (and all your agents and supporters at SAP Labs in Palo Alto) for being an excellent host while I surfed SAP systems for screenshots.

TABLE OF ABBREVIATIONS

APICS

Formerly the American Production and Inventory Control Society, now the Association for Operations Management

APO

Advanced Planner and Optimizer (version 3.1)/Advanced Planning and Optimization (version 4.0+)

ASN

Automated Shipping Notice

ATP

Available to Promise

B2B

Business-to-Business

B2C

Business-to-Customer

BAPI

Business Application Programming Interface

BEx

Business Explorer

BI

Business Intelligence (see BW; historically a general term for advanced analytic reporting technologies—now applied more specifically by SAP AG)

BKM

Best Known Method

BOM

Bill of Materials

BW

Business Information Warehouse (NOTE: At the time of this text’s publication, SAP AG was in the process of re-naming BW to BI. For some time, therefore, readers may expect to see both the terms BW and BI used interchangeably for the same product)

CIF

Core Interface

CRM

Customer Relationship Management

CTM

Capable to Match

DCM

Delivery Control Monitor

DEPREQ

Dependent Requirements

DP

Demand Planning

DSS

Decision Support System

EAN

European Article Number

ECC

Enterprise Common Core

ECM

Engineering Change Management

EM

Event Management

EPR

External Procurement Relationships

ERP

Enterprise Resource Planning

FC Req

Forecast Requirements

GATP

Global Available to Promise

GR/GI

Goods Receipt/Goods Issue

ICH

Inventory Collaboration Hub

IM

Inventory Management

IMG

Implementation Guide

INDREQ

Independent Requirements

IT

Information Technology

MDM

Master Data Management

MLR

Multiple Linear Regression

MM

Materials Management

MPS

Master Production Schedule

MRP

Materials Requirements Planning

nMPS

Network Master Production Schedule

OLAP

Online Analytical Processing

OLTP

Online Transaction Processing

PDS

Production Data Structure

PIR

Planned Independent Requirements

PLDORD

Planned Order (R/3)

PlOrd

Planned Order (APO)

PP

Production Planning

PP/DS

Production Planning/Detailed Scheduling

PPM

Production Process Model

PURREQ

Purchase Requisition

R/3

SAP’s flagship enterprise resource planning system

RFID

Radio Frequency Identification

RN

RosettaNet

ROI

Return on Investment

RTO

Run Time Object

SA

Scheduling Agreement

SCC

Supply Chain Cockpit

SCE

Supply Chain Engineer

SCM

Supply Chain Management

SEM

Strategic Enterprise Management

SMI

Supplier Managed Inventory

SNP

Supply Network Planning

SOP

Sales and Operations Planning

SQL

Structured Query Language

SRL

Stock Requirements List

SRM

Supplier Relationship Management

TCM

Traditional Chinese Medicine

TLB

Transport Load Builder

TP/VS

Transportation Planning/Vehicle Scheduling

UI

User Interface

UOM

Unit of Measure

UPC

Universal Product Code

VC

Variant Configuration

VMI

Vendor Managed Inventory

XML

Extensible Markup Language

ZBB

Zero-based Budget

PART 1

CULTURAL BACKGROUND: THE BUSINESS AND TECHNICAL CONTEXT FOR SCM

CHAPTER 1

HOW TO USE THIS BOOK: APO AS A MIND MAP

As with most SAP applications, the best path through this text is not a straight one. SAP applications in general and SAP APO in particular are simply too multidimensional to be suited to a simple, linear decomposition. Just the same, we have undertaken great pains to make SAP SCM as navigable as humanly possible. SAP APO seeks to replace some work that until recently has been strictly limited to the aegis of the human intellect—yet it ultimately does not replace people as much as it elevates their purpose by providing better computation and leveraging more strongly on the human specialties of reason, interaction, and qualitative judgment. Where SAP APO expands the scope of the system in supply planning is when it computationally takes over as much as possible of what used to be exclusively a human analytical domain; in this respect APO may be said to “map a supply planner’s mind,” yet there is no simple way to lay out a map to the human mind. The mind, like APO, is nonlinear. In finding the best way through SAP APO we should think of the supply chain models created in it as models of all the objects, relationships, and dynamics that a human master scheduler, buyer, or production planner intellectually masters in order to employ his or her craft.

Our planner, as such, is concerned with certain components of the supply chain: locations of plants, customers, vendors; products, their components, the transportation lanes between them and methods of transport; the means of production. She is likewise concerned with different end-goals in analyzing the information about these supply chains: determining the best, most current picture of demand without respect to supply (demand planning), organizing the entire supply chain to work collaboratively—even collaborating outside organizational walls with suppliers and customers—to optimally meet known demand (supply network planning), and deriving the best schedule to fully utilize the resources of a specific plant (production planning/detailed scheduling).

To grapple with the complex and multidimensional organization of a mind that thinks about the supply chain, analyzes and master plans it, a straight line simply will not do. Instead we will employ the metaphor of a cookbook and divide our treatment into three major functional parts:

1. A contextual introduction, such as introduction to the cultural background that gave rise to a particular cooking genre such as Italian or Thai—in this case an introduction of the overall SAP APO architecture and its supply chain context, as well as “tips and tricks” for improving the critical strategic judgments and decisions of project managers, executives, and project sponsors that have so much impact on APO and SCM projects’ success or failure.

2. Ingredient stocks and bases that form the core of more sophisticated entree dishes, such as beef or vegetable stock, dressings, batters, and icings—but here with SCM our basis shall be supply chain master data and transactional data elements that form the basis of any manner of supply chain model (i.e., locations, products, orders, etc.).

3.Actual complete entrée recipes, which simply make reference to bases in the second section without redundantly reprinting them, as they may occur many times over in many different recipes—in our case recipes to deliver with SCM techniques for employing planning modules to work with master data, model supply chains, and forecast or produce operational schedules.

Unlike cooking, however, SAP’s SCM product is expansive, crossing boundaries into whole additional disciplines; so in addition to these three sections we must add a fourth to address the major disciplines with a direct impact on supply chain planning:

4.The SAP BW data basis and analytical adjunct to APO and the SCM ICH application, the latter of which enables sophisticated planning collaboration with customers and suppliers.

As with a cookbook, the introduction sets the stage for the subject of the text, it explains backgrounds and starting requirements (i.e., kitchen appliances, tools, materials), and sets expectations. From there many cookbooks include a section for making common stock materials that are found as ingredients to recipes for entrees or side dishes, but which are not usually served alone, for example, vegetable stock, gravies, dough, batters, and dressings. The recipes for these stock food components are used repeatedly as parts of other recipes and there is no point in repeating them each time they are used, so they are stated independently in their own section and then referred to whenever they come up later on. The last section of the cookbook may then contain recipes to make the actual entrees, sides, deserts, and dishes that are the business of dinner, which each may or may not refer back to stock recipes as a prerequisite.

Our text closely follows this model. We begin with a basic background in supply chain management that is essential to understanding the use, applications, and power of SAP SCM. Without a solid background in the basics of supply chain management, users run the risk of repeating many of the mistakes made with legacy tools when they deploy the product, using it the same way they used much more primitive tools. One would not purchase a modern rice cooker if one meant only to steam up Uncle Ben’s from time to time. One buys the modern rice cooker because there are 6,000 years of multicultural history of rice and thousands of ways to prepare it. Don’t get stuck with ordinary, fluffy white rice—learn the basics of supply chain management so that you can deploy the full power of APO!

Second, there are two kinds of data used in APO, as in almost any business-oriented computer system: master data and transactional data. Master data is the architectural or skeletal data that forms the infrastructure of the system: things like product and location setup. Transaction data is data that is put to use describing actual events, like 100 units of plastic cups that a factory means to build on Tuesday. So much master data in APO is used in every module that there is no use in repeating the steps for setup of locations and products in both the SNP and PP/DS modules, for example. The master data section will list instructions for setting up each element of master data.

Like a cookbook, Part Three contains “recipes” for using the actual planning modules of APO to plan and manage the various aspects of the supply chain: demand planning, supply network planning, production planning and detailed scheduling, global available to promise, and transportation planning and vehicle scheduling. Wherever master data elements are called on as prerequisites by these modules, their recipe will be referenced so that readers can go to the appropriate section in Part Two for details of how to set them up.

Finally, in order to empower users, developers, and their respective organizations to employ the full power of APO, we include an additional section that explores two other, major integrated applications found within the SAP SCM platform in versions 4.1 and 5.0: SAP BW and SAP SCM ICH. The Business Information Warehouse (BW) forms both the data basis of SCM, including and especially APO, as well as provides mature, first-class reporting and analytics that are actually integrated with and manifested in Microsoft Excel. SAP SCM ICH, the Inventory Collaboration Hub, comes as a separate application in SAP SCM with APO, but empowers users of SAP R/3 to collaborate directly with external suppliers and customers—either outsourcing materials replenishment to suppliers or including them in the planning process or both. Together, BW and ICH are like height and depth to APO’s length: exponentially increasing its power to provide value-return to organizations that adopt it.

ONE BOOK, MANY CURRICULUMS: CUSTOM RECOMMENDATIONS FOR READING ORDER

As indicated earlier, this book will not make for a good straight-line read. Because of its cookbook-like organization, it will not make sense for most users to read this text from cover to cover as most users will not need or interact with all the modules of APO or all the applications of SCM; and even if they did, it still would not make sense to read Part Two in its entirety before reading Parts Three or Four, for example. Readers will need the SCM foundations established in the first section. We always recommend starting there and reading Part One in its entirety. Failure to read this first part may result in an unintentional underutilization of the full power of APO simply by way of ignorance of all the different business and information domain spaces it covers and its depth of integration.

From there, however, end-users should skip to Part Three and focus only on the module or modules they expect to use in the course of their work, referring back to chapters in Part Two whenever the planning module “recipe” of their interest instructs them to do so. Even readers who mean to absorb the entire scope of APO’s planning modules may wish to skip to Part Three, as this will lead to the most orderly and nonrepetitive coverage of Part Two. For example, if your organization has deployed DP and PP/DS, skip Part Two and read only the DP and PP/DS sections of Part Three. Wherever necessary, those sections will instruct you to go back and read master data sections in Part Two and you will have the option to read only those sections specified, and when you do so it will be in the mental context of how they will be used for the tool you are interested in.

Depending on whether one comes to APO and this text as a first-time learner or seasoned system analyst or consultant, one may go about exploring and reading this book differently. In contrast to end-users, analysts, consultants, and engineers will usually do best to work through the book from cover to cover in a nearly strict 1, 2, 3, 4 order. Executives interested in APO but involved in direct delivery may be interested only in Part One and overviews of modules in Parts Three or Four. Project managers will have a similar scope as executives but should also familiarize themselves to some degree with the use of master data and the CIF in Part Two. Seasoned developers directly involved in construction and deployment may start with Part One, skip to Part Three, and only refer to Part Two in reference. Furthermore, tool experts specializing in DP and/or BW should cover all of Part One but may wish to limit further reading to Chapter 6, on analytical master data, and Chapters 8 or 11, DP and BW. Supply chain planning specialists, however, may start with the same foundation in Part One but cover supply chain master data in Chapter 5 and SNP and PP/DS in Chapters 9 and 10. (See Exhibit 1.1.)

EXHIBIT 1.1 CURRICULUMS BY BUSINESS ROLE AND EXPERIENCE

Role-based Curriculum/Common RolesRecommended Reading OrderExecutive/Project ManagerPart I (Chs. 1–4, architecture, strategy)ExecutivesProject ManagersSection: Use of Profiles in APOChapter 11: BW and strategiesOptional—Chapter 12: ICHDemand PlanningPart I (Chs. 1–4, architecture, strategy)Demand or forecast analystSupply/demand analystChapter 5: Supply chain master dataChapter 6: Analytical master dataChapter 8: (UI section)Chapter 9: Demand PlanningChapter 11: BW and strategiesSupply Network Planning and External CollaborationNovice:Sales/operational plannerMaster schedulerBusiness analystBuyer (medium-range)Part I (Chs. 1–4, architecture, strategy)Chapter 5: Supply chain master dataChapter 8: (UI section)Chapter 9: Supply Network PlanningAdvanced:aChapter 7: Core interfaceChapter 6: Analytical master dataChapter 11: BW and strategiesChapter 12: ICH and other collaborationProduction Planning/Detailed SchedulingNovice:Production plannerProduction schedulerGround controllerBuyer (tactical/short-range)Site scheduler (i.e.; factory, warehouse, distribution center, port)Part I (Chs. 1–4, architecture, strategy)Chapter 5: Supply chain master dataChapter 8 (whole chapter): Production Planning/Detailed SchedulingAdvanced:Chapter 7: Core interfaceChapter 6: Analytical master dataChapter 11: BW and strategiesDeveloperGeneral:Business analyst/application consultantSystem analystSoftware/SC engineersOther developersPart ⇒ Part II ⇒ Part III

a Advanced users are also counseled to rely on cookbooks wherever possible, selectively dipping into textual explorations only when necessary, thereby avoiding the necessity of digesting all the verbal detail that is required to bring novices up to pace with the tool.

INCLUDED AND EXCLUDED: SCOPE OF THIS TEXT

APO and the wider SAP SCM suite of tools including BW and the Inventory Collaboration Hub that are now included in the SCM package form a truly deep and vast body of software applications—there are more than 4,300 transactions in SCM! It is simply impossible within one volume to do instructional justice to this mighty corpus of tools and it is not our intent to attempt so. In principle, this book is scoped to focus on supply chain planning and its direct support in data management, analytics, and external collaboration (Exhibit 1.2). Specifically we include detailed, modular, and step-by-step “how-to” instructions on the supply-chain planning modules of APO, that is, DP, SNP, and PP/DS. Even covering only these three parts of APO it will still not be possible to consider every setting and their effects, but we will seek to comprehensively describe the relevant planning processes of each tool and the range of options available to users. Additionally, since DP is built on the same master-data basis as is BW, a natural bonus of this text will be a miniprimer in the setup and use of the BW tool, which will be by no means comprehensive by itself but which should leave the reader with an appreciation for the business value of the tool, some skills to set it up and conduct minimal reporting, and a sound foundation for further study. Since industry interest has shifted great energies to exploiting return-on-investment opportunities available through increased supply-line efficiency via external collaboration and vendor-managed inventory, and as SAP has greatly expanded the power of SCM ICH in the 5.0 revision, we will also visit this tool and explore its business use, integration with SCM and R/3, and basic configuration.

EXHIBIT 1.2 SCM PLANNING APPLICATION/MODULE SCOPE

Much energy has been spent and oil burned hailing the vitality of solvers and optimization in the improvement of supply chain planning and execution, and we will certainly pay our dues here to those important changes in the technical landscape of commerce. Yet, though not often hailed, of minimally equal value to the improvement of supply chain management efficiency, effectiveness, and bottom-line ROI-value in commerce is the quality of two signals that traverse the supply chain: the customer-originated demand signal and the global inventory signal. The better visibility that suppliers have of changing customer demand data and the better visibility that buyers, planners, and automated planning runs have at all stages of planning—the more time-dollar-cost efficiency will be realized. Collaboration tools such as those provided in SCM and explored in Chapter 12 go to great lengths to make levels of supply chain power available off-the-shelf to small-and medium-sized organizations that were until recently the exclusive domain of such players as UPS and Wal-Mart.

While some discussion of the transactional nature of the CIF interface is essential because almost all installations of SAP APO will acquire master data from SAP R/3 using the CIF, not covered here will be any of the technical basis-level installation, configuration, or management of internal components for liveCache or the CIF, nor for that matter installation of the APO tool itself. Neither will we look at system/server network configuration or optimization.1 Do not look to this text, for example, for instruction on how to install APO and optimize a server or network platform for its use.

Also not covered are the ancillary SCM tools that have been added to the SCM 4.1 and 5.0 releases: Forecast and Replenishment or Event Management; though in the latter case of Event Management (EM), with a mind to the powerful supply chain advantage of inventory visibility across the supply chain, we nonetheless strongly recommend further investigation outside this text by the reader and any interested organization. The advanced planning techniques of APO, the inventory and demand signal quality advantage of ICH, and the power of the EM tool through its employment of radio frequency identification (RFID) in logistics tracking will together make for a potent blend of twenty-first-century supply chain excellence for SCM-adopting organizations, which have every reason to expect realization of concrete and far-reaching competitive advantages in supply chain execution that would be altogether unaffordable if technology adoption was limited to in-house technical development. Regretfully, space and experience simply do not allow for coverage of EM here.

We will not cover parallel functions of APO in the R/3 tool, such as opening customer orders, management of independent requirements, materials requirements planning (MRP), or inventory any more than they are absolutely essential to understanding their role in APO itself. Other exclusions will be the Global Available to Promise module of APO (GATP), the Transportation Planning and Vehicle Scheduling module (TP/VS), and the Deployment and Transport Load Builder (TLB) submodules. Global Available to Promise, though a powerful planning specialization that can enhance SNP and PP/DS, is nonetheless such a specialization as to be a departure from our key emphasis on planning. The structure of SCM and APO is continuous, stretching from the highest aggregate of planning in the forecasting of the DP module to the lowest level of production order management in the DS submodule, and therefore it does not allow us to dogmatically exclude supply chain execution and control from scope. Sitting at the end of the planning line, the PP/DS module ultimately converts planning to management of day-to-day physical action, and to address PP/DS as we must because of its role in planning, we necessarily address supply chain execution. That said, our intent here is to explore planning, covering other areas only where necessary, so TP/VS, Deployment, and the TLB, each of which are primarily related to supply chain execution, fall outside our scope.

One last note on what is not covered: the Mass Maintenance transaction (MASSD). Found under APO’s Master Data node in General Master Data Functions, we feel it necessary to exclude this transaction with special treatment. We usually exclude whole areas without picking on individual transactions, and with greater than 4,300 transactions in SCM to explore we have much reason to do so, but MASSD requires a little explaining for a text that targets the end-user as much as the developer: Why would we exclude a transaction whose existence is explicitly intended to ease the end-users’ experience of the tool?

We address this with a few short points: First, mass maintenance is indeed a process that may be applied during productive use of the tool and is of limited utility during development and, as the case happens to be, this text is written by a developer. As such, we come to the second point, which is that for data on experiences with this transaction we must rely on the authority of anecdotes from those in the trenches who sometimes are called upon to use it. Anecdotes, unfortunately, are unreliable teachers and should be treated with instructive authority usually only when good research and direct experience supports their suggested conclusions. While we have no research or experience to corroborate the hearsay that sometimes besmirches MASSD, there is a certain air of credibility to the reports about it, and as the consequences are so severe, we choose to err on the side of conservatism and note them here.

This brings us to the third point: the reports. We have heard from many quarters not so much that MASSD is buggy (and we do not claim here that it has any bugs) as that it is dangerous. MASSD (Mass Maintenance as the name implies) is a transaction that is applied to make mass changes across whole swaths of master data without being troubled with the necessity of individually investigating each change-case. Of course, it may be a master data manager’s job to investigate each use case when making mass changes, but we nonetheless face the inescapable fact that angelic beings are in very short supply on the labor market and master data managers are too often of the run-of-the-mill human type. It is nice to have a feature like MASSD when all one wants to do is change a setting from “P” to “S” on 500 products. Nonetheless, it seems to be too easy for some users to include products (or other objects) on their changes lists that they did not notice or intend. Alternatively, it also sometimes occurs that users will make a small, unintended change—or even a small change that was intended but not carefully thought out—but to 500 or 1,000 cases. In a production environment these changes may equate to money, usually money lost and sometimes lots of it—before changes are noticed and corrections made.

So, anecdotes: yes; direct experience or research: no; but strangely credible to the ears of those dirtied by years in the trenches of IT: You better believe it. In fact it is possible to carefully design master data interfaces and business processes to minimize if not eliminate the need for regular mass maintenance, and while we would caution against the oversensitivity of some securities professionals who would “solve” problems such as this via the oft-abused power to forbid, we must nonetheless urge developers to think carefully through data maintenance processes in such a way as to treat use of mass maintenance as an exception process rather than a regular event. As to its use: Like so many of the 4,000 transactions that we cannot cover in one text, nimble SCM/APO users such as the type we wish to create with the following instruction will find it relatively easy to master without explicit step-by-step coverage; and moreover, users should probably not even be in the transaction until they have risen to that appropriate credit of “nimble.”

Enough, then, for what we will not cover; let us consider what is included. Generally speaking this text is both inclusive of and limited to whatever facts, techniques, or methods are necessary for a business user to employ SAP APO usefully to conduct supply chain management planning on an already-deployed, already-optimized (technically) software platform while expansively applying APO’s unique integrative power to add ROI-improving dimensions of data visibility, business intelligence, and data communications that are provided through SCM integration with the R/3 (ECC), BW, and ICH products.

NOTE

1. That is, system optimization, which will not be considered. We will, of course, consider linear optimization as APO employs it in the use of developing schedules and plans, as that is one of the central objects of this text.

CHAPTER 2

SCM ARCHITECTURE