Real Optimization with SAP® APO

Josef Kallrath Thomas I. Maindl

Real Optimization with SAP® APO With 73 Figures and 30 Tables

123

Professor Dr. Josef Kallrath E-mail: [email protected]

Dr. Thomas I. Maindl E-mail: [email protected]

Trademarks “SAP” and mySAP.com are trademarks of SAP Aktiengesellschaft, Systems, Applications and Products in Data Processing, Dietmar-Hopp-Allee 16, D-69190 Walldorf, Germany. The publisher gratefully acknowledges SAP’s kind permission to use its trademark in this publication. SAP AG is not the publisher of this book and is not responsible for it under any aspect of press law. SAP®, the SAP logo, mySAPTM, SAP NetWeaverTM, SAP® R/3®, SAP® BW, SAP® CRM, SAP® GUI, mySAPTM SCM, SAP® SCM, SAP® APO, ABAPTM, ABAP/4®, BAPI®, Drag&Relate, and mySAP.com® are trademarks or registered trademarks of SAP AG in Germany and in several other countries. All other products mentioned are trademarks or registered trademarks of their respective companies. i2®, and the “i2 dot” logo are registered trademarks of i2 Technologies, Inc. ILOG®, the ILOG design, CPLEX® and all other logos and product and service names of ILOG are registered trademarks or trademarks of ILOG in France, the U.S. and/or other countries. Xpress-MPTM is a trademark of Dash Optimization. TriMatrix® is a registered trademark of MATHESIS GmbH. SCOR® is a registered trademark of the Supply-Chain Council in the United States and Europe. Microsoft®, Excel®, MSN, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other products or company names mentioned are used for identification purposes only and may be trademarks of their respective owners. Cataloging-in-Publication Data Library of Congress Control Number: 2006923242

ISBN-10 3-540-22561-7 Springer Berlin Heidelberg New York ISBN-13 978-3-540-22561-4 Springer Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilm or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag.Violations are liable for prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springeronline.com © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany The use of general descriptive names, registered names, trademarks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. Cover design: design & production GmbH Production: Helmut Petri Printing: Strauss Offsetdruck SPIN 11305699

Printed on acid-free paper – 42/3153 – 5 4 3 2 1 0

to our parents

Foreword

Optimization is a serious issue, touching many aspects of our life and activity. But it has not yet been completely absorbed in our culture. In this book the authors point out how relatively young even the word “model” is. On top of that, the concept is rather elusive. How to deal with a technology that finds applications in things as different as logistics, robotics, circuit layout, financial deals and traffic control? Although, during the last decades, we made significant progress, the broad public remained largely unaware of that. The days of John von Neumann, with his vast halls full of people frantically working mechanical calculators are long gone. Things that looked completely impossible in my youth, like solving mixed integer problems are routine by now. All that was not just achieved by ever faster and cheaper computers, but also by serious progress in mathematics. But even in a world that more and more understands that it cannot afford to waste resources, optimization remains to a large extent unknown. R It is quite logical and also fortunate that SAP
, the leading supplier of enterprise management systems has embedded an optimizer in his software. The authors have very carefully investigated the capabilities and the limits of APO. Remember that optimization is still a work in progress. We do not have the tool that does everything for everybody. Some sales people will claim to have such a miracle weapon every once in a while, out of enthusiasm so blind that it turned into ignorance. But the serious technicians among us all know that such a thing does not exist, and never will. For the creators of APO, I have the following advice. Do not get offended by the fact that the authors discovered deficiencies. In some cases you will be inspired to remove the weak points. In other cases you may decide not to address certain issues, because they are out of the league you want to play in. No matter what, the result is going to be an even better version of an already good product. Also for the users this book is a very important help. It is essential to understand the potential as well as the limits of a tool one is going to use. It

VIII

Foreword

does not matter whether you are going to do furniture building or optimization. Without good solid information about the capabilities of your tool you are more likely to break something than to make something. To those that would be disappointed by the fact that APO is not everything for everybody, I can only say in German: “Eine eierlegende Wollmilchsau bringt außer Bellen meistens nichts zustande!” January 2006

Gerard De Beuckelaer Member of the Board Director of Strategic Development UTI SN, Bucharest, Romania

Preface

R APO can be used to tackle This book describes and demonstrates how SAP
“real” optimization problems arising in industry and focuses on optimization1 based on mixed integer linear programming (MILP). In a unique combination it deals with the aspects of model-building and solving algorithms as well as with the implementation in commercial supply chain management software, SAP APO being a typical example of an advanced planning system (APS). R As many enterprises have implemented SAP
software for Enterprise Resource Planning (ERP) in a global scale successfully we feel that a logical extension of this backbone is to be seen in optimization for procurement, production and distribution. Decision makers become more and more convinced of the benefits of using optimization techniques and to formulate and implement models that address the actual problems that cannot be solved using just ERP software. This book bridges the domains of economists and business engineers who deal mostly with ERP-like solutions on the one hand and the operation research experts and mathematicians who typically deal with more or less isolated optimization applications on the other hand. The availability of APS software that is fully integrated into the ERP software and system landscapes provides a unique opportunity to utilize these two domains in the form of a tightly integrated symbiosis. Certainly there is still some work to do to convince “business people” of the huge potentials of optimization techniques and at the same time convincing the “optimization practitioners” of the potential value of APS that are based on a predefined mathematical model and allow for changing optimization model settings by changing pre-set parameters. One of the biggest challenges is to work towards better understanding each other, a seemingly obvious issue that nevertheless is very much neglected in the real world. Especially this last task is made increasingly difficult because the term optimization, as outlined on page 23 is often used in different meanings. In this book we speak of real optimization – meaning that in an 1

See Sect. 2.2 for a definition of the term optimization which has different meaning in mathematics, computers science, economy and its colloquial usage.

X

Preface

exact, mathematical sense the result derived from the input data is optimal or that strict and tight bounds are computed quantifying the maximal difference between the objective function of the current feasible solution to the optimum. Thus, from the mathematical point of view this leads to incorrect labeling of some supply chain management (SCM) and ERP systems as optimization providers where in reality just certain rules are applied to real world problems resulting in possibly feasible, but by no means optimal recommendations for solving supply chain problems. The value and consequences of obtaining optimal solutions or solutions with safe bounds are discussed in Sect. 10.2.1. We address readers involved in optimization projects in which SAP and, particularly, SAP APO are implemented in companies. These are the project designers, projects leaders, the IT personnel inside the companies, but also operations research practitioners, supply chain management consultants, and decision makers in the area of tool selection for optimization tasks. Graduates in the economic sciences, business and operations research, but also mathematicians and physicists with interest in solving real optimization problems might benefit from reading this book. We do not expect a strong background in mathematics and optimization but rather a certain openness to become familiar with the concepts and nomenclature of optimization and to acquire the skills necessary to understand the described algorithms and R models. Our book is not supposed to introduce the reader into SAP, SAP
R
TM R/3 , mySAP ERP, or SAP APO in general. The reader is advised to keep in mind that the optimization engine is just one part of SAP APO and that the software supports a wealth of other functionalities and business processes. This book rather summarizes when optimization is useful (Sect. 10.2.1), it provides a sound overview of optimization model formulation and solving as well as implementation in SAP APO and leads to interpreting the results in the right way. At the same time we demonstrate the strengths and weaknesses of the two possible approaches2 – using an integrated advanced planning3 and 2

3

The reader should keep in mind that many statements we make about SAP APO when comparing it to tailored optimization approaches hold – cum grano salis – for other commercial advanced planning systems as well. The number of case studies using SAP APO (SNP optimizer) discussed in this book is most likely not representative for the number of companies using SAP APO (SNP optimizer) successfully. Current SNP live implementations we are aware of at the time of the writing using the SNP optimizer are with clients in plastics, and in surgical and hygiene items. Current SNP project implementations (with optimizer) planned to go live in the first quarter of 2006 are with a catalyst manufacturer and an automotive supplier. Planned SNP projects to begin in the first quarter 2006 are with a windmill manufacturer (SNP optimizer) and industrial automation products manufacturer (constraint propagation-based algorithm Capable-To-Match, CTM). All these projects have been implemented or will be implemented by axentiv AG (Darmstadt). As it is very difficult to obtain publishable references on precisely SNP optimizer applications, we would

Preface

XI

scheduling system or building a customized optimization model or application – hoping to work towards building the bridge described above. In order to set the right expectations we would like to summarize what we just said and explicitly stress what this book is and what it is not: • it is a book on mathematical optimization in SAP APO for operations research practitioners, consultants, or project team members involved in SAP APO projects • it is a book on mathematical optimization in SCM • it is a book on real life issues associated with decision taking in real world problems supported by mathematical optimization in SCM • it is a book from which one can learn the relevant conceptual ideas of SCM related to planning from the mathematical point of view • it is an introduction to linear and mixed integer linear programming (LP, MILP) for non-mathematicians • it is an introduction to setting up and running the SNP optimizer in SAP APO helpful to any novice • it is a book containing selective case studies on optimization in and in connection with SAP APO; the selection criteria were mostly availability (permission to write about it in this book) and suitability (didactical issues) • it is a technical book (in the sense of mathematics) • it is a book for readers who want to establish an independent opinion based on a deeper technical understanding of the underlying mathematical assumptions enabling to select the best planning philosophy and approach for a real world optimization problem at hand • it is a book for readers in companies having selected SAP APO and who want to improve their cooperation with external consultants by an improved understanding of technical issues and foundations • it is a book for consultants who specialized on introducing SAP APO to companies and exploiting SAP APO optimization facilities to its best • it is a book encouraging the reader to think and to establish an own and independent opinion • it is a book which tries to provide clear answers and ideas to real world optimization projects involving SAP APO • it is not an SCM book • it is not a textbook on mySAPTM SCM • it is not an introduction to LP and MILP optimization techniques for mathematicians • it is not a description of processes supported by SAP APO beyond the SNP optimizer • it is not a marketing book for SAP APO or any other APS appreciate readers making references to such positive cases available to us – we would consider them in a future edition of this book.

XII

•

Preface

it is not a marketing book for Dash Optimization, ILOG, or any other provider of optimization algorithms, nor for AUDI, axentiv, Ferrari, or Mathesis

We hope it is a book the reader will enjoy reading! Structure of the Book SAP APO is introduced as a commercial supply chain management tool in Chap. 1. This chapter deals with the role of optimization in supply chain management (SCM) and introduces the concept of commercially available software products, so-called advanced planning systems (APS). In Chap. 2 we give an introduction into models, model building and optimization. We introduce the main objects of optimization: variables, constraints and objective function and give a brief sketch of optimization projects. We conclude this chapter by highlighting the basic ideas and intention of optimization in SAP APO. The Chapters 3 and 4 provide a step-by-step introduction into how an optimization model is built in SAP APO. The more general steps of building a supply chain model are explained in Chap. 3 along with an idea how a mathematical formulation might look like. Chap. 4 demonstrates how the optimizer-specific settings are made and the optimization is actually run in SAP APO. By adjusting the parameters we treat this example supply chain model as both an LP and an MILP problem. In Chap. 5 we use supply chain planning in the semiconductor industry as an example of advanced planning in high technology industries. In addition to optimization we discuss a constraint propagation approach that is very popular in this particular industry. Chap. 6 focuses on consumer goods. Chap. 7 has been contributed by Ruth Wassermann, Matthias Lautenschl¨ager, Boris Reuter, and Christian Steiner (axentiv AG, Darmstadt, Germany) and discusses a planning problem in the automotive industry and a scheduling problem occurring in the chemical industry. The detailed scheduling is part of the overall planning process including SAP R/3, the SAP APO components Demand Planning, Supply Network Planning, and Production R Planning/Detailed Scheduling, and ILOG
cartridge. Chap. 8 deals with a planning problem in the process industry: a multilocation, multi-period planning problem of a network of multi-purpose reactors used in the chemical industry to derive optimal production plans. This production planning case study focuses strongly on the MILP model and describes a typical situation in which a complete optimization solution has been implemented in industry prior to the introduction of SAP APO. The questions then arises whether it is possible to replace the system by SAP APO or to interface it as an individual model. In order to do so, we add appropriate SAP APO related comments to the mathematical model description. In addition, this case provides a good example of what is needed in terms of documentation if a model external to SAP APO is to be developed or maintained.

Preface

XIII

In Chap. 9 we find case studies in which individual optimization models have been interfaced to SAP APO. This chapter indicates alternative tracks and focuses on problems and issues to be considered when taking the approach of interfacing own optimization models to SAP APO. In two of the three cases both the SAP APO optimizer and an external solver are used to tackle different planning tasks in one SAP implementation. Section 9.2 and 9.3 have been contributed by R´emi Lequette (ILOG, Gentilly Cedex, France) and Axel Hecker (Mathesis GmbH, Mannheim, Germany), respectively. A summary of what can be learned from this book and many years of experience in SAP APO and optimization projects is given in Chap. 10. Here we also discuss which impact advanced planning and scheduling systems such as SAP APO have in larger companies and which possible consequences this has for optimization in the future. In the appendix we give an overview of the different SAP APO components followed by some of the mathematical foundations of optimization enabling the reader to develop a deeper understanding and to be able to fully exploit the benefits of mathematical optimization. Finally, we provide a glossary and a subject index for easy reference. Reading Recommendations The book has been structured in such a way that the chapters, especially Chapters 1 to 4 depend on each other while Chapters 5 to 9 are independent from each other and thus can be read in any sequence. Chap. 10 provides a summary which for some readers might be the first part to look at (there are, believe it or not, detective story readers who first want to know who was the murderer). Of course, the chapters of the book can be read in the sequence arranged in this book. But, depending on the interest of the reader, deviations from this sequence might be appropriate. As the book addresses different types of readers we suggest the following paths. These paths depend on background, interest and goal [Orientation and Real World Optimization (1); SAP APO and mathematical foundations (2), Support of own work in SAP APO projects or when producing a master or PhD thesis (3)]:

XIV

Preface

profession mathematician scientists

economist SCM

background

goal

path

no SCM no SAP

(1) 1 (A) (2) 3 4 (5) (6) (7) (8) (9) 10 (B) (2) 1 (2) A 3 4 (5) (6) (7) (8) (9) 10 (B) (3) 1 (A) (2) 3 4 (5) (6) (7) (8) (9) 10 (B)

no SAP APO

(1) 1 (A) 2 3 4 10 (B) (5) (6) (7) (8) (9) (2) 1 2 3 4 (5) (6) (7) (8) (9) 10 (A) (B) (3) (1) (2) A 3 4 (5) (6) (7) (8) (9) 10 (B)

economist SCM

(1) (1) 2 3 4 (5) (6) (7) (8) (9) 10 (A) (B) good knowledge (2) (1) (2) 3 4 (5) (6) (7) (8) (9) 10 (A) (B) in mathematics (3) (1) (2) 3 4 (5) (6) (7) (8) (9) 10 (A) (B)

economist SCM

(1) (1) 2 3 4 (5) (6) (7) (8) (9) 10 (A) B poor knowledge (2) (1) 2 3 4 (5) (6) (7) (8) (9) 10 (A) (B) in mathematics (3) (1) 2 (B) (A) 3 4 (5) (6) (7) (8) (9) 10

practitioner consultants

(1) (1) (2) 3 4 10 (5) (6) (7) (8) (9) (A) (B) good knowledge (2) 3 4 (5) (6) (7) (8) (9) 10 (1) (A) (2) (B) in mathematics (3) (1) (A) (2) 3 4 10 (5) (6) (7) (8) (9) (B)

practitioner consultants

(1) (1) 2 3 4 10 (5) (6) (7) (8) (9) (A) B poor knowledge (2) 2 3 4 (5) (6) (7) (8) (9) 10 (1) (A) B in mathematics (3) (1) (A) 2 B 3 4 10 (5) (6) (7) (8) (9)

Most chapters, especially the application Chapters 5 to 9 are written in such a way that they can be read separately in spite of the many cross-references. Hence reading this book selectively is well possible. Finally we want to mention that in most cases the book is starting off a topic in an elementary way that is easy to understand, but might increase in difficulty to a level that might not seem adequate to all readers. We choose this proceeding for being able to deal with the topics to a sufficient level of detail, address a wide variety of readers, and provide each of them some interesting aspects making this book a companion for quite some time of their work on optimization. We hope that every reader will find at least parts of the book useful and will come to the conclusion it was worthwhile to read this book. This book is partly based on lectures at the University of Heidelberg, University of Cologne, and the University of Florida (Gainesville, FL), conference papers and experience from industrial projects. We particularly stress the different approaches when tackling optimization problems with mathematical model formulation tools and with commercial advanced planning systems. By showing the strengths and limitations of both approaches we hope to give novices and practitioners in supply chain management an orientation and support decision makers when they have to decide which way to go.

Preface

XV

Acknowledgements This book would never have been published without the common interest both authors had in celestial mechanics, experiencing the inspiring atmosphere of the Vienna Observatory and the interaction with Prof. Dr. Rudolf Dvorak4 who encouraged both of us to do some more scientific work also during our industrial life. This is not to say that one could not write a book on supply chain issues without a celestial mechanics background – but it definitely helps, especially when watching M13 through the observatory’s large refractor after a few hours spending at a local wine restaurant in one of Vienna’s suburbs. Therefore, a word of thanks to Prof. Dr. Rudolf Dvorak. We would like to thank Prof. Dr. Michael Pinedo5 for providing a draft of his book. This contributed to Chap. 6. We are grateful to Ms. Melanie Seliger6 who contributed to Chap. 1, helped in defining the example model (Chap. 3), and contributed to researching results for Sect. 8.3 and Mr. Clemens M. Merk who helped with translating working manuscripts on Supply Chain Management. We thank Prof. Dr. Hartmut Stadtler7 for his interest and constructive criticism of the book manuscript. His long-year appreciation of many activities of JK, not only during the work of this book, but also other optimization activities such as the GOR working group “Praxis der mathematischen Optimierung” was always very encouraging. A special word of thanks is directed to Prof. Dr. Martin Gr¨ otschel8 for numerous discussions on supporting mathematical optimization in industry. JK thanks Prof. Dr. Robert Daniel9 for giving more detailed insight into Xpress-MPTM . We are grateful to a number of colleagues who read the manuscript critically and made many valuable suggestions, especially Dr. Ulrich Eberhard10 , Dr. Hans-Joachim Pitz11 , Steffen Rebennack12 , Dr. Anna Schreieck13 , again Prof. Dr. Hartmut Stadtler14 , and Dr. Ruth Wassermann15 . 4 5 6 7 8 9 10 11 12 13 14 15

Institut f¨ ur Astronomie, Universit¨ at Wien, T¨ urkenschanzstr. 17, A-1180 Wien, Austria NYU Stern, New York, NY, USA POM Prof. Tempelmeier GmbH, Leichlingen, Germany Universit¨ at Hamburg, Hamburg, Germany Zuse Institut Berlin, Berlin, Germany Dash Optimization, Blisworth House Blisworth, GB-Northamptonshire NN7 3BX, England BASF Aktiengesellschaft, D-67056 Ludwigshafen, Germany BASF Aktiengesellschaft, KTE/P-J630, D-67056 Ludwigshafen, Germany Universit¨ at Heidelberg, Heidelberg, Germany BASF Aktiengesellschaft, Scientific Computing (GVC/S-B009), D-67056 Ludwigshafen, Germany Universit¨ at Hamburg, Hamburg, Germany axentiv AG, Darmstadt, Germany

XVI

Preface

We appreciate the permission granted by Ruth Tellis (Palgrave/Macmillan) and John M. Wilson16 to use and reproduce some material (especially, pp. 3943, pp. 105-120, pp. 128-131) from Josef Kallrath & John M. Wilson, Business Optimisation Using Mathematical Programming, (1997, [55]), Macmillan Press Ltd., Houndsmill, Basingstoke, Hamsphire RG21 6XS, UK. We thank Dr. Werner A. M¨ uller17 , the publishing director of Springer’s Economics and Management Science section for his constructive support, the time he spent with us in several meetings, all his advise during various phases of this book project, and for being a patient editor. Thanks is also directed to Barbara Karg18 for her clear answers, instructions and help regarding various layout issues in the final production phase of this book. Overall we thank everybody in the acknowledgement list and also others providing minor comments or suggestions who preferred not to be listed for contributing to this three years project producing this book. It was an interesting project and we hope that the reader feels encouraged by the spirit of this book – the reader’s feedback will be appreciated and will likely be considered in a future edition of this book. Weisenheim am Berg, January 2006 Mannheim, January 2006

16 17 18 19 20

Josef Kallrath19 Thomas I. Maindl20

Loughborough University, Loughborough, UK Springer-Verlag GmbH, Tiergartenstrasse 17, 69121 Heidelberg, Germany Springer-Verlag GmbH, Tiergartenstrasse 17, 69121 Heidelberg, Germany Contact this author by sending an e-mail to [email protected] Contact this author by sending an e-mail to [email protected]

Contents

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX Conventions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XXV . Part I Introduction 1

2

Supply Chain Management and Advanced Planning Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Supply Chain Planning – a Brief Introduction . . . . . . . . . . . . . . . 1.1.1 The Supply-Chain Operations Reference Model . . . . . . . 1.1.2 Supply Chain Planning and Advanced Planning Systems 1.1.3 Advanced Planning Systems and Optimization . . . . . . . . 1.2 SAP APO as an Advanced Planning System . . . . . . . . . . . . . . . . 1.2.1 Components of SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Optimization in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Fundamentals of Supply Network Planning in SAP APO . . . . . 1.4 Planning Methods in SAP APO Supply Network Planning . . . . 1.4.1 SNP Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 SNP Capable-to-Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 SNP Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 4 6 8 9 9 10 12 15 15 16 18

Introduction: Models, Model Building and Optimization . . . 2.1 An Important Warning on Modeling and Optimization . . . . . . . 2.2 Mathematical Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 The Main Ingredients of Optimization Models . . . . . . . . . . . . . . . 2.3.1 Indices and Index Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 21 23 26 27 28 29

XVIII Contents

2.3.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 The Objective Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Classes of Problems in Mathematical Optimization . . . . . . . . . . 2.4.1 A Deterministic Standard MINLP Problem . . . . . . . . . . . 2.4.1.1 Comments on Solution Algorithms . . . . . . . . . . . 2.4.1.2 Optimization Versus Simulation . . . . . . . . . . . . . 2.4.2 Multi-objective Optimization . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Optimization Under Uncertainty . . . . . . . . . . . . . . . . . . . . 2.5 Implementing Models and Solving Optimization Problems . . . . 2.5.1 Implementing Optimization Models . . . . . . . . . . . . . . . . . . 2.5.2 Solving Optimization Problems . . . . . . . . . . . . . . . . . . . . . 2.6 Optimization and SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 31 32 32 33 35 35 36 38 38 39 39

3

Model Building in SAP APO Supply Network Planning . . . 3.1 The Example Supply Chain Model . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 The Supply Chain Structure . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Constraints and Costs in the Example Model . . . . . . . . . 3.1.3 A Mathematical Formulation of the Example Model . . . 3.2 Supply Chain Model Master Data . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Models and Planning Versions in SAP APO . . . . . . . . . . 3.2.2 Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Products and Location Products . . . . . . . . . . . . . . . . . . . . 3.2.4 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4.1 General Resource Data . . . . . . . . . . . . . . . . . . . . . 3.2.4.2 Resource Capacity Variants . . . . . . . . . . . . . . . . . 3.2.5 Production Process Models . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5.1 General PPM Data . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5.3 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5.4 Product Plan Assignment . . . . . . . . . . . . . . . . . . . 3.2.5.5 PPM Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5.6 PPM Data in the Example Model . . . . . . . . . . . . 3.2.6 Assembling the Parts with the Supply Chain Engineer . 3.2.7 Transportation Lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41 42 42 43 45 51 51 53 55 59 59 61 61 62 64 65 67 67 68 69 72

4

Optimization in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Recap of the Supply Chain Model . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Optimizer Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 The Optimization Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Scaling the Costs in the Master Data – the SNP Cost Profile and SNP Cost Maintenance . . . . . . . . . . . . . . . . . . 4.2.3 Working Towards Steady Results – the SNP Optimization Bound Profile . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Lot Sizes for Shipments – the SNP Lot Size Profile . . . . 4.2.5 Decomposition Methods and the SNP Priority Profile . .

79 79 80 81 86 87 88 89

Contents

XIX

4.2.6 Settings in SAP APO Customizing – the SNP Planning and Parallel Processing Profiles . . . . . . . . . . . . . 89 4.2.7 The Time Bucket Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.3 The Planning Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.1 SNP Planning Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3.2 Continuous Variant of the Model . . . . . . . . . . . . . . . . . . . . 93 4.3.3 Discrete Variant of the Model . . . . . . . . . . . . . . . . . . . . . . . 98 4.4 Some Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.4.1 A Mathematician’s View . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.4.2 The Standard Business Software View . . . . . . . . . . . . . . . 101 Part II Detailed Case-Studies 5

Planning in Semiconductor Manufacturing . . . . . . . . . . . . . . . . . 105 5.1 Semiconductor Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.1.1 The Manufacturing Process . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.1.2 Semiconductor Business Challenges . . . . . . . . . . . . . . . . . . 107 5.2 Supply Chain Business Practices . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.2.1 Semiconductor Capacity and Master Planning . . . . . . . . 109 5.2.2 Semiconductor Supply Chain Modeling . . . . . . . . . . . . . . . 110 5.2.3 Semiconductor Supply Chain Planning and SAP APO . 111 5.2.3.1 Capable-to-Match for Semiconductor . . . . . . . . . 111 5.2.3.2 Optimization for Semiconductor . . . . . . . . . . . . . 113 5.3 The Semiconductor Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.3.1 The Business Objectives and Project Scope . . . . . . . . . . . 115 5.3.2 The Supply Chain Structure . . . . . . . . . . . . . . . . . . . . . . . . 116 5.3.3 SNP Implementation in SAP APO . . . . . . . . . . . . . . . . . . 117

6

Consumer Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.1 Supply Chain Challenges Characterizing the Consumer Products Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.2 The Carlsberg Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 6.2.1 The Carlsberg Business Objectives and Project Scope . . 121 6.2.2 The Supply Chain Structure in the Carlsberg Case . . . . 121 6.2.3 SNP Optimization Implementation in SAP APO . . . . . . 123

7

Customized Optimization Solutions for the Automotive and Chemical Industries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.1 Automotive Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.1.1 The Complete Planning System . . . . . . . . . . . . . . . . . . . . . 126 7.1.2 Strategic Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 7.1.3 Mid-Range (Budget and Master Production) Planning . 128 7.1.3.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.1.3.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

XX

Contents

7.1.3.3 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 7.1.3.4 Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 7.1.3.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 7.1.4 Order-driven Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 7.1.4.1 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.1.4.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.1.4.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.4.4 Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.1.4.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7.2 Chemical Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7.2.1 The Architecture of the Complete Planning System . . . . 135 7.2.2 Production Planning and Detailed Scheduling . . . . . . . . . 136 7.2.3 Approximation Methods in SAP APO PP/DS . . . . . . . . 138 7.2.3.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.2.3.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.2.4 Cartridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.2.4.1 Cartridge Planning Scenario . . . . . . . . . . . . . . . . 139 7.2.4.2 Optimization Problem (Overview) . . . . . . . . . . . 139 7.2.4.3 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.2.4.4 Smelter/Simple Extruder Model . . . . . . . . . . . . . 140 7.2.4.5 Extruder Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.2.4.6 Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.2.4.7 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 7.3 The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 8

Operative Planning in the Process Industry . . . . . . . . . . . . . . . 143 8.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 8.2 A Tailored MILP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 8.2.1 Basic Assumptions and Limitations of the Model . . . . . . 147 8.2.2 General Framework of the Mathematical Model . . . . . . . 147 8.2.2.1 Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 8.2.2.2 Index Sets and Indicator Tables . . . . . . . . . . . . . 148 8.2.2.3 The Problem Data . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.2.2.4 Time Discretization . . . . . . . . . . . . . . . . . . . . . . . . 151 8.2.2.5 The Concept of Modes . . . . . . . . . . . . . . . . . . . . . 153 8.2.2.6 The Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 8.2.3 The Mathematical Model – the System of Constraints . . 156 8.2.3.1 Modeling the Production . . . . . . . . . . . . . . . . . . . 156 8.2.3.2 Modeling Mode-changing Reactors . . . . . . . . . . . 157 8.2.3.3 Multi-stage Production . . . . . . . . . . . . . . . . . . . . . 162 8.2.3.4 Minimum Production Requirements . . . . . . . . . . 164 8.2.3.5 Batch and Campaign Production . . . . . . . . . . . . 167 8.2.3.6 Modeling Stock Balances and Inventories . . . . . 169

Contents

XXI

8.2.3.7 Dedicated Inventories at Sites (Free Origin) . . . 169 8.2.3.8 Modeling Transport . . . . . . . . . . . . . . . . . . . . . . . . 176 8.2.3.9 Keeping Track of the Origin of Products . . . . . . 179 8.2.3.10 Including Demands and Demand Constraints . . 180 8.2.4 Defining the Objective Functions . . . . . . . . . . . . . . . . . . . . 181 8.2.4.1 Maximizing Contribution Margin . . . . . . . . . . . . 182 8.2.4.2 Maximizing Margin – Satisfying Demand . . . . . 185 8.2.4.3 Minimizing Cost While Satisfying Full Demand 185 8.2.4.4 Maximizing Total Sales . . . . . . . . . . . . . . . . . . . . . 185 8.2.4.5 Maximizing Net Profit . . . . . . . . . . . . . . . . . . . . . . 187 8.2.4.6 Multi-criteria Objectives . . . . . . . . . . . . . . . . . . . . 187 8.2.4.7 Maximizing Total Production . . . . . . . . . . . . . . . 188 8.2.4.8 Maximizing Production of Requested Products 188 8.2.5 Implementation of the Model . . . . . . . . . . . . . . . . . . . . . . . 188 8.2.5.1 Estimating the Quality of the Solution . . . . . . . 189 8.2.5.2 Comparing Solutions of Different Scenarios . . . . 190 8.2.5.3 Description of the Output . . . . . . . . . . . . . . . . . . 191 8.2.6 Real Life Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 8.2.6.1 Diagnosing Infeasibilities . . . . . . . . . . . . . . . . . . . . 193 8.2.6.2 Seemingly Implausible Results . . . . . . . . . . . . . . . 195 8.2.6.3 Relaxation of Constraints . . . . . . . . . . . . . . . . . . . 195 8.3 The SAP APO View on this Problem . . . . . . . . . . . . . . . . . . . . . . 196 8.3.1 (Non)linear Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.3.2 Objective Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 8.3.3 Demand Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 8.3.4 Detailed Comments on the Tailored MILP Model . . . . . . 199 8.3.4.1 Basic Assumptions and Limitations . . . . . . . . . . 200 8.3.4.2 General Framework of the Model . . . . . . . . . . . . 200 8.3.4.3 The Mathematical Model – the Constraints . . . 201 8.3.4.4 Description of the Outputs . . . . . . . . . . . . . . . . . . 203 8.3.4.5 Diagnosing Infeasibilities . . . . . . . . . . . . . . . . . . . . 203 8.3.5 Concluding Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 9

Case Studies – Interfacing Tailored Models to SAP APO . . 205 9.1 Developing Tailored Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.2 The ILOG Cartridge Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.2.1 ILOG Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.2.1.1 The Optimization Development Framework and Cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.2.2 The Bulk Distribution Case . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.2.2.1 Business Context . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.2.2.2 SAP APO Project . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.2.2.3 Cartridge Motivations . . . . . . . . . . . . . . . . . . . . . . 209 9.2.2.4 Solution Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.2.2.5 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

XXII

Contents

9.2.2.6 Project Information . . . . . . . . . . . . . . . . . . . . . . . . 215 9.2.3 The Load Builder Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.2.3.1 Business Context . . . . . . . . . . . . . . . . . . . . . . . . . . 216 9.2.3.2 SAP APO Project . . . . . . . . . . . . . . . . . . . . . . . . . 218 9.2.3.3 Cartridge Motivations . . . . . . . . . . . . . . . . . . . . . . 218 9.2.3.4 Solution Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 9.2.3.5 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 9.2.3.6 Project Information . . . . . . . . . . . . . . . . . . . . . . . . 222 9.2.4 The Cartridge Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 223 9.2.4.1 External Architecture . . . . . . . . . . . . . . . . . . . . . . 224 9.2.4.2 Data Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.4.3 Internal Architecture . . . . . . . . . . . . . . . . . . . . . . . 227 9.2.5 About Cartridge Projects . . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.5.1 The Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 9.2.5.2 The Inception Phase . . . . . . . . . . . . . . . . . . . . . . . 230 9.2.5.3 Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.2.5.4 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 9.2.5.5 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 9.2.5.6 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 9.3 Production and Sales Planning in the Chemical Industry . . . . . 237 9.3.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.2 Task and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 9.3.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 9.3.3.1 Data Download from SAP R/3 and SAP APO . 239 9.3.3.2 Checks on Completeness and Consistency . . . . . 240 9.3.3.3 User Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 9.3.3.4 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 9.3.3.5 Iterations and Adjustments . . . . . . . . . . . . . . . . . 241 9.3.3.6 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 9.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 9.3.4.1 The “Human Factor” . . . . . . . . . . . . . . . . . . . . . . . 243 9.3.4.2 “Plug-in” Solution Versus SNP . . . . . . . . . . . . . . 243 9.3.5 Future Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.3.5.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 9.3.5.2 Task and Objectives . . . . . . . . . . . . . . . . . . . . . . . 246 9.3.5.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Part III Concluding Considerations - The Future 10 Summary, Visions and Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 253 10.1 What Can Be Learned from this Book? . . . . . . . . . . . . . . . . . . . . 253 10.2 A Summary of Experience in Optimization Projects . . . . . . . . . 255 10.2.1 When Is Optimization Useful at All? . . . . . . . . . . . . . . . . . 255 10.2.2 Data and Optimization Model . . . . . . . . . . . . . . . . . . . . . . 261

Contents XXIII

10.2.3 Rules in Planning and Scheduling Problems . . . . . . . . . . . 262 10.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 10.2.5 Interfacing Tailored Models . . . . . . . . . . . . . . . . . . . . . . . . . 265 10.3 Further Developments in Real World Optimization . . . . . . . . . . 265 10.3.1 Simultaneous Operative and Strategic Optimization . . . 266 10.3.2 Rigorous Approaches to Scheduling . . . . . . . . . . . . . . . . . . 267 10.3.3 Planning and Scheduling Under Uncertainty . . . . . . . . . . 268 10.3.4 A Mathematician’s Dream . . . . . . . . . . . . . . . . . . . . . . . . . . 268 10.3.5 SAP APO as a Modeling Tool . . . . . . . . . . . . . . . . . . . . . . 269 10.4 The Future of Optimization with SAP APO . . . . . . . . . . . . . . . . 269

Part IV Appendix A

The Hitchhiker’s Guide to SAP APO . . . . . . . . . . . . . . . . . . . . . . 273 A.1 SAP APO Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 A.2 Hierarchical Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

B

Mathematical Foundations of Optimization . . . . . . . . . . . . . . . . 277 B.1 Linear Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 B.1.1 A Primal Simplex Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 279 B.1.2 Computing Initial Feasible LP Solutions . . . . . . . . . . . . . . 283 B.1.3 LP Problems with Upper Bounds . . . . . . . . . . . . . . . . . . . . 284 B.1.4 Dual Simplex Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 B.1.5 Interior-point Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 B.2 Mixed Integer Linear Programming . . . . . . . . . . . . . . . . . . . . . . . . 290 B.3 Multicriteria Optimization and Goal Programming . . . . . . . . . . 294

C

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

Conventions and Abbreviations

The following table contains in alphabetic order the abbreviations used in this book. Abbreviation

Meaning

APS ATP R BAPI
BOM B&B cf. CIF cu CP CTM CTP DP e.g. ERP GUI i.e. IP LP MILP MIP MIQP MINLP MPEC MRP NLP ODBC OR PDS PP/DS

Advanced Planning System Available-to-Promise Business Application Programming Interface Bill of Material Branch and Bound confer (compare) Core Interface currency unit Constraint Programming Capable-to-Match Capable-to-Promise Demand Planning exempli gratia (for example) Enterprise Resource Planning Graphical User Interface id est (that is) Integer Programming Linear Programming Mixed Integer Linear Programming Mixed Integer Programming Mixed Integer Quadratic Programming Mixed Integer Nonlinear Programming Mathematical Programming with Equilibrium Constraints Material Requirements Planning Nonlinear Programming Open DataBase Connectivity Operations Research Product Data Structure Production Planning and Detailed Scheduling

XXVI Conventions and Abbreviations PPM QP SAP APO SCM SNP s.t. w.r.t.

Production Process Model Quadratic Programming SAP Advanced Planning and Optimization Supply Chain Management Supply Network Planning subject to with respect to

Part I

Introduction

1 Supply Chain Management and Advanced Planning Systems

One of the most prominent applications of optimization in today’s business world is using advanced planning in supply chain management (SCM). In short, SCM refers to coordinating material, information and financial flows in a company’s value chain including business partners such as suppliers, contract manufacturers, distributors, and customers. In the following chapter we give a concise introduction to the SCM and supply chain planning terms and concepts sufficient for the following context of optimization applied to supply chain problems and introduction of the SAP APO software. For a more thorough treatment of SCM and advanced planning see the ample literature on this topic; Stadtler and Kilger (2004, [92]) is an excellent reference.

1.1 Supply Chain Planning – a Brief Introduction The term supply chain management was introduced by the business consultants Oliver and Webber in the early 1980’s (see Oliver and Webber, 1992, [75]) and since then a wide variety of definitions depending on individual’s point of view has been created. We will stick to our short and broad definition as it is sufficient for the purpose of this book. SCM is a business economics term and the involved tasks and processes as well as solution methodologies are classified in a business-oriented way. To someone with a mathematically oriented science background this may appear less exact and precise than desired. Therefore there is an arbitrary large potential for misunderstandings and conflict when dealing with mathematical issues such as optimization in SCM. We see it as a primary target for this book to help build a bridge between business administration and economics on the one hand and the exact sciences on the other hand. The basic advise in this context is to agree on some sort of communication quality standards ensuring that precise definitions are used and that it is checked whether all participants involved in the communication mean and understand the same when using certain terms.

4

1 Supply Chain Management and Advanced Planning Systems Plan

Plan

Deliver Return

Suppliers’ Supplier

Source

Make

Plan

Deliver

Source

Make

Deliver

Return

Return

Supplier Internal or External

Source

Make

Return

Return

Return Your Company

Deliver Return

Customer Internal or External

Source Return

Customer’s Customer

Fig. 1.1. The five management processes in the SCOR model – see Supply-Chain c Supply-Chain Council Council (2005, [94]).


In this chapter we will focus on the aspects of SCM relevant to optimization as well as on the role SAP APO as a software tool plays when it comes to mathematical optimization. For a more thorough discussion of definitions and issues in and around SCM we refer the reader to the abundant literature on this topic, for instance, Stadtler (2000, [90]). 1.1.1 The Supply-Chain Operations Reference Model As manifold as the definitions of SCM are the attempts to model processes and concepts of actually doing supply chain management in a standardized way. The Supply-Chain Council, a non-profit organization formed as an independent consortium in 1996, standardizes supply chain terminology and processes in the widely accepted and adopted Supply-Chain Operations RefR erence (SCOR
) model. The Supply-Chain Council focuses on practitioners rather than academia and comprises several hundred members, the majority of which are companies and organizations applying SCM and the SCOR principles to their business. The SCOR model aims at improving supply chain processes and structures to serve customers’ needs as well as possible. Therefore it takes into account processes and transactions from the “supplier’s supplier” to the “customer’s customer” enabling supply chain evaluations from different aspects – from within and outside the company. The model is divided into four hierarchical levels dealing with process types, process categories, process elements, and, finally, implementation. None of these four hierarchical levels touches solution methodologies such as mathematical methods or optimization techniques, however. In each level predefined best practice building blocks are available which can be used to model supply chain processes in an easily reconfigurable way. Figure 1.1 shows the SCOR model’s level one with the five elementary management processes plan, source, make, deliver, and return. In each of the process types there is potential for optimization such as in long-term capacity planning, production planning, detailed scheduling, or vehicle routing. Kallrath (2002, [51]) discusses this in more detail. The

1.1 Supply Chain Planning – a Brief Introduction

5

other levels of the SCOR model provide a deeper level of detail; level two, for instance, distinguishes between 30 process categories covering planning, executing, and enabling. One of the biggest benefits of using a standard model like SCOR is introducing a standard terminology enabling efficient communication between the parties involved in implementing a supply chain strategy. The Supply-Chain Council has created a glossary that defines more than 300 terms and metrics allowing standardized performance benchmarking of a given supply chain. Diving a bit deeper into the four processes source, make, deliver, and return we have to distinguish between planning the future events in the supply chain and dealing with current events and tasks. The earlier is widely called supply chain planning (SCP), the latter supply chain execution (SCE) or supply chain operations. Examples of SCP are strategic and tactical planning such as network design, network or master planning, production planning, transportation planning and routing, demand forecasting, and so on; examples for SCE include event tracking (for instance, in transportation), warehouse operations, transportation load consolidation, shop floor control in manufacturing execution, etc. From the nature of these tasks it is quite straightforward to see that on the one hand SCP typically is done once in a while in order to get results that remain valid between instances of executing the SCP process, and SCE on the other hand is in some sense “always online” because it has to be ready to trigger and execute certain actions in response to real-world events. Master planning as a typical SCP process, for instance, is – depending on the type of industry and particular business – done once a day, once a week or even less frequently and results in a rough-cut plan that allocates resources in the production network to certain activities that work towards fulfilling customer demands. Due to the fact that these plans typically affect multiple locations and hence involve not only communication with electronic systems, but also a certain amount of human interaction before they are actually executed, it is not feasible to execute them continually.1 Optimization as a solution technology for supply chain problems, at least on the tactical planning level, is “offline”, too. It takes a snapshot of the business data of interest, optimizes according to a well-defined model, and writes the results back to the business data repository (which usually is some sort of transactional business software system such as SAP R/3 or mySAP ERP). Often, performance, process, and problem localization requirements chase optimization away from SCE tasks: for most companies it is undesirable to re-calculate all delivery routes in the case of one delivery truck out of many dozen being involved in a traffic accident, for example. A more desirable scenario in this case would probably be to apply some local, rules-based algorithm that might suggest to extend the 1

This, of course, is an oversimplification. There are more facts to be taken into account such as machine setup times for certain production processes that make product changes expensive. A good master planning algorithm takes this into account.

6

1 Supply Chain Management and Advanced Planning Systems

Procure

longterm

Produce

Distribute

Sell

Strategic Network Planning

Master Planning Demand Planning Material Requirements Planning (MRP) shortterm

Production Planning

Scheduling

Distribution Planning

Transportation Planning

Available To Promise (ATP)

Fig. 1.2. The supply chain planning matrix (cf. Rohde et al., 2000, [79])

tour of another truck or to rent an additional vehicle serving the remaining customers from safety stock. Optimization will be successful in this area if the model is thoroughly designed to match the specific businesses, but this usually rules out commercial, preconfigured optimization applications. 1.1.2 Supply Chain Planning and Advanced Planning Systems A step towards formalizing and defining SCP in a more concise way than we just did has been taken by Rohde et al. (2000, [79]) who define the supply chain planning matrix classifying SCP tasks by planning horizon and supply chain process. In Fig. 1.2 we give a version of the SCP matrix; note the similarity of the processes along the x-axis with the SCOR process types source, make, and deliver. The vertical axis in the SCP matrix corresponds to the time horizon affected by the corresponding planning processes and also gives an idea about how frequently the planning activities are performed. Although the SCP matrix is not completely adopted in the literature and has some structural drawbacks (cf. Tempelmeier, 2001, [96]), we will use it as a tool displaying SCM functionality “at one glance” – without asking questions like “Why does MRP belong to procurement?” or “Does demand planning really belong to supply chain planning?”. With the exception of stand-alone Material Requirements Planning (MRP) we see the functional modules of the SCP matrix in software systems called advanced planning systems (APS):2 2

MRP is essentially a straightforward calculation of dated material requirements in a production process based upon manufacturing bills of material and predefined

1.1 Supply Chain Planning – a Brief Introduction

7

Strategic Network Planning plans and coordinates strategic supply chain processes creating suggestions for network design, cooperative supplier contracts, distribution structures, manufacturing programs, etc. Decisions made based upon this module are strategic and thus long-term in nature and consequently cannot be undone or changed without considerable financial impact. The underlying data of such decision processes are mostly not in the transactional business software but in archives such as data warehouses. This leads to most companies setting up strategic network planning projects using in-house or external consultants with customized mathematical software tools independently of their enterprise business software. Demand Planning takes a supporting role to the planning processes by generating forecasted demand figures that are fed into the other planning modules. Its functionality is based on statistical methods, on “collaboration” between business partners such as key customers or distributors that can help estimate future demand, and on data analysis methods such as “what-if analyses”, aggregation/disaggregation, etc. Master Planning creates feasible mid-term production plans synchronizing the material flow along the supply chain and ensuring efficient resource utilization in procurement, production, warehousing, and distribution. Usually this is a centrally executed process because its outcome affects the whole supply chain and respects interdependencies of different supply chain parts such as production facilities being able to manufacture the same product. Master planning depends on input data obtained from network design, demand planning, and cost data from all parts of the supply chain – these costs are used to decide between options in procurement, production, and transportation of goods. Depending on the complexity of the supply chain and its processes master planning is often restricted to consider bottleneck materials and/or resources or aggregated production processes. Available- and Capable-to-Promise (ATP/CTP) help in order promising. When a customer order for a specific product comes in, ATP checks quantities in stock and planned receipts (from procurement and production) across the entire supply chain to determine a delivery date for the order. Optionally, CTP can create production orders for the required product, which involves changing and adapting production plans according to incoming customer orders and available resource capacity. Production Planning and Scheduling creates detailed, short-term production plans for individual production areas (e.g., plants) based on the results from master planning. The tasks can be divided into lot sizing, resource utilization planning and detailed scheduling. Similar to master planning, the goal is a feasible plan that respects resource and material constraints, but here lead times. Therefore we see it as part of all production planning-like processes in this planning context, in particular as part of all planning algorithms in APS. From a “classical” ERP point of view, however, MRP is a stand-alone functionality and is not necessarily related to optimization or advanced planning.

8

1 Supply Chain Management and Advanced Planning Systems

we look at only one production area in all detail, i.e., without aggregating or restricting processes as in master planning. The detailed production plan is passed on to manufacturing execution / shop floor control systems and hence leaves the classical domain of APS. Distribution and Transportation Planning determines which quantities of goods are transported via which routes in the supply chain at what times. Distribution planning deals with transportation quantities and stock levels in connection with customer deliveries considering stock and transport capacities whereas transportation planning performs routing and load planning determining cost effective and timely deliveries. 1.1.3 Advanced Planning Systems and Optimization APS supplement the existing optimization programming libraries and pure optimization engines with “ready-to-use” applications covering certain SCM processes. Almost all major business software providers offer an APS as part of their application suite covering the processes described above to a larger or smaller extent. They typically divide their software into modules covering one or more of the SCP matrix elements; often enough the quality of this coverage is dependent on the industry – good functionality for production planning in the process industry does not necessarily imply that the respective APS is well-suited for discrete manufacturing such as high tech. In a complete SCM solution these modules have to work together in an integrated way which sets high standards for implementing and running those APS solutions. Often it is most beneficial to use the APS and the ERP system from the same vendor to take advantage of native system integration technologies. Optimization techniques are applicable in the areas of Strategic Network Planning, Master Planning, Production Planning and Scheduling, and Distribution and Transportation Planning. The remaining areas are typically tackled with statistics (Demand Planning), rules-based algorithms (sales order promising, ATP/CTP), or transactional and/or rules-based processing (MRP). Commercially available APS that make use of optimization usually offer comprehensive, but predefined mathematical models for one or more of these application areas. We see those commercial APS as an augmentation to the programming libraries, pure optimization engines, e.g., Xpress-MPTM and R , and respective modeling systems and languages (cf. Stadtler, 2000, CPLEX
[89]). Most APS use ILOG’s optimizer library, but the model formulation itself is kept as a company secret and only documented by stating supply chain parameters such as products, locations, customer orders, late delivery penalties, etc. that go in the model equations and the objective function. Therefore, before an actual implementation of such an APS is started a thorough investigation of the applicability of the vendor’s model is essential in order to avoid surprises upon implementation: in contrast to custom applications developed by a skilled team of IT experts and mathematicians it might prove impractical

1.2 SAP APO as an Advanced Planning System

9

to adapt the model in the required way. For a more thorough discussion of implications arising from using APS see once more Kallrath (2002, [51]).

1.2 SAP APO as an Advanced Planning System Since 1998 SAP AG, the world’s leading supplier of standard business application software, offers the advanced planning system SAP APO3 . The name SAP APO however is difficult to find in company publications and the SAP website http://www.sap.com because the APS is now marketed as part of mySAPTM SCM, one software solution offered in the mySAPTM Business Suite. R SCM, and part One SAP product enabling the mySAP SCM solution is SAP
of this product SAP SCM is the application SAP APO along with two other applications dealing with supply chain visibility, event management, and inventory collaboration. Henceforth, for an easier reference to the software the reader might have heard of or is familiar with already, we will continue to write SAP APO when we mean SAP’s APS offering. In a similar way, we will refer to the ERP offering of SAP as mySAPTM ERP. After the release SAP R/3 Enterprise 4.70 a shift was made to the mySAP ERP solution containing SAP ERP Central Component as the direct SAP R/3 successor. In the case studies later in this book we still refer to SAP R/3 if this is the product actually implemented at the time of the respective projects. 1.2.1 Components of SAP APO Figure 1.3 shows how SAP APO covers the functionality in the SCP matrix and states the respective SAP terminology. “Network Design” was available in SAP APO based on MILP up to release 3.1 and has been discontinued by SAP due to business reasons. This might have been due to the conceptual separation of an operational APS and strategic projects such as network design being based on specialized software of niche players in the market (cf. the related comment on p. 7). For this reason we decided to leave Network Design in Fig. 1.3, but we will not further elaborate on this SAP APO functionality. MRP can be seen as a rules-based mechanism of creating supply elements for demand without considering constraints such as material availability and available capacity. This is of course part of the SAP APO planning methods. MRP – as a stand-alone process – is also covered by mySAP ERP (cf. the related footnote on p. 6) and the user can choose which parts of the supply chain (which products, for instance) shall be planned in SAP APO and which shall be planned in mySAP ERP. This is because SAP APO and mySAP ERP are intrinsically integrated with the so-called Core Interface (CIF). This 3

APO stands for Advanced Planning and Optimization.

10

1 Supply Chain Management and Advanced Planning Systems

Procure

longterm

Produce

Distribute

Sell

Network Design

Supply Network Planning (SNP)

SAP APO planning algorithms SAP R/3

Production Planning

Demand Planning (DP) Deployment

Detailed Scheduling (PP/DS)

shortterm

Transportation Planning / Vehicle Scheduling

Global Available To Promise (GATP)

Fig. 1.3. SAP applications and components covering the supply chain planning matrix

– given a properly configured CIF connection – ensures real-time integration of the transaction system (mySAP ERP) and the APS (SAP APO). Planned production orders that are created by a planning process in SAP APO are immediately transferred to mySAP ERP and can be used by a subsequent MRP process to plan non-bottleneck components there, for example. 1.2.2 Optimization in SAP APO Although the supply chain community usually uses the term optimization not in its original mathematical meaning SAP APO, in some of its components, provides strict optimization algorithms in the sense of the definition given in Sect. 2.2. The following is a list of components (sometimes also called “modules”) in SAP APO using planning algorithms along with a summary of the types of the implemented algorithms (we refer to SAP APO release 4.1): • Supply Network Planning (SNP): mid-term multi-location production and distribution planning and deployment: – exact linear programming (LP) and mixed integer linear programming (MILP) algorithms – Heuristics / constraint propagation • Production Planning / Detailed Scheduling (PP/DS): short-term singlelocation production planning and scheduling (cf. http://help.sap.com/) – Heuristics / constraint propagation

1.2 SAP APO as an Advanced Planning System

•

11

– Evolutionary algorithms Transportation Planning / Vehicle Scheduling (TP/VS): routing and load consolidation (cf. Gottlieb and Eckert, 2005, [31]) – Evolutionary algorithms

This practice of providing several methods for various supply chain planning tasks is in accordance with the expectations of the business administration and economics. The techniques listed can be divided into two classes: a) heuristics being reasonable approaches finding feasible (hopefully good) solutions quickly and b) algorithms called optimization in the colloquial language of business administration and economics. In the sense of the exact mathematical sciences aiming for preciseness and optimality there is no doubt that LP and MILP are exact optimization algorithms in the sense of the definition in Sect. 2.2, constraint propagation and evolutionary algorithms are not. However, hybrid approaches – constraint propagation and evolutionary algorithms coupled with bound-generating methods – are also exact.4 As in this book we stick to real optimization in the sense of the definition given in Sect. 2.2 we do not cover constraint propagation and evolutionary algorithms, realizing that the nature of standard planning software as a means for solving a wide variety of planning problems and the desires of clients implementing and using such software requires these latter algorithms being part of the solution portfolio offering. Regarding advanced modeling requirements such as finite scheduling, sequencing and vehicle routing there is indication that the lack of real optimization in commercial APS software is due to the current impracticability of formulating standard multi-purpose scalable models (cf. Stadtler, 2003, [91]). For our further investigations this leaves primarily supply network planning (SNP) as the part of SAP APO making use of optimization in the undisputable exact mathematical sense. Therefore we restrict the focus of this book to SNP when it comes to optimization wholly within SAP APO. As it is usually the case with commercial APS, the variables and equations constituting the optimization model are predefined and not revealed by the vendor. Depending on business parameters originating from the transaction system mySAP ERP and/or SAP APO itself such as locations, products, resource capacities, late delivery penalties, etc. the actual optimization model is built by the model generator in a pre-processing step (see Fig. 1.4). The optimization engine receives this model along with transactional data (such as demand forecasts and customer orders) and solves the problem. After the 4

There is actually nothing wrong with heuristics as such as long as they are labeled and positioned as what they are: reasonable approaches finding feasible (hopefully good) solutions. From a technical point of view one could in some cases support the argument that due to the availability of only non-exact data, striving for the strict optimum may be less important. However, this claim can only be justified using technical methods appropriate for analyzing non-exact data, which leads back to providing bounds for the solution.

12

1 Supply Chain Management and Advanced Planning Systems

Fig. 1.4. Schematic SAP APO optimizer architecture

optimization run the results are translated into transactional data and are ready to be analyzed in SAP APO and – in the case of a connected system – in mySAP ERP. Additionally, for diagnostic purposes users can evaluate technical protocols of the model generator and the optimization engines. Model generation and diagnostics will be covered in Chapters 3 and 4, where we will discuss the application-specifics in more detail.

1.3 Fundamentals of Supply Network Planning in SAP APO As we have seen in Sect. 1.2, SAP APO uses real optimization in the sense of the definition given at the beginning of Sect. 2.2 primarily in Supply Network Planning. Therefore we think it is a good idea to spend two introductory sections on this SAP APO component. Supply Network Planning (SNP) is used for the compilation of supply chain-wide, realizable mid- and long-term plans for on schedule coverage of estimated requirements from demand planning as well as existing customer orders. In addition to the selection of optimal sources of supply considering purchasing, production, distribution, and transport, SNP is responsible for maintaining the required safety stock levels covering demand uncertainties. The planning process is quantity and period orientated; this involves dayexact order deadlines without consideration of detailed order sequences. As a result of SNP processes companies receive information about supply demands on external suppliers, transport requirements, planned production output as

1.3 Fundamentals of Supply Network Planning in SAP APO

13

well as stock levels at individual locations in the logistics network. Planning issues in SNP can be addressed with SAP APO Alert Monitor functions. The Alert Monitor issues more or less detailed warnings about an existing planning problem according to its configuration. SNP is based on certain SNP-relevant master data, specifically locations, products, resources, production process models (or – alternatively – product data structures), as well as transportation relations between locations.5 Different location types such as (production) plants, distribution centers, points of stock transfer, customers, etc. are available. The characteristics of these locations, like geographic location or potential restrictions are saved in the location as well as in other corresponding master data (e.g., resources that exist in locations). Suppliers can be defined as contract manufacturers. Contract manufacturing is recognized as the manufacture or assembly at a supplier (the contract manufacturer) whose components are delivered by the ordering company or a third party (contract manufacturing with third party purchase). An example are packaging processes, where the contractor receives material and wrapping from another company, performs the final packaging process and returns the packaged product to the company. Transport relations exist between the individual locations. These relations do not only include distance, specification, means of transportation, etc., but also transportation costs, which are relevant for decisions by the optimizer and CTM (see Sects. 1.4.3 and 1.4.2). The products are assigned to individual locations, in which the aggregation into different product groups for mid-term planning is possible. In SAP APO a product at a specific location is an object called location product. In the product master data SNP offers interchangeability of products. Interchangeability, available since SAP SCM release 4.0, distinguishes between the discontinuation of a product, the replacement chain, and the form-fit-function-class. All three functions are considered by the heuristics, CTM, and the optimizer. During the discontinuation of a product it is replaced in a single step by another. Products in the replacement chain on the other hand can be exchanged in various directions and various steps (e.g., product A for product B, product A for product B or C, product A for product B and later product B for product C and then again for product A, etc.). This allows to include promotions or seasonally changing products in the planning process. The form-fit-functionclass finally consists of interchangeable, completely substitutable, materials which have identical characteristics (form, fit, and function). SNP resources are either defined as bucket resources, which are SNPspecific and contain details about possible utilization hours and the available capacity, or as single-mixed and multi-mixed resources. The latter ones are used if resource utilization due to PP/DS orders is to be considered in SNP 5

Different planning methods and algorithms (such as heuristics and the optimizer) need slightly different master data attributes to be set up (cf. the discussion of supply chain models for the optimizer in Chapters 3 and 4).

14

1 Supply Chain Management and Advanced Planning Systems

planning. Mixed resources are characterized by including bucket capacity for SNP and continuous capacity for PP/DS planning.6 Minimal, normal, and maximal capacities can be defined for the mentioned types of resources in the resource master data. The single capacity load levels can be specified according to amount and rate, while violating minimal and maximal capacities can be tied to penalty costs. The last principal step in master data setup for SNP is the definition of SNP production process models (PPMs) and production process model plans (PPM plans).7 The PPM describes when a PPM plan can be used for the production of a product while the actual PPM plan includes the bills of material (BOM) and the routing. This allows for a customer order-independent description of the production process for the manufacture of one or more products. Typically, the individual operations and activities in a SNP PPM span several actual process steps on the shop floor which results from the midterm planning environment and decreases calculation time of a given plan. In the SAP APO concept master planning does not require time-resolution finer than a day. For detailed scheduling SAP APO offers PP/DS PPMs for a more detailed modeling of the production processes. Each activity in a SNP PPM is assigned a mode which defines the required resources on which the activity is performed, and the activity relationships in the PPM reflect the actual sequence of process steps in the routing. If the user is familiar with Demand Planning (DP) in SAP APO, he or she will find the basic setup of SNP comparable to that of DP regarding the planning area, the basic planning object structure, the planning book, and the assignment of key figures and characteristics in the InfoCube8 . The SNPrelevant transactional data is saved in liveCache, a memory-resident relational database optimized for fast data-access. The master data is explicitly stored in the SAP APO database.9 6

7

8

9

Rather than planning in discrete time buckets like SNP, production planning and detailed scheduling (PP/DS) plans production activities time-continuously (“exact to the second”) and therefore requires continuous capacity data in its resource master data. As of SAP APO release 4.1 an alternative way of modeling production for – essentially – all SAP APO components is provided by the production data structure (PDS). Because SAP continues to support the PPM and in order to stay compatible with earlier SAP APO releases we will restrict our discussion to the PPM. The statements we make here regarding PPMs are also valid for the PDS. An InfoCube is an instance of a multi-dimensional data model within the SAP Business Information Warehouse which is also available in SAP APO. Technically, an InfoCube consists of a number of relational tables arranged according to the star scheme: a large fact table in the center is surrounded by several dimension tables. On possible integration scenarios with mySAP ERP (SAP R/3) see for instance Dickersbach (2004, [17]), Chapters 13 and 14.

1.4 Planning Methods in SAP APO Supply Network Planning

15

1.4 Planning Methods in SAP APO Supply Network Planning Three methods are available for SNP differing in the mathematical methods used and in the consideration of material and capacity constraints. For a complete picture of the methods offered by SNP we will discuss all three methods. SAP distinguishes heuristics, optimization-based planning, and Capable-toMatch (CTM). 1.4.1 SNP Heuristics The term heuristics derives from the Greek “heuriskein” and means to find or discover and was originally used for the description of the art of invention. Heuristics are procedures for solving problems and discovering new knowledge based on a logic sequence of steps. In the field of supply chain planning they are deployed to find a sufficiently good solution in an acceptable period of time by iteratively applying correction-based planning steps. In SAP APO, the planning sequence follows the scheduling steps of the location products. Since restrictions such as resource capacities or material restrictions are neglected (infinite heuristics), it is not guaranteed that a feasible solution will be found, nor an optimal solution. After the infinite heuristics run, SAP APO can examine the capacity situation displaying information about when and where resource overloads caused by the generated plan occurs. By interactively adjusting the resource loads into the past or future capacity utilization may be adjusted (capacity levelling) for one resource at a time. Afterwards the effects of the adjustments on the load on other resources can be evaluated. In SAP APO the available heuristics are multi-level heuristics, network heuristics, and location heuristics. The source of supply determination of all three processes is based on priorities and quotas. Quotas indicate to what fraction the product requirements are supposed to be received from a source or are to be delivered to a location. In regard to the heuristic functions it is necessary to differentiate between planning processes that are executed in context with interactive planning or as background processing. For interactive planning all three options are available: location, network, and multi-level heuristics. In location heuristics, only location products from a single, predetermined location are considered in the planning process. This is a single-level process, i.e., the bill of material (BOM) explosion is not performed. In case that a section of the supply chain is supposed to be planned and components considered, multiple location heuristics runs can be executed. In network heuristics, all locations of the supply chain are considered in the planning process, but again in a single-level fashion; consequently, only planning for final products is possible. In multi-level heuristics the network is viewed as a whole and the final products are broken down according to all their respective BOM levels. Hence, planning for primary and secondary products occurs.

16

1 Supply Chain Management and Advanced Planning Systems

Background processing is done by specifically configured ABAPTM programs. Since SAP SCM release 4.0 it is possible to perform a BOM explosion by setting a check mark in the location and network heuristics, which allows planning the components of the final product at the according locations. Since the network heuristics in combination with this mark offers the same function as the multi-level heuristics in interactive planning, multilevel heuristics are not offered in background processing. 1.4.2 SNP Capable-to-Match Capable-to-Match (CTM) is a finite, multi-level, and cross-plant planning method available in SNP.10 The methodology behind it is constraint propagation. Other than an optimizer, CTM does not optimize total cost but is based on heuristics driven by priorities, e.g., regarding demand sequences and the choice between purchasing alternatives. Costs are considered for deriving priorities in relation to sourcing decisions in case there is an alternative between in-house production and procurement/transportation comparing the multi-level cost of PPMs related to production and the shipping costs related to external procurement. Supporting detailed order-based planning CTM offers a pegging method that allows the user to track orders all the way back to the original demands. Pegging is a procedure that relates supply and demand elements. The pegging structure describes the material flow between orders across all BOM levels from the finished product up to raw material supply. The quantities of demand and supply elements can deviate from each other – resulting from different lot sizes for instance. Therefore, in some cases, demands are pegged to several supply elements and the supply elements cover multiple demands. SAP APO distinguishes fixed and dynamic pegging. In the first case the pegging relationships are stored in the liveCache – the memory-resident database holding transactional data – and remain unchanged until a new planning run that re-determines fixed pegging is executed. Dynamic pegging relationships on the other hand may change whenever new supply or demand elements are written into liveCache as they are calculated on-line in the liveCache. CTM planning can deal with both pegging types. The result of a CTM planning run is always a feasible – not necessarily mathematically optimal – production plan.11 It is a sequential algorithm that works through the list of demands and tries to fulfill one after the other as 10

11

Rather than being part of SNP, CTM has an entry of its own in the SAP APO menu tree which is called Multilevel Supply & Demand Matching. Its development was initiated in the late 1990’s and constantly enhanced. Even though it was originally focused on semiconductor manufacturing, today customers in various industries use it. See Sect. 5.2.3.1 for a discussion of CTM for semiconductor. In fact CTM can – with some limitations – also be used to create PP/DS plans. Its design is general enough to use PP/DS master data and write PP/DS orders which are scheduled time-continuously.

1.4 Planning Methods in SAP APO Supply Network Planning

17

sketched in Fig. 1.5 where the prioritized demands are on the right hand side supplies

prioritized demands

Multi-level SDM algorithm: Capable-to-Match (CTM) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Material requirements planning multi-site capacity check check of transportation capabilities

11.

c SAP AG Fig. 1.5. A sketch of the CTM Algorithm, see text for explanation.


and the first one on the list is fulfilled by a series of planned production and transport orders via several production steps at different locations originating from raw material supply. This demand sequence is built based upon priorities that are set by the user/implementor based on any demand characteristic available in SAP APO such as customer, customer group, product (group), order dates, etc. Similarly to prioritizing demand, priorities are also assigned to categories of supply such as inventory, in-house production, safety stock shortfall, etc. These priorities together with quotas for different classes of supply (e.g. “use up inventory rather than procuring from location A” or “procure 40% from location B and 60% from location C ”) define CTM’s search strategy for covering the demands. The stock categorization is based on available inventory and planned supply with possible assignment of inventory categories or stock limits to the individual locations. CTM tries to cover all demands on their respective due dates. To do so it utilizes forward and backward scheduling. If on-time delivery is not possible CTM can use a combination of several strategies for dealing with delayed demand: • Minimize delays: switch from backward to forward scheduling and fulfill the demand with as little delay as possible, up to a maximum delay after which the demand is left unsatisfied. • Gradually postpone demand date: add a certain number of days to the demand’s due date and try again. This way a little “buffer” in resource availability for future demands may be created.

18

1 Supply Chain Management and Advanced Planning Systems

•

Airline strategy: skip the late demand, put it at the end of the prioritized list, and try to fulfill the other demands first. This increases the chance for subsequent demands to be satisfied on time. The opposite in CTM is the domino strategy allowing late fulfillment of the demand in question that may cause a late fulfillment of the other demands depending on the capacity situation. • Down-binning scenarios: based on certain rules, try to use higher quality product to cover demands of lower quality product. • Allow shortages, i.e., a partially satisfied demand will be considered fulfilled. As a result of CTM planning the user receives the assignment of sources and scheduling of demands as well as the appropriate secondary demands within a mid-term demand and distribution plan which also considers partial shipments. From the rules-based approach just described CTM derives its “locality”: it works one demand at a time fixing all orders originating from demands already processed until the end of the planning run. Co-production from fulfilling “earlier” demands are of course available further down in the list of demands. If the particular supply chain business problem requires a global algorithm, it is worthwhile to evaluate using the SNP optimizer. 1.4.3 SNP Optimization The optimization-based planning exploits exact mathematical optimization algorithms and facilitates the computation of mathematically optimal and feasible solutions. The SNP optimizer in SAP APO is based on linear and mixed integer linear programming (LP and MILP) using ILOG’s CPLEX as the optimization engine. LP problems can be solved with the primal simplex (see Appendix B.1.1), the dual simplex (see Appendix B.1.4), or interior point methods (see Appendix B.1). The decisions about the sources of supply for the products in question depend on the resulting costs, the cost factors considered in SAP APO are listed in Table 1.1. The basic idea of the SNP optimizer is to plan the whole supply chain with the objective of optimizing total cost. The costs are maintained in SAP APO and can be chosen so that the actual business objective (such as increasing customer service, decreasing inventory levels across the supply chain, etc.) is addressed by the optimization model. In the optimization profile the optimization objective can be set to either cost minimization or profit maximization. The difference is in the way the system interprets the non-delivery penalty costs. In the case of profit maximization this penalty is seen as the revenue of selling a particular product. Hence, the total profit is then calculated as the quantity of goods produced times the respective revenues less all costs defined to be relevant for the optimization run. The relevant costs can be fixed and/or variable costs which allows contribution margin optimization.

1.4 Planning Methods in SAP APO Supply Network Planning

19

Table 1.1. Real and penalty costs considered by the SAP APO SNP optimizer – all costs have to be maintained in SAP APO Cost Type production cost

Dimension by production process model

Comment linear or piecewise linear

production resource capacity expansion cost

by resource family

can be time-dependent

production resource capacity under-utilization penalty

by resource family

can be time-dependent

procurement cost

by material and location

linear or piecewise linear

storage cost

by material and location

storage resource capacity expansion cost

by resource family

can be time-dependent

shelf life cost

by material and location

procurement cost used for calculating penalty cost for disposing of a product with past shelf life date

safety stock deficit penalty cost

by material and location

handling resource capacity expansion cost

by resource family

can be time-dependent

transportation cost

by material and lane

linear or piecewise linear

transportation resource capacity expansion cost

by resource family

can be time-dependent

late delivery cost

by material, location, and demand type

can be time-dependent

non-delivery cost

by material, location, and demand type

after a maximum delay the non-delivery penalty is used instead of the late delivery cost; can be time-dependent

The constraints considered by the SNP optimizer can be soft, pseudo-hard, or hard. Examples for soft constraints are bottlenecks which are caused by delivery dates and that can be compensated by capacity expansions or additional shifts. Soft constraints can be “violated” by the solution resulting in penalty costs that go in the objective function. Pseudo-hard constraints are characterized by possible violations that, however, result in very large (“infinite”) penalty costs. The consequence is that the optimizer only allows violations if no other acceptable (feasible) solution can be found. Hard constraints on

20

1 Supply Chain Management and Advanced Planning Systems

the other hand do not allow violations at all. If hard restrictions cannot be complied with the plan becomes unrealizable and finding an optimal solution mathematically infeasible leading to a termination of the algorithm. The option to define conditions and restrictions as soft or pseudo-hard constraints is necessary since business goals can be at odds with each other. Since the existence of many restrictions or – to a higher extent – discrete variables can lead to high computational efforts, SAP APO offers various possibilities to reduce the storage and runtime requirements by dividing the problem into parts. Particularly in case the supply chain model results in a MILP problem solver runtimes can get very high; integer models are a consequence of discrete decisions such as modeling lot size intervals. As the implementor does not have direct access to SAP’s mathematical model formulations these methods of handling solution times are the appropriate way of influencing the behavior of the SAP APO optimizer (apart from changing master data that define the coefficients in the model equations). Especially when dealing with large MILP problems the runtime of the algorithm might be cut by decomposing the problem into smaller subproblems. SAP offers time, product, and resource decomposition. With time decomposition the original problem is split up into successive subproblems which are solved sequentially. Product decomposition creates product groups for which the total system is optimized individually. Resource decomposition is based on the analysis of the material flow and the basic decisions about production. After the analysis, subproblems are developed for the individual resources according to which the resource assignment is generated. With product and resource decomposition priority profiles can be established to determine the sequence in which the optimizer aggregates and plans product groups and resources. Another possibility for simplifying the planning problem is incremental planning where the optimization is only done for a segment of the supply chain model or on the basis of a previously developed plan. Finally, there is an option for vertical and horizontal aggregation of planning data where the optimization is dealing with aggregated data rather than with data at the high-detail level. Vertical aggregation is concerned with product demand and horizontal aggregation deals with subgroups of the supply chain network. Chapter 4 goes into some more detail on how and where to actually set these optimizer options in SAP APO.

2 Introduction: Models, Model Building and Optimization

This chapter starts with a brief overview of modeling and optimization, especially mixed integer optimization. It introduces the main objects of optimization: variables, constraints and objective function and contains a brief sketch of various types of optimization problems. For elementary introductions to linear and mixed integer linear programming we refer the reader to Kallrath and Wilson (1997, [55]) and Kallrath (2002, [51]). We conclude this chapter by highlighting the basic ideas and intention of optimization in SAP APO.

2.1 An Important Warning on Modeling and Optimization Modeling is an important concept and methodology in various disciplines. In this book we encounter on the one hand the data model in SAP and the predefined model implemented in SAP APO, and on the other hand a data model and an optimization model used in mathematical optimization. Although the terms data model and optimization sound the same in the IT world and in the mathematical world there are important differences in their meaning and interpretation. Naturally, it helps in communication to define clearly what one means when using certain terms. But in reality there is more than just the terms and definition: there is a whole world of ideas and thinking behind these harmless words. In supply chain projects bringing together SAP consultants, specialists customizing SAP APO, and mathematical model builders it is necessary to build some communication bridges before starting the project. To support this process, we first want to create some awareness of the historical and philosophical background of modeling. The terms modeling or model building are derived from the word model. Its ethymological roots are the Latin word modellus (scale, [diminutiv of modus, measure]) and what was to be in the 16th century the new word modello. Nowadays, in scientific context the term is used to refer to a simplified, abstract or well structured part of the reality one is interested in. The idea itself

22

2 Introduction: Models, Model Building and Optimization

and the associated concept is, however, much older. The classical geometry and especially Phythagoras around 600 B.C. distinguish between wheel and circle, between field and rectangle. Around 1100 D.C. a wooden model of the later Speyer cathedral was produced; the model served to build the real cathedral. Astrolabs and celestial globes have been used as models to visualize the movement of the moon, planets and stars on the celestial sphere and to compute the times of rises and settings. Until the 19th century mechanical models were understood as pictures of the reality. Following the principals of classical mechanics the key idea was to reduce all phenomena to the movement of small particles. Nowadays, in physics and other mathematical sciences one will talk about models if •

one, for reasons of simplifications, restricts oneself to certain aspects of the problem (example: if we consider the movement of the planets, in a first approximation the planets are treated as point masses), • one, for reasons of didactic presentation, develops a simplified picture for the more complicated reality (example: the planetary model is used to explain the situation inside the atoms), • one uses the properties in one area to study the situation in an analogue problem. A model is referred to as a mathematical model of a process or a problem if it contains the typical mathematical objects (variables, terms, relations). Thus, a (mathematical) model represents a real world problem in the language of mathematics using mathematical symbols, variables, equations, inequalities and other relations. It is very important when building a model to define and state precisely the purpose of the model. In science, we often encounter epistemological arguments. In engineering, a model might be used to construct some machines. In operations research and optimization, models are often used to support strategic or operative decisions. All models enable us to • learn and understand situations which do not allow easy access (very slow or fast processes, processes involving a very small or very large region); • avoid difficult, expensive or dangerous experiments; and • analyze case studies and What-If-When scenarios. The last point is probably one in which the purpose of the predefined models in SAP APO and individual tailored optimization models differ most. The models in SAP APO support operative decisions for a set situation. It is not possible to vary the situation completely and play around with all possible ideas (although SAP APO allows some scenarios to be investigated). A customized optimization model allows any numerical experiment one can think of (provided it is coded properly). Both the standard SAP APO optimization model and tailored optimization models can be used to support decisions (that is the overall purpose of

2.2 Mathematical Optimization

23

the model). But there is a clear objective describing what is a good decision. The optimization model should produce, for instance, optimal solutions in the following sense: • • •

to avoid unwanted side products as much as possible, to minimize costs, or to maximize profit, earnings before interest and taxes (EBIT), or contribution margin.

Regarding the purpose of a model we have to warn the reader or the consultants who want to use SAP APO or “own models” to be embedded to SAP APO that in real life, especially in SAP IT structures, we might face a serious problem: the different purposes behind the SAP data model and the tailored optimization model. The model, or better the customizing of the mySAP ERP or SAP APO systems has often been developed or finished before anybody thought about using SAP APO to support an operative decision problem. This may lead to difficulties because – as we stated above – the model should always be developed in such a way that one knows precisely what purpose the model should serve. And, as we see in the next section, in mathematical optimization data and concepts might be used differently than in the world outside mathematical optimization. In any case, it is necessary and very useful that the clients using the optimization components of SAP APO understand the ideas behind the predefined models in SAP APO.

2.2 Mathematical Optimization Optimization1 is a mathematical discipline analyzing and developing algorithms to solve optimization problems. In an optimization problem, one tries to minimize or maximize a quantity associated with a decision problem such as elapsed time or cost, by exploiting available degrees of freedom under a set of restrictions (constraints). Optimization problems arise in almost all branches of industry, e.g., in product and process design, production, logistics, and even strategic planning (see the list below). While the word optimization, in nontechnical or colloquial language, is often used in the sense of improving, the mathematical optimization community sticks to the original meaning of the word related to finding the best value either globally or at least in a local neighborhood. For an algorithm being considered as a (mathematical, strict or exact) optimization algorithm in the mathematical optimization community there is consensus that such an algorithm computes feasible points proven globally (or locally) optimal for linear (nonlinear2 ) optimization problems. In 1 2

Appendix B contains a deeper treatment of mathematical optimization. Note that this is a definition of a mathematical optimization algorithm and not a statement saying that computing a local optimum is sufficient for nonlinear optimization problems arising in industry.

24

2 Introduction: Models, Model Building and Optimization

the context of mixed integer linear problems (in this book we mostly consider this class) an optimization algorithm (Gr¨ otschel, 2004, [32] and Gr¨ otschel, 2005, [33]) is expected to compute a proven optimal solution or to generate feasible points and, for a maximization problem, to derive a reasonably tight, non-trivial upper bound. The quality of such bounds are quantified by the integrality gap discussed on page 291. It depends on the problem, the purpose of the model and also the accuracy of the data what one considers to be a good quality solution. A few percent, say, 2 to 3%, might be acceptable for the example discussed on page 257. However, discussion based on percentage gaps become complicated when the objective function includes penalty terms containing coefficients without a strict economic interpretation. In such cases scaling is problematic3 ; see also the example in Appendix B.2. For practical purposes it is also relevant to observe that solving mixed integer linear problems and the problem of finding appropriate bounds is often N P complete (cf. Appendix B), which makes these problems hard4 to solve. This complicates developing standard software designed to be able to cope with a wide variety of optimization problems within an acceptable and predictable range of computing time. The simplex algorithm and the Branch&Bound method described in Appendix B are examples for optimization algorithms. Evolutionary algorithms (genetic algorithms fall into this group), metaheuristics or constructive heuristics do not fall in this class unless they are coupled with a bound generating method. In this book we refer to evolutionary algorithms and metaheuristics as improvement methods. In standard business software finding the optimum of a nonlinear or hard-to-solve problem is often approached by using evolutionary algorithms/iterated search which – after a pre-set maximum calculating time – in a wide variety of cases encountered in business optimization return an acceptable solution in a vicinity of a local optimum (hopefully) close to the global optimum. As these algorithms per se do not provide a proof of optimality or bounds, they can be used in conjunction with methods generating non-trivial bounds, which helps in judging the quality of the solution. In industry, such a solution provided after a predictable computing time is what many clients expect from a standard software package not specific to their individual optimization problem. Although the supply chain community usually uses the term optimization not in its original mathematical meaning, SAP APO contains strict optimization algorithms in the sense of the definition given above in some of its components. 3

4

Goal programming as discussed in Section 2.4.2 might help in such situations to avoid penalty terms in the model. The problem is first solved with respect to the highest priority goal, then one cares about the next level goal, and so on. A consequence of this structural property is that these problems scale badly. If the problem can be solved to optimality for a given instance, this might not be so if the size is increased slightly. While tailor-made optimization algorithm such as column generation, Branch&Price techniques can often cope with this situation for individual problems, this is very difficult for standard software.

2.2 Mathematical Optimization

25

To solve a real-world problem by mathematical optimization, at first we need to represent our problem by a mathematical model, that is, a set of mathematical relationships (e.g., equalities, inequalities, logical conditions) representing an abstraction of our real-world problem. This translation is part of the model building phase (which is part of the whole modeling process), and is not trivial at all because there is nothing we could consider an exact model. Each model is an acceptable candidate as long as it fulfills its purpose and approximates the real world accurately enough. SAP APO contains already a predefined model saving us the work of developing a customized model (this holds not only for the optimizer, but also for the CP and evolutionary approaches in SAP APO). Usually, a model in mathematical optimization consists of four key objects: • •

data, also called the constants of a model, variables (continuous, semi-continuous, binary, integer), also called decision variables or parameters, • constraints (equalities, inequalities), also called restrictions, and • the objective function. The data may represent cost or demands, fixed operation conditions of a reactor, capacities of plants and so on. The variables represent the degrees of freedom, i.e., what we want to decide: How much of a certain product is to be produced, whether a depot is closed or not, or how much material will we store in the inventory for later use. Classical optimization (calculus, variational calculus, optimal control) treats those cases in which the variables represent continuous degrees of freedom, e.g., the temperature in a chemical reactor or the amount of a product to be produced. Mixed integer optimization involves variables restricted to integer values, for example counts (numbers of containers, ships), decisions (yes-no), or logical relations (if product A is produced then product B also needs to be produced). The constraints can be a wide range of mathematical relationships: algebraic, analytic, differential or integral. They may represent mass balances, quality relations, capacity limits, and so on. The objective function expresses our goal: minimize costs, maximize utilization rate, minimize waste, and so on. Mathematical models for optimization usually lead to structured problems such as:

• linear programming (LP) problems, • mixed integer linear programming (MILP) problems, • nonlinear programming (NLP) problems, and • mixed integer nonlinear programming (MINLP) problems. In addition, although not strictly belonging to the mathematical programming community, constraint programming (CP) shows increasing popularity and can be used to solve certain problems, such as scheduling problems, more

26

2 Introduction: Models, Model Building and Optimization

efficiently. CP is used in the SAP APO modules CTM and PP/DS (as of SAP APO release 4.1). Below we list some areas in which applications of (linear and nonlinear) mixed integer optimization are found. This list is by no means complete but it illustrates the wide range of possible applications (note that many have a connection to supply chain optimization): application area / problem type production planning (production, logistics, marketing) cutting stock problems (1D,2D) sequencing problems (putting activities into order) scheduling (planning activities subject to resource limits) allocation problems (resources to orders, people to tasks) distribution and logistics (supply chain optimization) blending problems (production and logistics) refinery planning and scheduling process design (chemical and food industry, refineries) engineering design (all areas of engineering) market clearing problems (energy markets) portfolio optimization (production, energy market, finance) selection and depot location problems (strategic planning) investment and de-investment problems (strategic planning) network design (planning, strategic planning) financial problems (strategic planning)

problem class MILP, MINLP MILP, MINLP MILP CP MILP, CP MILP (MI)LP, (MI)NLP NLP, MINLP MINLP NLP, MINLP LP, MILP, NLP MILP, MINLP MILP MILP MILP, MINLP MILP, MINLP

2.3 The Main Ingredients of Optimization Models Mathematical problems revolve around variables. Variables are used to model the decisions “how much”, “how many”, “what kind”, “where to”, “where from”, and so on. Variables are often thought of in algebraic terms as representing “unknown quantities”. Symbols such as x, y and z may be used to denote variables. These are commonly used in textbooks on algebra for “unknowns”. However, in our work we want to make a distinction between what is unknown and what is the direct result of a decision. Therefore, the variables or unknowns are often thought of as “decision quantities” and are also called decision variables.5 For example, if a manager of a factory has to make a decision as to how many trucks to dispatch at fixed 5 minute intervals, starting with the earliest at 08:30 a.m., then initially the planned departure time of the last truck is unknown. However, the final departure time is not a direct decision, but the total number of trucks to dispatch is. Once we know that 20 trucks are to be dispatched, the planned departure time of the last truck is known. Thus the key to identifying variables is to identify decisions. 5

In the LP community variables are also called activities or just columns.

2.3 The Main Ingredients of Optimization Models

27

Sometimes it is difficult to identify exactly which decisions exist in a problem situation. It may often be useful to pose questions such as “what does the decision maker need to know?” in order to identify what are the necessary decisions and hence the variables of the model. In this part of the process we are reemphasizing the earlier distinction made between the “client’s world” and the “modeler’s world”. The client wishes to know what decisions to make, but may wish to remain indifferent about which variables are in the model. The variables are part of the modeler’s world. 2.3.1 Indices and Index Sets Indices and index sets are very important for at least three reasons: implementation issues, conceptual aspects, and readability. The last point speaks for itself. Let us first focus on the implementation issues. If we wish to model quantities of a product made in different time periods (say, 12) and at different locations (say, 5) then it will be cumbersome to think of each variety of production at a particular location and in a particular time period as totally separate from one another. Instead we think of a generic variable, or array of variables, x, to model production and introduce indices to indicate time period and location. The indices are linked with x and are used to describe each member of a set of variables. Let t = 1, 2, .., 12 be the index for a time period, i.e., each of the time periods is numbered from 1 through to 12 and t tells us to which one we are referring. Let l = 1, 2, 3, 4, 5 be the index for location. To be more precise, t is the index and {1, 2, ..., 12} is its index set representing time buckets of 12 months, for instance. Similarly, l and {1, 2, ..., 5} accordingly. We then define xtl as the quantity to be produced in time period t at location l. Thus x4,5 will be the quantity produced in time period 4 at location 5. Sometimes the convention x(t, l) is used to avoid the need for subscripts because most computer languages do not use subscripts, but frequently the modeler uses the subscripted notation as a shorthand way of writing. Scaling up models can be handled easily when indices are used. The ranges over which the indices are allowed to vary are scaled down for prototype models and then ranges can be extended later. More than two indices can be associated with a variable, but it is often found that notation becomes very cumbersome when more than four subscripts and associated indices are used, particularly by a non-expert modeler. As an upper limit on indices is approached it may be beneficial to rethink the nature of the variables. In any model the choice of which variables to use (not simply the choice of names or characters to use to denote them) will not be unique and may depend on personal style. When integers are used as subscripts the set of index values which a particular variable can take will be referred to as its domain, e.g., {3,4,7}. However, when using index sets it is not necessary to restrict the elements of the domain

28

2 Introduction: Models, Model Building and Optimization

to integers, names of products or cities are also valid. So we could have an index set for locations which appears as l ∈ {W alldorf, P aloAlto, Shanghai}. If we define the sets T = {1, 2, ..., 12} and L = {1, 2, ..., 5} we can form equivalent expressions such as xtl xtl xtl xtl

≤5 ≤5 ≤5 ≤5

;t∈T , l∈L ; t = 1, 2, ..., 12 ; ; ∀t , ∀l . ; ∀{tl}

l = 1, 2, ..., 5

.

Note that the inequality xtl ≤ 5 holds for all index combinations. The symbol ∈ is read as “is an element of” while ∀ means “for all”. Thus t ∈ T is read as “t is an element of set T ”, and ∀l means “for all l”. If xtl ≤ 5 should hold only for certain index combinations we could write, for instance, xtl ≤ 5 xtl ≤ 5

; t = 2, 4, ..., 12 ; l = 1, 2, ..., 5 ; ∀(t, l) ∈ {(2, 1), (2, 5), (12, 5)}

.

Conceptually, index sets represent the basic objects of a model. Depending on the decision problem this can be products, sites, time buckets, transport types and other objects. Index sets provide the logical link between the mathematical optimization model and the data model. 2.3.2 Data Mathematical optimization models rely on data of consistent quality being readily available. This will not always be so. Indeed, collecting data is one of the most critical problems involved in solving large scale optimization problems. It may be overly optimistic to assume that we can obtain information on the costs of each of 17 stages of a production process. People we ask for information may not even be able to agree on a definition of cost let alone quantify aspects of it. Thus what we do will be a compromise, which may lead to a lack of user confidence in the model. What we must do is to devise the best procedures we can for data collection and see that procedures are adhered to if the model is going to be used repeatedly on data which may change over time. New data must be collected under the same terms as the old, until a major overhaul of the model is undertaken. We must then make it clear to users of the model that results were obtained under certain assumptions and stress that results should still be helpful in providing decision support provided appropriate caution is maintained. Optimization tools should allow users to vary data by making use of sensitivity, post-optimality and ranging analyses which may go a considerable way to getting around data deficiencies.

2.3 The Main Ingredients of Optimization Models

29

2.3.3 Variables Some comments on variables have been given above. Here we follow up on this by recognizing that variables can be classified according to type. In mathematical programming the usual types of variables are: •

Continuous variables, x ≥ 0

These are non-negative variables which can take any value between zero and some specified upper limit X, 0 ≤ x ≤ X, and X may take the value infinity. Note that we use lower-case characters for continuous variables. A continuous variable might for example be used to model the amount of product produced. • Integer variables, α, β, . . . ∈ {0, 1, 2, 3, 4, . . .} These are non-negative variables which can take any integer value between zero and some specified finite upper limit. Throughout the book we use lowercase Greek characters for all integer variables or other special variables. Integer variables are introduced, for instance, into the model described in Section 6.2.2 by lot size constraints on the brewing and filling steps. •

Binary or {0,1} variables.

These are a special form of integer variables which can only take on the values 0 or 1. Note that a binary variable, say δ, always obeys the weaker restriction 0 ≤ δ ≤ 1 with upper limit 1. Such a restriction is called relaxation, or to be more precise, a domain relaxation, and is a very useful concept to treat optimization problems containing integer variables. Binary variables are used to model decisions which have exactly two outcomes, e.g., to begin a project or to not begin it. In this instance we may choose to associate the value “1” with the commencement of the project and the value “0” with non-commencement. These associations are arbitrary and are decided on by the modeler. Notice that a binary variable models the logic of a decision, not necessarily an actual value which occurs in the client’s world. In many models continuous variables occur alongside binary variables, the binary variables being used to model major dichotomies in the decision making and the continuous variables modeling the consequences of these decisions. There are other types of variables listed below, but their definitions may be skipped for now by the reader, but should be returned to when required. •

Semi-continuous variables, σ

These are variables which can take the value zero or any continuous value bounded by X − and X + , i.e., x = 0 or 0 < X − ≤ x ≤ X + , where the lower limit X − is any positive number, X − > 0, and the upper limit X + may take the value infinity. These variables are used to model aspects of industrial processes where either nothing is produced or if anything is produced, it has to be above a minimal level; see Sect. 8.2.2. Semi-continuous variables are

30

2 Introduction: Models, Model Building and Optimization

also used in transport problems. Imagine a company with production sites on different continents. They can ship goods from one site to another. But if goods are shipped then the requirement is that at least, say, 50 tons, are shipped. Otherwise no transport is possible. •

Partial integer variables

Partial integer variables, also known as semi-integer variables, are variables that must be integral if they lie below some stated model-dependent value, otherwise they are considered to be continuous variables. They are a generalization of semi-continuous variables. The reason for having such variables is that once a variable is larger than some stated value any fractional part associated with it will be sufficiently small compared to the integer part of its value that it may be regarded as relatively insignificant. Thus the variable can be regarded as continuous once it is relatively large. Binary, integer, semi-continuous and partial integer variables are often referred to as discrete variables. In all work in linear programming (LP), integer linear programming (ILP) or mixed integer linear programming (MILP) variables are assumed to be non-negative unless otherwise stated. Sometimes, however, •

Free variables

are useful to represent quantities unrestricted in sign. They can take any positive, zero or negative value. They are also called unconstrained variables. In contrast to the earlier remark about variables usually being nonnegative, free variables exist to model varying quantities such as “growth”, “change” or “net profit” where the desired value of a variable could be positive or negative, or indeed zero. A free variable can be thought of as the difference between two non-negative variables, e.g., x − y, and it is possible to avoid the use of free variables in models, but this will be unnecessary within optimization software packages. It is not obligatory to use single letters to denote variables. In fact it may be useful to use mnemonic names to denote them, e.g., xship, produce1, produce2, as this can help to document the model (but one should bear in mind that it makes mathematical relations more difficult to read). However, there is a trade-off between mathematical elegance and the use of mnemonic names which might improve the understanding of a model, particularly to those people not involved in building it in the first place. 2.3.4 Constraints Constraints put explicit or implicit restrictions on the values the variables can take. In general, constraints take the form (left-hand side) “relation” (right-hand side)

2.3 The Main Ingredients of Optimization Models

31

The relation can be ≤, = or ≥ , i.e., less than or equal to, equal to, and greater than or equal to. The relations < (less than) and > (greater than) cannot be used directly used due to the structure of the algorithms but can be modeled as described in Kallrath (2002, [51], Sect. 5.3). In LP and MILP models, the left-hand side must be a linear expression in the variables of the model. Only expressions of the form 4x + 3.5y − 8.2w . . . are allowed with each variable being multiplied by a positive, negative or zero constant (coefficient)6 and the constant·variable items added together. Products or powers (e.g., xy or x5 ) of variables, or even functions of variables such as ex are not permitted in linear models. Thus typical constraints include x + y + w = 12 2x − 3y + 4.7w ≥ 5.8 x + 3y − z ≤ 5 ⇔

x + 3y ≤ 5 + z

In the last constraint it is not necessary to collect together all the non-constant terms on to the left-hand side of the constraint for input into the optimization software. In fact it is often convenient to use this style of constraint to clarify modeling, e.g., in the constraint new stock = old stock + production + purchases − sales Using binary variables it is possible to model sophisticated logical relations or piecewise linear functions, e.g., those in Sect. 8.2.4.1, as linear constraints. As shown in Kallrath (2002, [51], Sect. 5.4) it is also possible to model the absolute value function |x|, e.g., to handle expressions of the form |r1 − r2 | where r1 and r2 may refer to output rates of plants in consecutive time intervals. 2.3.5 The Objective Function In practical problems it is very important to identify and agree on a reasonable objective function. Profit maximization or cost minimization may be appropriate, but sometimes more sophisticated accountancy measures such as “earnings before interest and taxes (EBIT)” may have to be used as objective functions. A client may in fact have a number of objectives or goals in mind, each of which could lead to the formulation of an objective function. Some of these may involve maximization and some minimization and are likely to conflict, e.g., sales maximization and stock minimization may be desirable in a retailing environment but are in direct conflict. It will be best to elicit from a client some principal objectives and test how the solution to a model impinges on other objectives. Attempts at combining objectives and handling 6

Conventionally variables with zero coefficients are omitted, so not all variables are necessarily present in the expression. Also a coefficient of 1.0 is conventionally not shown next to its associated variable, i.e., 1x is written as x.

32

2 Introduction: Models, Model Building and Optimization

multi-objective problems are discussed in Sect. 2.4.2 and Appendix B.3. However, in LP or MILP models, ultimately an objective function must be a linear expression in variables and must be maximized or minimized. Two particular types of objective functions sometimes used in scheduling deserve special consideration: Minimax and Maximin. Let us assume we want to minimize the makespan of a set of jobs j ∈ J to be finished, i.e.,
 min max {tj } , (2.1) j∈J

where the non-negative variables tj represent the completion time of job j. Using the additional continuous variable, t, the LP equivalent of (2.1) is min

t ,

s.t. 0 ≤ tj ≤ t ,

j∈J

.

The objective function min t and the constraints 0 ≤ tj ≤ t ensure that t is larger than the completion time of all events, but is the minimal time value that satisfies that requirement. The Maximin objective, max {minj∈J {tj }}, which is, loosely speaking, the opposite of the Minimax objective just introduced, can be modeled as max

t ,

s.t. 0 ≤ t ≤ tj

,

j∈J

.

The Maximin objective applies, for instance, to the problem to maximize the time available before any of the jobs are completed.

2.4 Classes of Problems in Mathematical Optimization In this section we will briefly review some classes of problems often occurring in mathematical optimization and which are relevant to the supply chain aspects related to SAP APO. 2.4.1 A Deterministic Standard MINLP Problem Mixed integer nonlinear optimization problems are the most general class within algebraic optimization7 . They are specified by the augmented vecT T tor xT established by the vectors xT = (x1 , ..., xnc ) and ⊕ = x ⊕ y T y = (y1 , ..., ynd ) of nc continuous and nd discrete variables, an objective function f (x, y), ne equality constraints h(x, y) and ni inequality constraints g(x, y). The problem 
  h(x, y) = 0 h : X × U → IRne x ∈ X ⊆ IRnc min f (x, y)  (2.2) g(x, y) ≥ 0, g : X × U → IRni , y ∈ U ⊆ ZZnd 7

Algebraic optimization models may contain products and explicit functions of variables but not differential or integral relationships, or black-box functions.

2.4 Classes of Problems in Mathematical Optimization

33

is called Mixed Integer Nonlinear Programming (MINLP) problem, if at least one of the functions f (x, y), g(x, y) or h(x, y) is nonlinear. The vector inequality, g(x, y) ≥ 0, is to be read component-wise. Any vector xT ⊕ satisfying the constraints of (2.2) is called a feasible point of (2.2). Any feasible point, whose objective function value is less or equal than that of all other feasible points is called an optimal solution. From this definition it follows that the problem might not have a unique optimal solution. Let us consider the following pure integer nonlinear problem with two integer variables y1 and y2  4
  y − y2 − 15 = 0 y1 , y2 ∈ U = IN0 = {0, 1, 2, ...} 3y1 + 2y22  1 min y1 + y2 − 3 ≥ 0, y1 ,y2 One feasible point is y1 = 3 and y2 = 66. All feasible points are given by     y1 y1 = λ = , λ ∈ {2, 3, 4, ...} . y2 = λ4 − 15 y2 The optimal solution y∗ = (y1 , y2 )∗ = (2, 1) and f (y∗ ) = 8 is unique. There exists no other integer feasible point with objective function value 8. Depending on the functions f (x, y), g(x, y), and h(x, y) in (2.2) we get the following structured problems known as acronym

type of optimization

f (x, y)

Linear Programming

cT x

MILP

Mixed Integer LP

T

MINLP

Mixed Integer NLP

LP

MIQP

Mixed Integer QP

NLP

Nonlinear Programming

h(x, y) g(x, y)

c x⊕

nd

Ax − b

x

0

Ax⊕ − b

x⊕

≥1 ≥1

xT ⊕ Qx⊕

T

+ c x⊕ Ax⊕ − b

GLOBAL Gobal Optimization

x⊕

≥1 0 ≥0

with a matrix A of m rows and n columns, i.e., A ∈ M(m × n, IR), b ∈ IRm , c ∈ IRn , and n = nc + nd . Real-world problems lead much more frequently to LP and MILP than to NLP or MINLP problems. QP refers to quadratic programming problems. They have a quadratic objective function but only linear constraints. QP and MIQP problems often occur in applications of the financial service industries. 2.4.1.1 Comments on Solution Algorithms Since some problems occur as subproblems of others for obtaining a good performance it is very important that the algorithms to solve the subproblems are well understood and exploited efficiently. While LP problems as described in Appendix B.1 can be solved relatively easily (the number of iterations,

34

2 Introduction: Models, Model Building and Optimization

and thus the effort to solve LP problems with m constraints grows approximately linearly in m), the computational complexity of MILP and MINLP grows exponentially with nd but depends strongly on the structure of the problem. Numerical methods to solve NLP problems work iteratively and the computational problems are related to questions of convergence, getting stuck in “bad” local optima and availability of good initial solutions. Global optimization techniques can be applied to both NLP and MINLP problems and its complexity increases exponentially in the number of all variables entering nonlinearly into the model. It is understandable that the current release of SAP APO does not consider NLP or MINLP models. SAP APO offers several solution approaches to planning and scheduling problems, among them MILP but also constraint programming (CP) and evolutionary algorithms. Thus, those active in problem solving need to know a great deal about good modeling practice and how to connect models and algorithms. For that reason, we strongly recommend that practitioners and consultants obtain a deep understanding of the algorithms involved in SAP APO and consult the technical documentation. The following table contains a series of books which we consider as valuable regarding the background of algorithms or in the context of solving real-world optimization problems: LP problems MILP problems NLP problems

Padberg (1996, [76]) Nemhauser and Wolsey (1988, [73]), Wolsey (1998, [101]) Murtagh and Saunders (1978, [72]), Gill et al. (1981, [29]), Spelluci (1993, [88]) MINLP problems Gupta and Ravindran (1985, [35]), Geoffrion (1972, [28]) Duran and Grossmann (1986, [21]), Floudas (1995, [22] Viswanathan and Grossmann (1990, [98]) global optimization Floudas (2000, [23]), Horst et al. (1996, [38]), Kearfott (1996, [58]), Horst and Pardalos (1995, [37]), Tawarmalani and Sahinidis (2002, [95]) real-world problems Williams (1993, [100]), Kallrath and Wilson (1997, [55]), Ciriani et al. (1999, [12]), Kallrath (2002, [51])

Besides the exact mathematical programming algorithms in this table, there also exists constraint programming often used for solving scheduling problems, and heuristic methods, better called metaheuristics, which can find feasible points of optimization problems, but can only prove optimality or evaluate the quality of these feasible points when used in combination with deterministic approaches. Such methods include Simulated Annealing, Tabu Search (see Glover and M. Laguna, 1997, [30]), Genetic Algorithms, Evolution Strategies, Ant Colony Optimization, and Neural Networks. These methods are not optimization methods in the strict sense as they cannot prove optimality or generate safe bounds. However, for very hard problems, they can be used to find feasible points of optimization problems. Section 10.2.1 discusses when exact algorithms are useful.

2.4 Classes of Problems in Mathematical Optimization

35

2.4.1.2 Optimization Versus Simulation As the metaheuristics mentioned in the previous section are based on simulation, we add some comments on the relationship between simulation and mathematical optimization. In contrast to simulation (parameter values are fixed by the user, feasibility has to be checked separately, no proof on optimality), mathematical optimization methods compute directly an optimal solution and guarantee that the solution satisfies all constraints. While in optimization feasible solutions are specified a priori and implicitly by the constraints, in simulation somebody has to ensure that only those combinations of parameter values are evaluated or considered which represent “appropriate scenarios”. There is another fundamental difference. Mathematical optimization deals with declarative representations of problems while model formulations using simulation approaches appear much more procedural. Optimization problems cannot be solved by simulation (also called parameter studies), i.e., by evaluating the objective function and comparing the results of various scenarios. Nevertheless, since experts of simulation techniques have developed intuition and heuristics to select appropriate scenarios to be evaluated, and simulation software exists to perform their evaluation, simulating a real world problem creates understanding and knowledge. But there is no guarantee that the optimal solution or even a solution close to the optimum will be found. This is especially troublesome for complex problems, or those which require decisions of large financial impact as the decision problem discussed in Sect. 10.2.1. 2.4.2 Multi-objective Optimization Multi-objective optimization, also called multi-criteria optimization or vector minimization problems, involves several objective functions. A simple approach to solve such problems is to express all objectives in terms of a common measure of goodness leading to the problem how to compare different objectives on a common scale. Basically, one can distinguish two cases. Either the search is for Pareto optimal solutions, or the problem has to be solved for every objective function separately. When minimizing several objective functions simultaneously the concept of Pareto optimal solutions turns out to be useful. A solution is said to be Pareto optimal if no other solution exists that is at least as good according to every objective, and is strictly better according to at least one objective. When searching for Pareto optimal solutions, the task might be to find one, find all, or cover the extremal set. A special solution approach to multiple objective problems is to require that all the objectives should come close to some targets, measured each in its own scale. The targets we set for the objectives are called goals. Our overall objective can then be regarded as to minimize the overall deviation of our goals from their target levels. The solutions derived are Pareto optimal.

36

2 Introduction: Models, Model Building and Optimization

Goal programming can be considered as an extension of standard optimization problems in which targets are specified for a set of constraints. There are two basic approaches for goal programming: the preemptive (lexicographic) approach and the Archimedian approach. In preemptive goal programming, goals are ordered according to importance and priorities. It is recommended if there is a ranking between incommensurate objectives available. The goal at priority level i is considered to be infinitely8 more important than the goal at the next lower level, i + 1, but they are relaxed by a certain absolute or relative amount when optimizing for the level i + 1. In a reactor design problem we might have the ranking: reactor size (i = 1), safety issues (i = 2), and eventually production output rate (i = 3). In the Archimedian approach weights or penalties are applied for not achieving targets. A linear combination of the violated targets weighted by some penalty factor is added, or establishes the objective function. Goal programming offers an alternative approach but should not be regarded as without defects. The specific goal levels selected greatly determine the answer. Therefore, care is need when selecting the targets. It is also important in which units the targets are measured. Detailed treatment of goal programming appears in such books as Ignizio (1976, [42]) and Romero (1991, [80]) who introduce many variations on the basic idea, as well as in Schniederjans (1995, [85]). The reader is also referred to Appendix B.3 for more details and some examples. 2.4.3 Optimization Under Uncertainty In most applications cases and in many software packages input data are assumed to be exact and deterministic; SAP APO is no exception. This assumptions leads to deterministic models. If the input data are subject to uncertainty we are lead to optimization under uncertainty, i.e., optimization problems in which at least some of the input data are seen as random data, or in which even some constraints hold only with a given probability. Those uncertainties can arise for many reasons: • • •

8

Physical or technical parameters only known to a certain degree of accuracy. Usually, for such input parameters safe intervals can be specified. Process uncertainties, e.g., stochastic fluctuations in a feed stream to a reactor, or processing times subject to uncertainties. Demand uncertainties occur in many situations: supply chain planning (cf. Gupta and Maranas, 2003, [34]), investment planning (cf. Chakraborty et al., 2004, [9]), or strategic design optimization problems (cf. Kallrath, 2002, [50]) involving uncertain demand and price over a long planning horizon of 10 to 20 years. It would also be possible to define weights which express how much the ith objective is more important than the (i + 1)th objective.

2.4 Classes of Problems in Mathematical Optimization

37

Optimization under uncertainty applied to real world problems, is still facing conceptual problems such as identifying the stochastic nature of process entering the optimization model, or interpreting the results properly. Thus, is not a surprise that it took until now that the number of applications using, for instance, stochastic programming is strongly increasing. A detailed review on optimization under uncertainty is provided by Kallrath (2005, [54]). Here we provide just a light version of the main points found in this review. The first step to model real world problems involving uncertain input data is to analyze carefully the nature of the uncertainty. Zimmermann (2000, [104]) gives a good overview of what one has to take into consideration. It is very crucial that the assumptions are checked which are the basis of the various solution approaches. Below we list and comment on some techniques which have been used in real world projects or which one might think of to use. • Sensitivity analysis is conceptually a difficult problem in the context of MIP, and is, from a mathematical point of view, not a serious approach to solve optimization problems under uncertainty (Wallace, 2000, [99]). However, this approach can be successfully applied to an optimization model embedded into a Monte Carlo simulation to establish how strong the objective function values depend on fluctuation of some input data. If the problem can be solved to quickly optimality one could proceed as follow. The problem is solved for a set of input data generated randomly around nominal values. The distribution of a few thousand input values is mapped to a distribution of objective function values. • Stochastic Programming, in particular multi-stage stochastic models, also called recourse models, have been used for a long time (cf. Dantzig, 1955, [14], Kall, 1976, [48], or Birge, 1997, [7]). In stochastic programming, the models contain the information on the probability information of the stochastic uncertainty and the distribution does not depend on the decision in most cases. While stochastic MILP is an active field of research (cf. the surveys of Klein-Haneveld and van der Vlerk, 1999, [59] or Sen and Higle, 1999, [87], and, more recently, in the Handbook of Stochastic Programming, Ruszczy´ nski and Shapiro, 2003, [82], Schultz, 2003, [86], or Andrade et al., 2005, [3]) industrial strength software has yet to enter the stage. • Chance constrained programming deals with probabilistically constrained programming problems and dates back to Charnes and Cooper (1959, [10]). A more recent overview on general chance-constrained methods is given by Pr´ekopa (1995, [78]). • Fuzzy set modeling supporting uncertainties which fall into the class of vague information and which are expressible as linguistic expressions – fuzzy set theory in the context of LP problems has been used, for instance, by Zimmermann (1987, [103]; 1991, [102]) and Rommelfanger (1993, [81]). • Robust optimization (see, for instance, Ben-Tal et al., 2000, [5]) is a relatively new approach to deal with optimization under uncertainty in case that the uncertainty does not have a stochastic background and/or that in-

38

2 Introduction: Models, Model Building and Optimization

formation on the underlying distribution is not or hardly available (which is, unfortunately, often the case in real world optimization problems). • Decisions based on Markov processes (cf. Meyn, 2002, [69]) and/or the control of time-discrete stochastic processes allow for decision-dependent probability distributions but typically require stronger assumptions on the stochasticity. Cheng et al. (2003, [11]) give an excellent illustration of such techniques applied to design and planning under uncertainty. Despite the conceptual difficulties, it is strongly recommended that if some data, e.g., demand forecasts in planning models, or production data in scheduling are subject to uncertainties, one should consider whether the assumption that planning and modeling is exclusively based on deterministic data can be discarded and uncertainty can be modeled. If probability distributions for the uncertain input data can be provided, stochastic programming or chance constrained programming is the means of choice.

2.5 Implementing Models and Solving Optimization Problems 2.5.1 Implementing Optimization Models In the model building phase, real-world optimization problems are structured according to their basic objects, variables, objective function and constraints discussed in Sect. 2.3. There are several approaches to put such a model into the computer: •

•

Programming or computer science approaches use a programming language such as FORTRAN, C, or C++ to combine the model and the data and either produce a matrix or other input file for a commercial solver, or even include the solution algorithms in one program. In standard business software this approach is quite common because there is minimal to no need of changing the model in a client-specific way and keeping the model, the business logic, and – probably – the solver together in one development environment reduces development complexity. Another advantage is keeping together application design and optimization development in one tool resulting in seamless applications. Disadvantages are the difficulty to understand and to be read by others, the difficulty to maintain the code, and the dependence on operating systems and compilers, to mention a few. In table or spreadsheet approaches the mathematical structure is extracted from table templates to be filled with data. In the past this approach was often found in software packages used in the process industry and especially refineries. The models were usually confined to linear problems or nonlinear ones with a very special structure. Those approaches are usually subject to data management problems, they are restricted to two dimensions, and scale-up can be a tedious work.

2.6 Optimization and SAP APO

•

39

Algebraic modeling languages (cf. Kallrath, 2004, [53]) are by far the best approach if the primary focus is on the optimization model problem. They allow the modeler to implement optimization problems close to their mathematical formulation, they are flexible and open to fast reformulations. Most of them have been developed by individuals in mathematical optimization. One might see as a possible disadvantage that besides a programming language such as C++ another language is required.

Based on what has been outlined we can summarize: in the optimizer SAP APO contains a predefined model coded in the programming languages ABAP and C/C++. The detailed mathematical model formulation is not revealed by SAP, which is understandable from the commercial and intellectual property points of view, but it may create a disadvantage because it makes the interpretation of the results very difficult. In addition, such concepts as reduced costs or shadow prices depend on knowing the structure of the model. 2.5.2 Solving Optimization Problems Once the model has been coded we need a solver, i.e., a piece of software which has an algorithm implemented capable of solving the problem listed above. SAP APO uses ILOG’s CPLEX as the solver for LP and MILP problems. In the ideal case, the optimal solution is returned. In reality, when trying to solve real-world problems, we often experience that a problem is returned with the statement “problem is infeasible”. Thus, as discussed in Sect. 8.2.6.1 a modeling system should also support the identification of infeasibilities. It helps also to use a data consistency checker which reports hard infeasibilities or conflicting data. Nowadays optimization problems can also be solved directly via the internet, cf. Lee and Maindl (1998, [65]), Fourer and Goux (2001, [26]), Dolan et al. (2002, [18]), or Dolan and Munson (2002, [19]). This eliminates the need to have a solver installed locally.

2.6 Optimization and SAP APO As has already been outlined in Sect. 1.2.2 SAP APO contains an optimization model and solution approach in the strict sense of mathematical optimization. This applies to SNP optimizer using the MILP solver CPLEX, which together with Xpress-MP, is considered the best worldwide. Due to the nature of SAP APO as a standard business software tool its mathematical optimization model is predefined and designed to meet the requirements of as many industries as possible. It has been pointed out that the SNP model formulation is not open and thus is not easy to qualify the solution. In other modules (e.g., CTM or finite scheduling in PP/DS) SAP uses constraint programming and evolutionary algorithms which are both not considered as mathematical optimization approaches without an in-depth analysis of the provided bounds for the solution. Although for scheduling in the

40

2 Introduction: Models, Model Building and Optimization

process industry there are more advanced solution approaches available (see Sect. 10.3.2) one has to take into account that SAP want to offer a scalable approach working reasonably well in many application areas and industries. Despite the availability of advanced modeling systems and modeling languages (cf. Kallrath, 2004, [53]), SAP APO as well as other APS providers have coded their models in C or C++. May be taste has been triggered this decision, may be speed was a major issue when the decision had been made between choosing a modeling language or system compared to programming languages. With improved technology and hardware this has become less of an issue and now, some of the modeling systems have been drastically improved for speed and are very fast. The reason for preferring C or C++ may also lie in the fact that in software companies such as SAP or i2 Technologies far more people are found with a computer science background than a mathematical programming background. In the latter community modeling languages are more frequently used supporting the concept of strictly separating the data, model, and solution methods. As long as SAP APO keeps the model and its formulation confidential, it is of less importance to the client whether the model has been coded in C or C++, or in a modeling language. However, if SAP APO would become open in the sense that the user can access the variables and constraints, a modeling language would definitely be the better choice. A modeling language would also make it easier to modify and extend the predefined model. When discussing SAP APO (SNP) and comparing its optimization model to customized models one has to appreciate and count positively for SAP that the developers managed to build a model which has reasonable scaling properties and that this very model serves clients in completely different application areas and industries. Scaling properties means that the model and the associated solver technology usually works for small problems as well as large problems. Serving different application areas means to comprise requirements from different areas. A customized model does not need to pay attention to these aspects because it is developed from scratch once for one purpose only. Therefore, it is understandable that in case a client wishes some model enhancement of SAP APO great care and effort is required when SAP’s technical and mathematical personnel is to modify and extend the model. If the models and solution approaches embedded in SAP APO are used as they are, the user does not necessarily need to know about the variables, indices etc. discussed in Sect. 2.3. The software produces the answer for a user not familiar with mathematics. However, to interpret the answer it would strongly help to understand the mathematics and, especially, the constraints. The more complexity is involved in a real world planning process the more crucial it becomes to have personnel involved who can understand and appreciate this complexity and are not intimidated by it. In order to give a more exhaustive picture of the way optimization is used in commercial business software, in the following two chapters we will have a closer look at how “modeling” is done in SAP APO SNP.

3 Model Building in SAP APO Supply Network Planning

Starting point of supply chain optimization in SAP APO is a supply chain model. Within this model so-called master data defines the detailed structure such as the number and types of locations and products. Transportation lanes define possible goods movements between locations, the respective durations, costs, etc. Setting up a supply chain model as described in this chapter largely refers to SNP in general no matter whether the optimizer, constraint propagation as in Capable-to-Match, or heuristics are used as the solving algorithm. But there are still some differences in what exact data elements are used by the different algorithms so that the user has to be carefully following the documentation or – and this is still the best method after years of SAP APO availability in the market – try out different settings. This part of the book is kept rather brief in order to focus on optimization rather than master data setup issues. We refer to the literature such as Dickersbach (2004, [17]) and Bartsch and Bickenbach (2002, [4]) for more thorough explanations regarding the SAP APO master data concept. The intention of this chapter is to serve as a recipe on how to quickly set up an SNP supply chain model that can be used for optimization. Chap. 4 continues the cookbook by using the results from this chapter for an actual optimization run preceded by a discussion of the various profiles that influence the structure of the (MI)LP itself. Readers familiar with setting up a supply chain model in SAP APO and not intending to reproduce our example in their system right away may postpone reading this chapter and skip forward to Chap. 4. We use a very simple example supply chain model and show how to formulate it in SAP APO step by step. We do not claim to include all aspects and facets of SAP APO setup and certainly do not intend to deliver an alternative to the SAP APO application documentation. Having said that, anyone with R some basic familiarity with the SAP user interface SAP
GUI should be able to implement our little example. SAP is the only business software provider known to the authors that makes its entire product documentation freely available on the internet. In-

42

3 Model Building in SAP APO Supply Network Planning

cluding all industry-specific information the SAP documentation is more extensive than the Encyclopedia Britannica. The SAP APO section can be found at http://help.sap.com/ in the section Documentation → mySAP Business Suite → SAP Supply Chain Management. We expressly encourage the interested reader to refer to this documentation. As the actual model equations defining the LP and MILP models in SAP APO are intellectual property of SAP they are among the best-kept company secrets. Therefore we cannot state our little example model in its mathematical notation and leave it up to the reader to formulate the model that way.

3.1 The Example Supply Chain Model In our example we look at a single-stage production problem with external sourcing partners. As simple as it might look, the problem is a good starting point for experimenting with the SAP APO optimizer and still provides quick results. The objective function of the (MI)LP model is designed to reduce inventory, optimize production quantities, and optimize procurement of components while maximizing the customer service level. Technically, the objective is to create a least cost production plan considering the demands, the constraints, and the costs for: • • • • • •

production production capacity expansion (e.g., introducing another shift) procurement / sourcing storage late delivery (penalty costs) non-delivery (penalty costs)

First we treat the model as an LP (Sect. 4.3.2) and in the second step introduce production lot size restrictions which requires a discrete formulation (Sect. 4.3.3). 3.1.1 The Supply Chain Structure Let us assume a company selling three main products, P1, P2, and P3. P1 is the high-grade and expensive product, P2 and P3 are mid-grade and lowgrade products, respectively. The company has three customer regions with homogenous properties so that we can model them as three customers C1, C2, and C3 in the system (one might think of DCs, retailers, or large industrial key customers). All three products are made in the factory F1 which has one production line represented by resource R1. As producing any of the products consumes a certain amount of capacity on the production resource R1 all three products compete for available R1 capacity. Figure 3.1 shows the structure of this example supply chain we want to implement in SAP APO demonstrating the SNP optimizer setup. As we do

3.1 The Example Supply Chain Model

43

C1 S1 X1

X2

F1

R1

C2 P1

P2

P3

S2 X1

C3

Fig. 3.1. The structure of the simple supply chain example

not model returns, the material flow is from left to right along the arrows representing the permissible goods movements, modeled as transportation lanes as we will see a bit later. The customers C1, C2, and C3 can order any of the products P1, P2, and P3. We do not model static sourcing assignments for component X1, but let the optimizer decide whether to source it from S1 or S2. Figure 3.2 shows the locations and possible transportation relationships on a map as the Supply Chain Engineer in SAP APO displays it. 3.1.2 Constraints and Costs in the Example Model In order to make the products two key components X1 and X2 are required and planned with SNP. The prime supplier of the company is S1 who can deliver both components, but has limited availability of X1. As a backup the company uses a second supplier, S2, for component X1 who charges a higher price for it (cf. Table 3.1). In the model limited supply of X1 from supplier S1 is represented as a constraint limiting the transportation quantity of raw material X1 from S2 to the factory F1 as we will see shortly. Incoming customer demand and/or demand forecasts drive the planning process. As mentioned earlier, the goal is to minimize total cost which is given as the sum of production cost, procurement cost, storage cost, and the penalties for delayed delivery or lost customer orders (no delivery). Whenever a customer cannot be serviced within a time of 30 days after the demand due date a sale is regarded to be lost and the no delivery penalty incurs. Table 3.2 summarizes the product-specific costs in the model.

44

3 Model Building in SAP APO Supply Network Planning

c SAP AG Fig. 3.2. Example supply chain structure displayed in SAP APO.


Product X1 X2

S1 60 30

Location S2 F1 80 1000 1000

Table 3.1. Raw material procurement costs in the supply chain example in currency units per piece. The high costs for procurement directly in the factory are an easy way to prevent the optimizer from circumventing the suppliers in the model

Cost type Production [cu/piece] Delay penalty [cu/(piece · day)] No delivery penalty [cu/piece] Storage [cu/(piece · day)]

P1 25 10 350 2

Product P2 P3 X1 15 15 5 5 250 180 1 1 0.5

X2 0.5

Table 3.2. Location independent costs in the supply chain example (cu . . . currency unit). Delay and no delivery penalties only apply to customer locations where demand is created

The hard constraints in the example are the availability of the production resource R1 and the maximum sourcing quantity of X1 from supplier S1 which is modeled as limited capacity of a transportation resource. In case of unexpectedly high customer demand the capacity of R1 can be increased up to double its value for a penalty. In case the transportation resource T1 is at its capacity limit the raw material supply has to happen earlier in time incurring increased storage cost or from the alternative supplier S2 for a higher purchase price. Table 3.3 summarizes the resource data.

3.1 The Example Supply Chain Model

Normal capacity Extended capacity Capacity expansion cost

45

Resource R1 T1 8 h/day 1000 pieces/day 16 h/day 2000 cu/h -

Table 3.3. Resource capacities and capacity expansion cost in the supply chain example. T1 can supply 1000 units X1 every day (cu . . . currency unit)

The last data elements are the actual sources of supply: instructions how to make the products and how to transport the components and the finished goods. Making the three products requires a certain quantity of component X1 and one unit of X2 per piece. Depending on the product grade the production process on resource R1 is more or less complex which translates into different resource consumption for making the different products P1, P2, and P3. Along the lines of SNP as a tool for aggregated planning we define the capacity and time consumption in the production process models in a way that it considers activities not explicitly modeled. Thus, we aggregate operations such as setup, waiting time, cool-down, etc. into a processing time longer than the actual resource-consumption. For product P1, for instance, we modeled an output of 1000 pieces per day, but a resource consumption of only 6 hours (as opposed to a normal R1 availability of 8 hours per day). Table 3.4 gives the values for the three production processes.

Material consumption X1 [pieces] Material consumption X2 [pieces] Resource consumption R1 [hours] Processing time [days] Production output [pieces]

P1 3000 1000 6 1 1000

Product P2 2000 1000 4 1 1000

P3 1000 1000 4 1 1000

Table 3.4. Production process data in the supply chain example. The values refer to a product base quantity of 1000 pieces, e.g., it takes six hours of R1 capacity to make 1000 pieces of P1

Finally, Table 3.5 lists the existing transportation lanes in the example model. As we referenced them several times in this section the table should speak for itself. 3.1.3 A Mathematical Formulation of the Example Model As an illustration for optimization practitioners, in the following paragraphs we state one possible approach to the mathematical formulation of the model

46

3 Model Building in SAP APO Supply Network Planning Source Destination Material restriction Capacity restriction S1 F1 yes: X1 yes: transp. resource T1 S1 F1 yes: X2 no S2 F1 no no F1 C1 no no F1 C2 no no F1 C3 no no Table 3.5. Transportation lanes in the example supply chain model

just described, kept straightforward and simple. The reader has to keep in mind that this does not describe how the model is built in the SNP optimizer because the mathematical model in SAP APO is not public! We start by stating the sets of indices which define the domains of the input data, variables, constraints and costs included in the model. Unlike in the subsequent model formulation where we will stick to the mathematical formulation without filling in the example data, we here also give the set elements in this particular example:

p r l t d

C := {C1, C2, C3} : V := {S1, S2} : F := {F 1} : X := {X1, X2} : Y := {P 1, P 2, P 3} : ∈ P := {P 1, P 2, P 3, X1, X2} : ∈ R := {R1} : ∈ L := {S1, S2, F 1, C1, C2, C3} : ∈ T := {1, . . . , N T } : ∈ D := {1, . . . , N D } :

customers vendors (suppliers) plants components finished products products resource(s) locations time buckets demands

The data stored in the database need to be prepared and processed in such way that they can be used as the input data in this model. Note that the structure of data fields is dominated by the purpose they are used for, and therefore there might be structural differences between the data in the data model and those required by the mathematical model. First, we deal with the demand data and prepare for using late delivery and non-delivery penalties. We use the index d ∈ D to refer to individual demands that in the “ERP domain” are defined as (product, customer location, time bucket, quantity) quadruples. More detailed input data (in time) is to be aggregated accordingly. The vector Dd holds the quantity of demand d. Indicator tables provide the link between “ERP-like” demands and our indexed P demand quantities: the elements of the indicator table Ipd are 1 if demand d L is for product p and 0 otherwise , and Ild is 1 if demand d occurs at location l P L and 0 otherwise. Note that for each demand d exactly one of each Ipd and Ild are 1. Taking the length of the time buckets, the late delivery and non-delivery L costs into account, the tables Cdt and CdN can be constructed, representing

3.1 The Example Supply Chain Model

47

the penalty cost for delivering one product-unit of demand d in time bucket t, t ≥ 1, and non-delivery of one product unit of demand d, respectively. Due to the maximum delay there is a time bucket TdD for each demand d after which no further deliveries are possible and a non-delivery penalty needs to be paid for the open quantity: Dd P Ipd L Ild L Cdt CdN TdD

: : : : : :

quantity of demand d 1 if demand d is for product p (unique), otherwise 0 1 if demand d is at location l (unique), otherwise 0 cost of late delivery of demand d in time bucket t cost of non-delivery of demand d last time bucket in which deliveries for demand d are possible

Next we define the parameters relating to production. The bill of materials (BOM, recipe coefficients in the mass balances) Bpp
is stating the amount of component p needed for making product p. The table Rpr defines the resource capacity consumption of resource r for making one unit of product p. In case we want to consider lot sizes in production, we will also need the lot sizes of the products Lp , given in units of product p. Making one unit of product p has the cost CpP associated to it:
≥ 0 , (p ∈ Y, p ∈ X ) Bpp

= 0 otherwise ≥ 0 , (p ∈ Y) Rpr = 0 otherwise Lp : lot size of product p CpP : production cost The resources r (in our example there is only one) offer a standard capacity RrC and extended capacity RrX . Utilizing the resource with a load between RrC and RrX involves a capacity expansion cost of CrX per resource capacity unit (cf. Table 3.3, note that we do not use a transport resource in this formulation, but explicitely limit the transportation quantity below): RrC : standard capacity of resource r RrX : extended capacity of resource r CrX : capacity expansion cost of resource r Storing one unit of product p leads to the storage costs CpS , per time period : CpS : storage cost of product p Procuring one unit of product p at location l incurs procurement costs given P by Clp : P Clp : procurement cost There is a limit TllX
pt on the maximum transportation quantity of product p between locations l and l in time bucket t:

48

3 Model Building in SAP APO Supply Network Planning

TllX
pt : capacity of transportation lane l → l , for product p, time bucket t 0 , of product p at location l: Finally, we provide the initial stock level, Slp 0 Slp : initial stock level of product p at location l

The decision variables are defined in a straightforward way (all non-negative). Because we may want to introduce discrete production lots we model production as integer variables αlpt . The blpt variables are used for modeling product consumption by production processes and the variables fdt are used to track fulfilment of each demand d for calculating late and non-delivery penalty costs: αlpt blpt slpt tll
pt dlpt fdt rlpt crt crt

: : : : : : : : :

production at location l in lots of product p in time bucket t production consumption at location l of product p in time bucket t 0 stock at location l of product p at the end of time bucket t, slp0 := Slp  transport volume from location l to l of product p in time bucket t delivered product at location l, product p in time bucket t delivered quantity to satisfy demand d in time bucket t external purchase at location l of product p in time bucket t used capacity of production resource r in time bucket t used extended capacity of production resource r in time bucket t

Because of the choice to aggregate suppliers, plants, and customers into locations, and components and finished goods into products we have to introduce a number of additional bounds (a good modeling tool or the solver’s presolving technology will exploit these bounds and will eliminate variables where possible). Production is only possible in plants producing finished products, i.e., vice versa: αlpt = 0, blpt = 0 except for l ∈ F,

p∈Y

.

Although not specified in Sect. 3.1, we here consider no inventories at the customer locations, i.e., slpt = 0 ;

∀l ∈ C

,

∀{pt}

.

Transportation is only allowed from suppliers to plants for components and from plants to customers for finished products. Additionally, it is necessary that the products exist at both ends of the transport connection (see the comment below): tll
pt = 0 except for (l ∈ V, l ∈ F, p ∈ X ) or (l ∈ F, l ∈ C, p ∈ Y)

.

Demand can only be fulfilled at customer locations: dlpt = 0

except for l ∈ C

.

External purchase is only possible for components and at supplier locations and plants (cf. Table 3.1):

3.1 The Example Supply Chain Model

rlpt = 0 rlpt = 0

for l ∈ C , ∀{pt} for p ∈ Y , ∀{lt}

49

.

In addition to these domain restrictions, note that all variables are only created for existing combinations of location and product. Component X2, for instance, does not exist at supplier S2. Therefore, all decision variables for (l, p) = (S2, X2) have a bound of 0. One way to accomplish this is via another index table included in the bounds above. For readability reasons we do not state these bounds in the equations, however. The material balance models the material flow:   tl
lpt +Lp αlpt +slp,t−1 +rlpt = tll
pt +dlpt +slpt +blpt , ∀{lpt} (3.1) l


l


The left-hand-side of (3.1) contains the ingoing material flow into a node balance point ∀{lpt}: inbound transport, production, stock level at the end of the previous time bucket, and external purchase. The right-hand-side of (3.1) contains outbound transport, demand fulfillment, the stock level of time bucket t, and the consumption of component p by production processes. The deliveries dlpt are used to satisfy demand, which is captured in fdt :  L P dlpt − Ild Ipd fdt = 0 , ∀{lpt} d



fdt ≤ Dd

,

∀d .

t L P Note that several terms Ild Ipd fdt can contribute to the delivery variable dlpt , i.e., one delivery dlpt can contribute to satisfying multiple demands “of different age” for product p at customer location l. No further deliveries are allowed after the maximum delay time bucket TdD :   fdt = 0 , ∀ dt|t > TdD .

Let us explicitely formulate the production process now. We start with consuming components blp
t defined by the bill of material (BOM) coefficients Bpp
:  Lp αlpt = Bpp
blp
t , ∀{lpt} p


and continue with the resource consumptions:  Rpr Lp αlpt = crt , ∀{lrt} p

crt ≤ RrC + crt , ∀{rt} crt ≤ RrX , ∀{rt} Finally, the transportation volume constraint in Table 3.3 is formulated:

50

3 Model Building in SAP APO Supply Network Planning

tll
pt ≤ TllX
pt

∀{ll pt}

,

.

Note that the time-dependence of T X is not used in this example (it could be used to modeling river shipment with varying water levels in winter and summer, for instance). For the objective function, in this example minimizing total cost, we add the cost of late delivery, C D ,  L Cdt fdt , CD = t

d

the cost of non-delivery, C N , C

N

=



Dd −

CdN



,

fdt

t

d

the total production cost, C P ,  CpP Lp αlpt CP = p

l

the total procurement cost, C B ,  P Clp rlpt CB = p

l

,

t

the total capacity expansion cost, C X ,  CrX crt CX = r

,

t

,

t

and the total storage cost, C S , CS =

 l

p

CpS slpt

.

t

Finally, the objective function is the total cost, z, min z

,

z := C X + C P + C S + C B + C D + C N

.

As mentioned above the purpose of this model is to provide an illustration of how a model entered to SAP APO might look like in its mathematical form. The small model presented here is, of course, not as generic and complete as the predefined model implemented in SAP APO covering many more features. In the next section, we are looking at how a supply chain model like this is set up in SAP APO for optimization-based supply chain planning.

3.2 Supply Chain Model Master Data

51

3.2 Supply Chain Model Master Data As a prerequisite of any planning process the elements of the supply chain model have to be maintained in the respective parts of the SAP APO system. As we do not intend to elaborate on integration to ERP backbone systems such as mySAP ERP we create and maintain all master data in SAP APO.1 In the following sections on the individual master data elements we will state the SAP APO transactions which we use as menu paths in the SAP SCM system. The release we used for the menu paths and the screen shots is SAP SCM 4.1 SP 4. For quick access via the command field in the SAP GUI the respective transaction codes are given in parentheses. From anywhere within the SAP APO system a transaction can be reached by preceding the transaction code with “/n”, for example enter “/n/SAPAPO/MVM” for getting to Model and Version Management. Before we start with creating the master data and setting the parameters for an SNP planning run we would like to mention that many settings can be defined in a time-dependent fashion. The scrap value of a production process can decrease with time to model yield learning curves in production, for instance. Another example is phasing certain components in or out. For the sake of brevity and clarity we do not discuss these features here and refer to the product documentation mentioned above (p. 41). Since release 4.1 SAP APO offers the production data structure (PDS) next to the production process model (PPM) as another way to model production processes in SAP APO. SAP recommends to use the PDS for new SAP APO implementations and for upgrade projects, but continues to support the PPM data model. As for our purposes there is no significant difference whether we use PDS or PPM in our example supply chain model we will stick to the well tried production process model (PPM). This way readers who have access to a release of SAP APO prior to 4.1 can directly try out our example. For the optimizer functionality it does not make a difference whether PDS or PPM is used because both are representations of the production process; the difference is primarily in how the underlying data are entered, how they are created, and how they integrate with mySAP ERP. 3.2.1 Models and Planning Versions in SAP APO The supply chain model as an object in SAP APO holds the master data defining the supply chain such as locations, transportation lanes, products, resources, and production process models. It is created in SAP APO Model and Version Management at the menu path Advanced Planning and Optimization → Master Data → Planning Version Management → Model and 1

Maintaining some data in SAP APO is necessary even in the case of using SAP APO and SAP R/3 in SAP’s integration scenarios. This is because not all data elements used for planning in APO are available in R/3.

52

3 Model Building in SAP APO Supply Network Planning

Version Management (/SAPAPO/MVM). The screen coming up lists the different supply chain models and planning versions in the system. By pressing the Create button (looking like an empty sheet of paper, see Fig. 3.3) and selecting Model from the appearing drop-down menu a new model is created (we call our example model SIMPLE ). The only parameters for creating the supply chain model object are the model name and a describing short text.

c SAP AG Fig. 3.3. Model creation in SAP APO.


For each model at least one planning version must exist. Planning versions contain a selection of data for the actual planning process and – unlike the model that contains master data – the version holds transactional data such as forecasted demand, customer orders, or planned production orders, for example. Additionally, some version-dependent properties of products, locations, and resources are stored in the planning version allowing it to easily create simulation versions for what-if analyses. Examples of such version-dependent data are penalty costs for unfulfilled customer demand which we will use later. A planning version is created in the Model and Version Management transaction by selecting the model and choosing Planning Version from the drop-down menu of the Create button (see Fig. 3.4). The model/version parameters are relevant for SNP and other planning modules. For our purposes we check the box next to Local Time Zone because we will use location time zones different from UTC. The other SNP parameters remain at their default values because • •

Change Planning Active affects the SNP heuristics only. No Order w/o Source of Supply affects the behavior of the optimizer in case there is no production process defined for products manufactured inhouse. Leaving the box unchecked results in the optimizer creating planned production orders for those products without reference to a PPM (for a description of production process models or PPMs see Sect. 3.2.5). In our

3.2 Supply Chain Model Master Data

53

c SAP AG Fig. 3.4. Planning version creation in SAP APO.


example it does not make a difference whether this feature is activated or not and hence we do not change the default value. • Consider Stock Transfer Horizon of Source Location affects CTM planning only. If SAP APO is to be used in connection with an ERP system such as mySAP ERP it is important to know that only one model and one planning version receive data from the other systems. These are called active model and active planning version. Other models and versions are typically used for simulation planning runs before the actual operative results are transferred to the execution system (by copying the respective model/version into the active one, for instance). The active model and version are always called model 000 and planning version 000. As we do not use mySAP ERP integration in our example we will work in the SIMPLE model and version. For more information on integrating SAP APO with mySAP ERP via the Core Interface (CIF), see Dickersbach (2004, [17]). 3.2.2 Locations Locations correspond to physical entities of the modeled company and/or business partners and can have different types such as production plant, distribution center, supplier, or customer. Since SAP SCM release 4.0 suppliers

54

3 Model Building in SAP APO Supply Network Planning

are called vendor s. The path for maintaining locations in SAP APO is Advanced Planning and Optimization → Master Data → Location → Location (/SAPAPO/LOC3). Apart from the location code and a descriptive text, necessary data entries are location type, time zone, and calendar. If – like in the example – the address of the location is given by specifying at least the country, the time zone and certain data pertaining to transportation will be suggested by the system. Figure 3.5 shows the location maintenance screen with the address tab selected, Table 3.6 the individual locations that have to be created in our example.

c SAP AG Fig. 3.5. SAP APO location maintenance screen.


Location S1 S2 F1 C1 C2 C3

Location Type Vendor Vendor Production Plant Customer Customer Customer

Country Hungary Italy Austria France Germany Switzerland

Region/City Budapest Milan Vienna Paris Berlin Zurich

Table 3.6. The locations in the example supply chain model

Note that upon creation the location is created for the active planning version 000. As the version-specific location data are intended for TP/VS2 we do not need to take care of setting special version-specific parameters 2

TP/VS is the Transportation Planning and Vehicle Scheduling module in SAP APO and responsible for routing and load consolidation.

3.2 Supply Chain Model Master Data

55

for our planning version SIMPLE. An easy way to find out which location data is version-specific, go to the location master entry screen, press the Set Planning Version button, choose a planning version (such as SIMPLE ) and select Change. All but the version-specific fields in the location master data will be read-only. We do have to assign the locations to the model SIMPLE, though. We recommend doing this in one process for all master data later on instead doing it from each individual master data maintenance screen. We will demonstrate this process in Sect. 3.2.6. 3.2.3 Products and Location Products SAP APO distinguishes between product properties that depend only on the product itself and those that additionally depend on the specific location where a product may reside or be processed. An example for “global” product data is the product code that is a company-wide (or – in this context – a supply chain-wide) constant, a location-specific property may be storage cost. An important attribute for a location product is the procurement type that determines whether a product can be produced at a specific location or not. Via the procurement type planning algorithms determine whether to look for supply from other locations, from production, or whether to just assume that demands are handled externally. In our little example we use three end products (P1, P2, and P3 ) manufactured from two different components X1 and X2. Consequently, these five different products can occur at different locations in the supply chain, which results in 17 location products: • The components X1 and X2 are procured from vendor S1. • X1 can also be procured from vendor S2. • At the plant F1, the end products P1, P2, and P3 are manufactured consuming X1 and X2. • Any of the customers C1, C2, and C3 can request any end product. Note that in the product master data we do not state how the production processes look like – the location product master data defines only properties of products at specific locations and does not contain bill of material or routing information. In SAP APO each location product needs to be created. We create the location products in two steps: first the planning version-independent data and then we create the location product for the planning version SIMPLE and add version-dependent parameters. The menu path for maintaining productrelated data in SAP APO is Advanced Planning and Optimization → Master Data → Product → Product (/SAPAPO/MAT1). In the first step we maintain the product codes, descriptions, units of measure, and the procurement types (see Figs. 3.6 and 3.7).

56

3 Model Building in SAP APO Supply Network Planning

c SAP AG Fig. 3.6. SAP APO location product maintenance entry screen.


c SAP AG Fig. 3.7. SAP APO location product master, procurement view.


Procurement types determine whether the planning algorithm will try to manufacture the product at the specified location (type E ), source it from another location involving transportation (type F ), or choose either alternative depending on costs or other supply chain settings (type X ). Type P is used for products not planned in SAP APO; e.g., it is used in CTM models at supplier locations, in our optimization example we use procurement type F instead. Table 3.7 gives the data to be used when creating the location products. In order to implement the costs and (soft) constraints explained earlier in Sect. 3.1.2, there are some planning version-dependent location product attributes to be maintained. These include procurement costs, storage costs, and penalties for late delivery and no delivery along with the maximum order delay that distinguishes between late and no delivery. The location product procurement costs are also used for calculating penalties for expired product quantities in case the shelf-life concept is included in the supply chain model.

3.2 Supply Chain Model Master Data

57

Product Location Product description Base unit Procurement type X1 S1 Component X1 PC F F X1 S2 F X1 F1 X2 S1 Component X2 PC F F X2 F1 P1 F1 Product P1 PC E F P1 C1 F P1 C2 F P1 C3 P2 F1 Product P2 PC E F P2 C1 F P2 C2 F P2 C3 P3 F1 Product P3 PC E F P3 C1 F P3 C2 F P3 C3 Table 3.7. Location product data maintained version-independently. For clarity, global product attributes are only listed once

If the optimization objective is set to profit maximization the no delivery cost is interpreted as the revenue generated by selling one unit of the respective location product for optimizing profit or contribution margin. For creating the location product for our planning version SIMPLE, select the planning version on the product master entry screen via the Choose planning version button (cf. Fig. 3.6) and re-create the product for the version. As examples, Fig. 3.8 shows part of the screen for entry of the procurement and storage costs for component X1 at the supplier S2 and Fig. 3.9 shows maintaining the delivery penalties. The units of measure are currency units

c SAP AG Fig. 3.8. Maintaining version-dependent costs for a location product.


58

3 Model Building in SAP APO Supply Network Planning

Fig. 3.9. Maintaining version-dependent delivery penalties for a location product. c SAP AG


per day and product base unit for the storage cost and delay penalty, currency units per product base unit for the procurement cost and no delivery penalty, and days for the maximum delay. If a delay in delivery would be bigger than the maximum delay value the demand is dropped and the no delivery penalty incurs. Product Location Procurement cost Storage cost

X1 X2 S1 S2 F1 S1 F1 60 80 1000 30 1000 0.5 0.5 0.5 0.5 0.5

Product P1 P2 P3 Location F1 C1, C2, C3 F1 C1, C2, C3 F1 C1, C2, C3 Storage cost 2 2 1 1 1 1 10 5 5 Delay penalty 350 250 180 No delivery penalty 30 30 30 Maximum delay Table 3.8. The version-specific costs for the location products in the example supply chain. See text for units and more information

Each location product has to be created and maintained in our planning version SIMPLE. For clarity, we summarize the cost information relevant for location products from Sect. 3.1.2 in Table 3.8. We suggest maintaining the penalty costs at a detailed location productspecific and demand category level like in Fig 3.9 in order to leave room for easy experimenting with the cost structure when you try the model on your

3.2 Supply Chain Model Master Data

59

own. In the planning run which we will execute in Chap. 4 only demand forecasts will be used. 3.2.4 Resources Resources provide a pool of capacity that is used by operations like production, transportation, storage, etc. In our example we need one production resource R1 at the production plant F1 and one transportation resource T1 that we use for modeling the limited supply of raw material X1 from supplier S1. 3.2.4.1 General Resource Data The menu path Advanced Planning and Optimization → Master Data → Resource → Resource (/SAPAPO/RES01) leads to the resource maintenance entry screen. In the example in Fig. 3.10 we look at resource T1 in our planning version SIMPLE.

Fig. 3.10. Resource maintenance entry screen in SAP APO. Note that we already c SAP AG entered the planning version.


Clicking the Create button leads to a form like in Fig. 3.11 in which the resource attributes are defined. In this context it is important to select the correct tab before entering data in order to create a resource of the right type (Transportation for T1 and Bucket for R1 ). For production processes in SNP resources of type Bucket, Single-Mixed, or Multimixed can be used (cf. Sect. 1.3). Table 3.9 lists the resource attributes that have to be entered on this screen. All the non-listed attributes remain at their default values (e.g., we could change the capacity utilization rate to model the effect of breaks, expected machine downtime, overtime, etc.). Factory calendar 99 is a predefined calendar including international holidays, AT corresponds to the country the factory F1 is located in.

60

3 Model Building in SAP APO Supply Network Planning

c SAP AG Fig. 3.11. Resource master data in SAP APO.
Resource T1 R1 Category T P F1 Location CET CET Time zone Bucket dimension MASS TIME 99 AT Factory calendar Bucket capacity 1000 8 KG H Unit 1 1 Number of periods Day Day Period type 30 30 Days – 180 180 Days + Table 3.9. Resources in the example supply chain model

The capacity in SNP is defined by planning time bucket which by definition is one day. Consequently, R1 is available for eight hours a day, T1 can transport 1000 kg per day. If, for instance, one transportation turn takes only six hours, a transportation process executed on resource T1 can transport four times 1000 kg = 4000 kg per business day (like we stated in Table 3.3 on p. 45). We will use this reasoning later on when we deal with transportation lane capacity consumption.

3.2 Supply Chain Model Master Data

61

3.2.4.2 Resource Capacity Variants The last resource setting still missing is considering a possible expansion of the production capacity of R1 such as defined in Sect. 3.1.2. In order to model this feature we define a capacity variant of R1 with associated penalty cost. First, we create and save a Quantity/Rate Definition via the Definitions button in the master data screen of R1 (cf. Fig. 3.11). Figure 3.12 shows an example, for our purposes only the MAX CAPACITY line has to be there.3 The entry corresponds to a maximum extended capacity of 16 hours a day (instead of eight hours in normal mode) for the cost of 2000 currency units per hour.

c SAP AG Fig. 3.12. Quantity/rate definitions for a bucket resource.


Now the quantity/rate definition is assigned to a capacity variant of R1 via the Capacity Variants button in the master data screen of R1 (cf. again the screen in Fig. 3.11). Pressing the + Interval button lets you add a capacity variant. The variant identification for extended capacity is 79 and references the quantity/rate definition from before. Figure 3.13 sketches the capacity variant screen after adding MAX CAPACITY. The other two variants on the screen are optional and not used in this example. 3.2.5 Production Process Models The production process model (PPM) defines how a product is made and represents the probably most complex master data object in SAP APO. It combines information from the bill of material (BOM) listing the components a product consists of and the routing that defines what production steps are necessary along with the respective resource usage to make the product. The components in the PPM correspond to BOM data whereas data relating to resources define the modes of a PPM. As outlined in Fig. 3.14, a PPM is organized in operations and activities and the components and modes are assigned at the activity level. 3

BELOW MIN can be used to force minimum resource utilization. A possible business application scenario might be to keep a production site active even if the mathematically optimal solution would suggest to close it.

62

3 Model Building in SAP APO Supply Network Planning

c SAP AG Fig. 3.13. Capacity variants of a bucket resource.


Operation 1 Activity 1

Activity 1

Res. a, b,.. Input materials

Operation n

Output materials

Res. c, d,.. Input materials Output materials

Fig. 3.14. Schematic structure of a PPM. Input and output materials are also called components, so called modes define resources and capacity consumptions

In SAP APO there are two entities in this context: the “plan” and the “PPM”. The plan holds the actual information about the production process and the PPM is used to access the plan (for a planned production order, for instance). As the distinction between “plan” and “PPM” is not always consistent in SAP APO we will use PPM to refer to both entities (cf. Dickersbach, 2004, [17]). 3.2.5.1 General PPM Data As an example we will describe step-by-step how to create the PPM defining the production process of the product P1 in location F1. The menu path to PPM maintenance is Advanced Planning and Optimization → Master Data → Production Process Model → Production Process Model (/SAPAPO/SCC03). For creating a PPM its name and use are entered on the entry screen as shown in Fig. 3.15 – in our case the Plan field contains PPM P1 and Use of a Plan is S because the PPM is intended to be used in SNP.4 4

Other SAP APO applications such as DP and PP/DS have their own PPM types (see Dickersbach, 2004, [17], for instance).

3.2 Supply Chain Model Master Data

63

c SAP AG Fig. 3.15. The entry screen for maintaining PPMs.


Clicking the Create button leads to the screen for maintaining the PPM such as Fig. 3.16 shows – with the exception that the PPM will not contain any objects upon creation, of course. The screen layout is the same for creating, changing, or displaying a PPM. On the left side of the screen there are two windows for navigating between the different elements of the PPM via a menu tree or graphically and on the right hand side the selected data is displayed. It is vital not to accidentally leave the transaction by using the Back, Exit, or Cancel button of the SAP GUI instead of navigating one operation “back” inside the PPM – the buttons on top will leave the PPM maintenance transaction instead of moving around inside the PPM. Remember to always use the PPM-internal navigation for such tasks by using the menu tree, the graphical diagram or the buttons that appear at different locations throughout the PPM user interface. On the initial screen we first name the plan by filling out the Description field and assign the cost that incurs when this PPM is used. In Table 3.2 (p. 44) we list a production cost of 25 per piece P1. Because we will use a base quantity of 1000 pieces in the PPM when we define the components and modes a cost of 25,000 for using the PPM has to be entered in the Single Level Costs – Variable field in Fig. 3.16. In the example we use just one operation that is created by typing in its name in the Operations sub-window. Double-clicking on the name of the operation leads to the operations and activities view shown in Fig. 3.17, already with one activity of type P (for produce) and zero scrap entered. Available activity types are produce, setup, teardown, and queue time. In SNP optimization each operation can contain only one activity which – for example – leads to the necessity of creating a separate operation for the setup activity in case campaign planning is an issue. A double-click, this time

64

3 Model Building in SAP APO Supply Network Planning

Fig. 3.16. The PPM maintenance screen – note the object tree on the left hand side c SAP showing the operation, activity, and the associated mode and components.
AG

c SAP AG Fig. 3.17. Operations and activities view in the PPM.


on the activity name, leads to the next screen where components and modes are defined. 3.2.5.2 Components On the component view screen (Fig. 3.18) we define the products that are involved in the production process of the activity. Products consumed are classified as input products (I/O Indicator set to I ) and products in which the production process results are called output products (I/O Indicator set to O). Co-products are modeled by entering multiple output products.

3.2 Supply Chain Model Master Data

65

c SAP AG Fig. 3.18. The components view of a PPM activity.


The Consump. Type field defines when the components are consumed or output. Available values are S for consumption at the start, E for consumption at the end of the activity, and C for continual consumption. We choose to assign input products the consumption type S and output products the consumption type E. The validity period for the individual component definitions is given by stating the from and to dates which we chose such that no time dependencies exist in the planning period. Finally, the component quantities have to be defined which at the same time define the base unit of the PPM we used for calculating the production cost. In our example we choose 1000 pieces as the reference quantity. According to the material consumptions in Table 3.4 (p. 45) we enter 1000 for P1, 3000 for X1, and 1000 for X2 in the Var. Consumptn field. Please note that the line for X2 is missing in Fig. 3.18 because the SAP APO GUI always displays two component lines only and does not allow resizing the sub-window. 3.2.5.3 Modes Having defined the input and output materials in the components section of the activity, we still need to define the resource consumption and process durations by selecting the Mode tab in Fig. 3.18.

c SAP AG Fig. 3.19. The mode view of a PPM activity.


66

3 Model Building in SAP APO Supply Network Planning

On the lower part of the screen modes can now be entered like illustrated in Fig. 3.19. Straightforwardly, we define one mode 10 to use resource R1 (location F1 is filled in automatically from the resource master data) taking one day processing time. This duration does not relate to resource capacity consumption, but defines how long executing the PPM producing the base quantity takes. In SNP the duration has to be an integral multiple of one day.

c SAP AG Fig. 3.20. The resource view of a PPM mode.


Double-clicking in the mode line continues to the mode view where actual resource capacity consumptions are maintained (Fig. 3.20). Following the data in Table 3.4, we define six hours of R1 capacity to be consumed by making the PPM reference quantity of 1000 pieces (entering the six hours in the Var. Bucket Consumptn field). Together with the activity duration defined in the mode we modeled the production process defined in Sect. 3.1.2: It takes one calendar day to make 1000 pieces of P1, but only six hours production resource capacity. This step concludes the operation and activity maintenance in our example. As we only model one operation there is no need to define how the individual activities are connected. These activity relationships are somewhat simple in SNP in the sense that only a single chain is allowed resulting in each activity (other than the single first and single last activity) having exactly one predecessor and one successor.5 5

If necessary, the relations can be defined via the Activity Relationshps button on the activity screen.

3.2 Supply Chain Model Master Data

67

3.2.5.4 Product Plan Assignment Finally the product plan assignment has to be done. It defines which product the PPM is assigned to and a number of other general parameters. Pressing the appropriate button (cf. Fig. 3.20) opens the table displayed in Fig. 3.21.

Fig. 3.21. The product plan assignment table in PPM maintenance – for better c SAP AG readability two parts are pasted together.


As distinguishing the “Plan” and “PPM” objects is not easy in SAP APO we choose the same name PPM P1, product P1, a large validity period, planning location F1, and a large lot size interval the entry shall be valid for. By defining different validity periods or lot size intervals we could model different production processes depending on time or on the quantity of goods to be produced, respectively. Checking the Discretization box allows optimizationbased planning runs that result in integral multiples of the PPM reference quantity; in our case we will produce in integer multiples of 1000 pieces in one scenario. Another optimization-relevant field is Bucket Offset containing a rounding value for determining the availability date of a receipt within a time bucket. We do not use the latter feature in our example, though. 3.2.5.5 PPM Activation For actually using the PPM it has to be saved and activated. Both saving and activating involve a consistency check which reports certain issues as warnings to the user or error messages preventing activation. Fig. 3.22 shows which buttons invoke the different functions along with a warning we will get. It is about a missing PP/DS plan linked to the SNP plan, which we ignore by confirming the message because PP/DS is not used in our example. After activating and saving we successfully created a production process model for the first product P1 in our example supply chain model.

68

3 Model Building in SAP APO Supply Network Planning

Fig. 3.22. Activating the SNP PPM will result in a warning about a missing linked c SAP AG PP/DS plan.


3.2.5.6 PPM Data in the Example Model Along the lines of the last paragraphs we created the PPM for the product P1, but we need to get two more that define the production process for the remaining products P2 and P3. For each of the PPMs, the following procedure applies: 1. Create the general PPM data consisting of the header as given in Table 3.10 and the one operation 0010 Produce and activity 10 Produce of type P. Field Use Description Single Level Costs PPM PPM P1 S Simple PPM for Product P1 25,000 15,000 PPM P2 S Simple PPM for Product P2 15,000 PPM P3 S Simple PPM for Product P3 Table 3.10. PPM header data in the example model

2. In the activity, create entries in the components section for the output products P1, P2, or P3, respectively, and the components X1 and X2 as listed in Table 3.11. 3. In the activity, create a mode 10 with primary resource R1, unit of measure D, and fixed duration 1. In the mode, maintain the variable bucket consumption as given in Table 3.12.

3.2 Supply Chain Model Master Data

69

Field Variable PPM Component I/O Indicator Consumption Type Consumption PPM P1 P1 O E 1000 I S 3000 X1 I S 1000 X2 P2 O E 1000 PPM P2 I S 2000 X1 I S 1000 X2 P3 O E 1000 PPM P3 I S 1000 X1 I S 1000 X2 Table 3.11. PPM component data in the example model Field Variable Unit of Measure Bucket Consumption PPM PPM P1 H 6 H 4 PPM P2 H 4 PPM P3 Table 3.12. PPM resource capacity consumption data in the example model Field Production Planning Maximum Process Model Location Discretization Lot Size PPM PPM P1 PPM P1 F1 × 9,999,999 PPM P2 F1 × 9,999,999 PPM P2 PPM P3 F1 × 9,999,999 PPM P3 Table 3.13. Product plan assignment data in the example model

4. Fill in the product plan assignment using the data in Table 3.13. 5. Activate and save the PPM. The only message from the model check when activating should be the one about the missing linked PP/DS plan mentioned above. 3.2.6 Assembling the Parts with the Supply Chain Engineer The master data elements created so far are not yet assigned to the supply chain model created in Sect. 3.2.1. This assignment can be done directly from the master data maintenance screens via the Assign model button or menu entry similar to setting the planning version, but then the same procedure has to be applied to each of the locations, location products, resources, and production process models one by one.

70

3 Model Building in SAP APO Supply Network Planning

A more convenient way of defining the constituents of a supply chain model is to use the Supply Chain Engineer. Besides visualizing the master data this tool helps in adding the master data elements to a supply chain model and provides an easy way to view the model elements all in one place. It is not necessary to use the Supply Chain Engineer during model setup, but it is essential that all relevant master data is assigned to the supply chain model.

c SAP AG Fig. 3.23. The Supply Chain Engineer entry screen.


Selecting Advanced Planning and Optimization → Master Data → Supply Chain Engineer → Maintain Model (/SAPAPO/SCC07) and entering the model name and a work area6 on the following screen (see Fig. 3.23) followed by a click on the Change button leads to an empty map such as in Fig. 3.24. The screen in the Supply Chain Engineer is divided into two parts: the upper part is displaying a world map which shows the locations and transportation lanes once objects are added to the work area and the lower part displays the master data elements of the work area. Objects in the work area that are not part of the model are displayed differently from members of the model. Context menus offer several functions such as adding and removing objects to and from the work area and model, maintaining the respective master data elements, maintaining quotas and transportation lanes, etc. Visualizing the supply chain model in the Supply Chain Engineer is a twostep process: adding the objects to the model and adding the objects to the work area displayed on the screen. We choose to first put the objects into the model and then adding them all to the work area. Clicking the Add Objects to Model button denoted in Fig. 3.24 opens a dialog for selecting objects to be added to the model looking like Fig. 3.25. Via the Change buttons we now add the products, locations, location products, resources, and production process models in the respective selection windows. Often it is necessary to double-check that the correct master data is assigned via the respective Display buttons. Adding the objects to the model should finish with a message such as in Fig. 3.26. In order to actually display the model objects in the Supply Chain Engineer, they have to be added to the work area. The easiest way of doing this 6

A work area is simply a filter of master data to be displayed in the Supply Chain Engineer and has no impact on planning. We will not use the concept of different work areas of the same model here.

3.2 Supply Chain Model Master Data

71

c SAP AG Fig. 3.24. An empty work area in the Supply Chain Engineer.


Fig. 3.25. Adding objects to the model in the Supply Chain Engineer. Note that the Basic Quantity section that limits the basic set of objects to be added is not c SAP AG shown for a new work area.


Fig. 3.26. The master data objects were successfully added to the supply chain c SAP AG model.


72

3 Model Building in SAP APO Supply Network Planning

c SAP AG Fig. 3.27. Adding objects to a Supply Chain Engineer work area.


is clicking the Objects in Model button (cf. Fig. 3.24) that opens a window listing all model objects which can be added to the work area with the click of another button such as in Fig. 3.27. In case anything goes wrong in the process of adding the master data objects to the model or the work area please repeat the steps described above for the missing objects. The optimization planning process will not work if any of our master data elements is missing in the model. 3.2.7 Transportation Lanes The last master data objects we create for the example model are the transportation lanes defining the detailed properties of cross-location product flows in the supply chain. As they are always created for a specific supply chain model we create them after we have assigned all other elements to the model in Sect. 3.2.6. Transportation lanes provide a convenient way to model the assignment of a supplier to a specific plant, for example. They can be defined specific to the product and different means of transportation such as air or truck can coexist. We will use different means of transportation for putting a constraint on the transport quantity of component X1 from supplier S1 to the factory F1 while transportation of X2 over the same lane remains unconstrained. The appropriate SAP APO transaction is Advanced Planning and Optimization → Master Data → Transportation Lane → Transportation Lane (/SAPAPO/SCC TL1). On the entry screen the model name along with the start and destination locations have to be specified. In Fig. 3.28 we entered the data for transportation from supplier S1 to the factory F1. Hitting the Create button leads to a screen similar to the one shown in Fig. 3.29, but without any entries in the three sections Product-Specific Transportation Lane, Means of Transport, and Product-spec. Means of Transport. Depending on how complex

3.2 Supply Chain Model Master Data

73

Fig. 3.28. The transportation lane entry screen in SAP APO – note that transc SAP AG portation lanes are model-specific.


transportation needs to be modeled two or all three of these sections have to be populated with data. In our model we have two cases:

c SAP AG Fig. 3.29. Defining product-specific transportation lanes in SAP APO.


1. For transportation from supplier S1 to the factory F1 we distinguish between components X1 and X2. For the former there is a constraint on the maximum transportation quantity, for the latter there is no such constraint. In the model there is one means of transport Car that consumes the capacity of a transportation resource and one means of transport Truck that does not. The components are assigned to the means of trans-

74

3 Model Building in SAP APO Supply Network Planning

port accordingly. Therefore, we need to create entries in all three sections since different products are transported by different means of transport. 2. For all other transportation lanes there are no such constraints so that we can model them by simply creating a means of transport and assigning all products to it. As suggested by Fig. 3.29, we will start with the more complicated, but general case. As we just mentioned, transporting the components X1 and X2 is treated differently. Hence, we create entries for these products in the Product-Specific Transportation Lane section. Hitting the appropriate button (cf. Fig. 3.29) opens a sub window on the right hand side of the screen where the components X1 and X2 are entered as well as a sufficiently large time interval for our planning purposes. All other parameters – including the optimizer-relevant ones such as the transportation cost function – remain at their default values as we do not use them in our example. Clicking on Copy and Close adds the data to the according section of the transportation lane screen. The product-specific data can be maintained in one step using the Mass Selection functionality in the sub window (upon creation of the product-specific transportation lane there is a Mass Selection radio button) or created one by one as shown for the first component X1 in Fig. 3.29.

c SAP AG Fig. 3.30. Defining means of transport in SAP APO.


For modeling the transportation constraint we use two means of transport. Fig. 3.30 shows the sub window that opens on the right hand side of the

3.2 Supply Chain Model Master Data

75

screen after clicking the Create button in the Means of Transport section of the screen. For the constrained means of transport data as shown in Fig. 3.30 is entered: • Validity Period : enter an arbitrary means of transportation, in our example Car 7 and start and end dates covering the time period we want to run the planning in. For more sophisticated setups transportation lanes can be maintained in a time-dependent way similar to most other model elements. • Control Indicator : for our case it is important that Valid for All Products is not checked and both Aggr. Planning and Fix Trsp. Duration are checked. The latter is needed for fixing the duration of the transport manually since we want to precisely control the transportation resource capacity consumption. Disc. Mns. of Trans. controls whether the optimizer uses the means of transportation in discrete intervals, which we do not use in our example. • Parameters: a click on the Generate Proposal button fills the distance and duration fields with proposed values – the latter only if a speed is maintained in customizing for the selected means of transport. In any case, we overwrite the Trsp. Duration field with 6:00 hours for reasons we will see a bit later. In the Resource field our transportation resource T1 is entered. The Bucket Offset determines the availability date of a receipt within a time bucket calculated by the optimizer. In our case it is at its default value of 1 which translates into product availability at the start of the time bucket containing the transportation end date. The Period Factor is not used by the optimizer and remains at its default value. Again, a click on the Copy and Close button adds the means of transport to the middle section of the screen and closes the sub window on the right. After Car has been created successfully, we need to create a second means of transport Truck with exactly the same properties apart from the resource assignment – that is, the Resource field is left blank. The last step in creating this most complicated transportation relationship in our model is to combine the (product-specific) transportation lane and the appropriate means of transport. The result is a set of entries in the bottom part of the screen defining the parameters of the product-specific means of transport that exist on the transportation lane, e.g., transport capacity consumption. Figure 3.31 shows how the screen looks like after highlighting the X1 line on the top part (Product-Specific Transportation Lane) and clicking 7

If Car does not exist you can use any entry (other than Truck which we will use later) or create Car in SAP APO customizing via transaction Tools → Customizing → IMG → Execute Project (SPRO), clicking the SAP Reference IMG button and executing mySAP SCM - Implementation Guide → Advanced Planning and Optimization → Master Data → Transportation Lane → Maintain Means of Transport (execute by clicking the green check mark next to the menu entry). As we will not use system proposals for the transportation duration for Car there is no need for maintaining speed data.

76

3 Model Building in SAP APO Supply Network Planning

c SAP AG Fig. 3.31. Defining product specific means of transport in SAP APO.


on the creation icon for product-specific means of transport. The only necessary entries for X1 are in the fields Means of Transport which takes the code for Car and Consumption which we set to 4 kg. After Copy and Close the same procedure is repeated for the component X2 which is assigned to the means of transport Truck. Hence, transporting it uses no resource capacity. In Sect. 3.1.2 we formulated the constraint that the supply of X1 from S1 to F1 has a upper limit of 1000 units a day. The consumption value of 4 kg, the transport duration of six hours, and the bucket capacity of resource T1 of 1000 kg per day provide this constraint: four transportation turns fit in one day (4 × 6 h = 24 h) and because transporting one piece X1 consumes 4 kg of the available transportation capacity each turn takes 250 pieces X1. Together we arrive at our constraint of a maximum of 1000 pieces of X1 flowing from S1 to F1 every day. To be precise, this refers only to working days because when defining the resources in Sect. 3.2.4 we chose calendars that consider weekends and holidays. All the other transportation lanes are much simpler in structure because they do not involve constraints. Along the lines of what we did so far only the top two sections need to be populated with data. In the top section a “product-specific” entry that is valid for all products (select the All Products radio button instead of entering product codes when creating the lane) is created and in the middle section one means of transport is created valid for all products. Figure 3.32 shows how the simple transportation lane from the factory F1 to customer C1 looks like. The transportation duration corresponds to the value proposed by SAP APO in this case. Concluding this section and as a reference we list the data for all five transportation lanes in our model in Tables 3.14 to 3.17. According to the

3.2 Supply Chain Model Master Data

77

c SAP Fig. 3.32. The product independent transportation lane from F1 to C1.
AG Source Destination S1 F1 S2 F1 F1 C1 F1 C2 F1 C3

Product X1, X2 All Products All Products All Products All Products

Table 3.14. Product specific transportation lanes in the example supply chain model

sequence we used in this section first the product-specific lanes are given in Table 3.14 followed by defining the means of transport for the constrained and unconstrained lanes in Tables 3.15 and 3.16, respectively. At last the productspecific means of transport for the constrained lane is defined in Table 3.17. We do not list data deviating from the default values nor do we list date ranges presuming they are chosen so that they span the complete planning horizon. In the end, the Supply Chain Engineer graphical display of the model should look like in Fig. 3.2 on p. 44.

78

3 Model Building in SAP APO Supply Network Planning Source location Destination location Validity Period Means of Trans. Control Indicators Checked

S1 F1 Car

Truck

Aggr. Planning Detld Planning Fix Trsp. Duration

Unchecked

Valid for All Products Do Not Build Transit Stock Fix Trsp. Distance Disc. Mns of Trans.

Parameters Transptn Distance Trsp. Duration Resource

220.335 6:00 T1

–

Table 3.15. Means of transport data for the constrained transportation lane in the example supply chain model. The field names are spelled like in SAP APO Source location Destination location Validity Period Means of Trans. Control Indicators Checked

Unchecked

S2 F1

F1 C1

F1 C2

F1 C3

Truck Valid for All Products Aggr. Planning Detld Planning Do Not Build Transit Stock Fix Trsp. Duration Fix Trsp. Distance Disc. Mns of Trans.

Parameters Transptn Distance 623.128 1,032.892 521.917 12:27 20:39 10:26 Trsp. Duration – Resource

579.720 11:35

Table 3.16. Means of transport data for the unconstrained transportation lanes in the example supply chain model. The field names are spelled like in the SAP APO Source Destination Product Means of Transport Consumption S1 F1 X1 Car 4,000 kg X2 Truck – Table 3.17. Product-specific means of transport in the example supply chain model and transportation resource capacity consumption (only applicable for the transportation lane from S1 to F1 )

4 Optimization in SAP APO

In this chapter we use the supply chain model defined in Chap. 3 as a starting point for optimization-based SNP planning. The example model is first treated as a continuous problem (LP) and then as a MILP which is created by introducing lot size constraints. Together with Chap. 3, which deals with maintaining master data objects so that they form a supply chain model suitable for optimization, this chapter serves as a little cookbook for creating an optimization model in SAP APO. In the same way as it is not feasible to cover all aspects of mathematical optimization in one place it is beyond the scope of this book to give a complete description of all aspects of (MI)LP settings and modeling in SAP APO, some topics are just briefly mentioned, some might be missing. This shall encourage the interested reader with access to a SAP APO system to experiment and “try things out”. For a consolidated view onto our optimization problem we first give a recap of our supply chain model. This may also be used as a shortcut for the reader who postponed reading the model building chapter and who wants to see an optimization run in SAP APO right away.

4.1 Recap of the Supply Chain Model Our example problem models single-stage production with external sourcing decisions. In Chap. 3 we were looking at a company selling three main products, P1, P2, and P3 to three customers (or customer regions) C1, C2, and C3. Making the products requires two raw materials X1 and X2 that are sourced from two suppliers S1 and S2 delivering to the factory F1. In the factory there is one production resource R1 the capacity of which is shared by the production processes making the three end products. Figure 4.1, which is the same as Fig. 3.1 that we repeat here for clarity, depicts these relations. The products can be seen as high, medium, and low grade products selling at different prices. In the model the higher grade products consume more of the expensive raw material X1 and making them consumes more resource

80

4 Optimization in SAP APO

C1 S1 X1

X2

F1

R1

C2 P1

P2

P3

S2 X1

C3

Fig. 4.1. The structure of the simple supply chain example

capacity. On the other hand, failing to satisfy demand for the higher grade products or running late on the delivery results in a higher penalty than it is the case for the lower grade products. Also, the storage costs are accordingly higher in order to reflect more inventory fixed capital. The objective function of the example model is addressing stock level reduction, production resource utilization at the same time as fulfilling customer orders, and procuring the necessary components in an efficient way. Hence, the following costs are elements of the optimization model: • • • • • •

production, production capacity expansion (e.g., introducing another shift), procurement / sourcing, storage, penalty costs for late delivery, and penalty costs for non-delivery.

For a more detailed description of the example supply chain model structure and its constraints please refer to Sect. 3.1.

4.2 Optimizer Setup In Sect. 3.2 we described setting up a general SNP supply chain model having optimization-based planning in mind. Here we go into optimization-specific settings and parameters of the optimizer determining the optimization method

4.2 Optimizer Setup

81

and the constraints that are taken into account in the resulting (MI)LP. In SAP APO there is a number of profiles for this purpose, the optimization profile being one of them. In our example we create a new optimization profile which we explain in some detail and use default data for the other profiles.1 Nevertheless, we give an overview of these other profiles relevant for optimization-based SNP in the following sections. The profiles are accessible via the application menu as well as via SAP APO customizing. In the instructions below we access them via the application menu where possible. 4.2.1 The Optimization Profile This profile determines the optimization method and techniques to be used, some model parameters, and the type of constraints the optimizer shall take into account. In the SAP APO system the list of optimization profiles is reached via transaction Advanced Planning and Optimization → Supply Network Planning → Environment → Current Settings → Profiles → Define SNP Optimizer Profiles (S AP9 75000102). A click on the New Entries button lets us define a new profile which we name SIMPLE as suggested by Fig. 4.2.

c SAP AG Fig. 4.2. Adding a new optimization profile.


A click on Maintain Profile leads to the SNP Optimization Profile Maintenance screen. In the upper part it displays the profile name and description and allows selecting between Linear Optimization and Discrete Optimizatn. Selecting Linear Optimization causes the model to be interpreted as an LP and all discrete constraints are neglected. The biggest part of the screen displays parameters for the optimizer which are grouped by tabs. Figure 4.3 shows the contents of the fist tab General Constraints. In our example we activate the constraints Production Capacity and Transportation Capacity as shown in the figure. The remaining profile parameters remain at their standard settings. Leaving the optimization method switched to Linear Optimization neglects the integrality condition otherwise induced by setting the discretization indicator in the PPM (cf. Sect. 3.2.5.4). 1

Depending on the setup of your system you may have to create a time bucket profile for the planning run (see Sect. 4.2.7).

82

4 Optimization in SAP APO

c SAP AG Fig. 4.3. Optimization profile maintenance in SAP APO.


The individual tabs in the optimization profile allow adjusting parameters that determine the behavior of the optimization planning run such as the type of constraints to be considered, whether to use the primal or dual simplex algorithm, whether to use a maximum runtime for the optimization process, etc. The first tab is called General Constraints and its settings determine exactly what its name suggests and what is listed in Table 4.1. Discrete Constraints, the second tab, controls which discrete elements are included in the optimization model. The settings are only applicable if Discrete Optimizatn is activated (cf. Fig. 4.3), otherwise the model is an LP. Several types of discrete constraints can be set: • Capacity constraints: if activated, the capacity expansion of production resources can either be not used at all or used in full (cf. defining the capacity variants of our example resource R1 in Sect. 3.2.4). • Lot Sizes determines the relevance of minimum lot sizes and integrality conditions. Minimum lot sizes can occur in PPMs/PDSs and transportation lanes (via the SNP lot size profile for transportation lanes). Integrality can refer to PPMs/PDSs, transportation lots, and means of transport. In our example we use it for production of an integer multiple of the PPM

4.2 Optimizer Setup Section Capacity Constraints

Lot Sizes Safety Stock

Shelf Life

83

Comment Switch capacity constraints on and off: production, transportation, handling, storage, and maximum product specific quantity stored (from the location product master data) Consider maximum lot sizes given in PPM/PDS and/or transportation lane master data Safety stock restrictions can be ignored or penalized according to absolute or relative shortfall. Penalties can be per bucket or per day. There are three options on how to deal with expired product: (1) ignore shelf life, (2) continue to use expired product for a penalty, and (3) dispose of expired product. In (2) and (3) the penalty can be the location-product procurement cost or a fixed value that is not product-dependent and set in the profile

Table 4.1. Settings in the SNP optimizer profile – the General Constraints tab

base value and hence activate the Integral PPM constraint (therefore we also activated Discretization in the PPM master data in Sect. 3.2.5.4). • Fixed Consumptions deals with the optimizer taking into account fixed consumption of materials and resource capacities in the PPMs/PDSs. • Cost Functions:2 piecewise linear cost functions for PPM/PDS execution, means of transport (defined for the means of transport in the transportation lane master data), and procurement quantity of a location product can be considered by the model. • Cross-Period Lot Size – if activated – causes the optimizer to take into account setup activities in the previous time bucket if the same PPM is used for production in subsequent buckets (campaign planning). The resources assigned a fixed capacity consumption in the PPM must have the (Cross) Period Lot Size indicator set. All activated constraints in this tab are active for a certain time span. This time span can be given either by stating a specific horizon starting from the current date, or by stating a time bucket type for which the corresponding discrete constraint shall be valid. The available units for the horizon and the time bucket types are days, weeks, months, quarters, and years. Model Params, the third tab, deals with the valuation of stock and the availability of product within a time bucket. Inventory can be valuated at the 2

Note that one has to distinguish convex and concave cost functions. A convex cost function in the objective function of a minimization problem can be represented by the sum of several linear expressions with a piecewise linear approximation, a concave cost function in a piecewise linear approximation requires binary variables to force the pieces to enter the solution in the proper order. The number of binary variables is one less than the number of pieces.

84

4 Optimization in SAP APO

end of the time buckets or on an per-day basis. For determining whether a product that is produced or transported is available at the beginning of the current or at the start of the next time bucket, rounding limits for production and shipments can be adjusted. Solution Methds, the fourth tab, provides the following parameters: • •

•

• • •

•

Stop Criteria determine when to stop the calculation and are particularly useful for MILP problems. A maximum optimizer runtime and a maximum number of improvements (of the integer solution) can be specified. Decomposition allows an automated way of decomposing the problem into subproblems which are solved sequentially. Decomposition can be done by time, product, and resource. In the first case a window size in time buckets is specified. The second case requires a percentage of the products for each sub-problem and – optionally – a priority profile (cf. Sect. 4.2.5). This profile helps in segmenting the products which otherwise would be done via quantity and non-delivery penalty analysis. In the resource case a priority profile can be defined that helps in determining the model splitup which would be done via material flow analysis and other internal computations otherwise. Priority Decomposition provides a choice between prioritizing demands in the decision-making process in a cost-based or strict fashion. The former determines the priority of a demand via its penalty cost in the location product master, the latter assigns each demand a fixed priority depending on its category. The default values are priority 1 (the highest priority) for customer orders, 5 for the corrected demand forecast and 6 for the forecast. The safety stock priority can be set to 1, 5, or 6 in order to match the business requirements (6 is the default safety stock priority). Strict prioritization does not work with discrete optimization. First Solution determines whether the first solution in a mixed integer problem shall be sought by using heuristics instead of an LP method. LP Solution Procedure gives a choice between primal and dual Simplex and whether an interior point method shall be used. Aggregation allows planning on a location product group level (called vertical aggregation) and planning only a subset of the supply chain model defined by certain locations and products (called horizontal aggregation). In vertical aggregated planning location products are aggregated automatically into product groups before planning and disaggregated after the planning run. A prerequisite for this is a set of location, product, and production process model hierarchies that has to be maintained in the SAP APO system. Optimization Objective gives a choice between cost minimization and profit maximization. In the case of profit maximization the non-delivery penalty in the location product master is interpreted as the profit of selling the product rather than as the penalty suggested by the field name. This allows optimizing the contribution margin, for instance. Note that switching

4.2 Optimizer Setup

85

between cost minimization and profit maximization does not necessarily change the objective function but could also be implemented by interpreting the results in post-optimal analysis (cf. the related comment in Sect. 8.3.2). Integration, the fifth tab, deals with integrating the optimizer to certain SNP parameters, former planning runs, and PP/DS: • Horizons determines whether the SNP production horizon, SNP stock transfer horizon, and the forecast horizon are considered by the optimizer. The two SNP horizons define periods of time in that SNP does not plan production or stock transfers, respectively. They are used for organizing the coexistence and interoperability of medium-term planning (SNP) and short-term planning (PP/DS). The forecast horizon defines a period of time in that the forecast is not considered part of total demand. All three horizons are set in the location product master. • Incremental Optimization defines how to deal with results from previous planning runs. If the Do not delete any orders indicator is not set (see below) or if fixed orders exist the algorithm might run into infeasibilities if the existing orders are considered as hard constraints that need to be fulfilled. To influence this, demand originating from fixed (and existing) orders can be treated either as a hard constraint, a pseudo-hard constraint (i.e., “infinitely” large penalty cost), prioritized as a customer demand, corrected forecast, or forecast. This can be set separately for dependent demand (e.g., components) and distribution demand. Similarly, it may happen that a planning run is executed with reduced scope excluding certain location products. In this case, required input products (components) not existing in sufficient quantity as production process input or subject to transportation could cause infeasibilities. Therefore, stock of non-selected PPM/PDS input products and stock of non-selected source location products can either be ignored (i.e., not planned), regarded as pseudo-hard constraint, or regarded as hard constraint. • Setup Status Handling deals with integrating to PP/DS when production processes with setup operations are involved. If Cross-Period Lot Size is activated the optimizer can be configured to consider existing PP/DS orders with a matching PPM in the current or prior time bucket in order to determine whether setup operations are necessary for new SNP orders (production campaigns). If Cross-Period Lot Size is not activated the optimizer can be configured to consider matching PP/DS setup operations in the current time bucket. • Existing Orders: by default, all orders that are not fixed are deleted before planning is executed. Optionally, all orders from the previous run can be left intact by setting the Do not delete any orders indicator; existing orders are not changed by the planning run in that case.

86

4 Optimization in SAP APO

Extended Settings, the sixth tab, offers some settings on the behavior of the engine: • •

• • • •

Consistency Checks can be adjusted to the errors, errors and warnings, and all checks levels or omitted altogether. Time-Based Constraints switches time-based constraints on and off. These constraints can represent upper bounds for production quantity (at product PPM level), external procurement (on location product level), inventory (on location product level), and transportation quantity (on producttransportation lane level). The bounds are maintained in certain key figures in the standard SNP planning book 9ATSOPT (see Sect. 4.3.1 for general information on SNP planning books) along with the safety stock data. Upper Bounds for Stock set in the SNP planning book (we will not apply this, but SNP planning books are mentioned in Sect. 4.3.1) can optionally be treated as a soft (rather than pseudo-hard) constraint. Message Output of the consistency check can be limited. Log Data can be saved or discarded. Unsuccessful Solution Determination deals with the case the optimizer does not find a solution within the given maximum runtime. If no solution is found after the configured extended runtime the problem can be either ignored (the partial problem is ignored and the optimizer tries to find a solution for the whole problem), simplified, or the solution process is cancelled.

4.2.2 Scaling the Costs in the Master Data – the SNP Cost Profile and SNP Cost Maintenance For experimenting with the relations of the costs maintained in the model, the costs can be scaled in the SNP cost profile. It is reached via Advanced Planning and Optimization → Supply Network Planning → Environment → Current Settings → Profiles → Define SNP Cost Profiles (S AP9 75000101). Executing this transaction leads to a tabular maintenance screen of all cost profiles in the system. Figure 4.4 shows the DEFAULT cost profile with equal weights for all cost types in graphical format as it is reached from the optimization screen (cf. Sect. 4.3.2). The values entered are relative weights and are normalized by the system (i.e., they do not need to add up to 1.00). SAP does not recommend to use other profiles than one with uniformly distributed weights in order to avoid the cost structure deviating from the values entered in the master data. In this context we would also like to mention a single point of entry for accessing all optimization-related costs. Two transactions with different appearance, but same functionality are reached via transaction Advanced Planning and Optimization → Master Data → Supply Network Planning Master Data → Maintain Costs (Directory) (/SAPAPO/SNP113) and Advanced Planning

4.2 Optimizer Setup

87

c SAP AG Fig. 4.4. Weighting the SNP cost types.


and Optimization → Master Data → Supply Network Planning Master Data → Maintain Costs (Table) (/SAPAPO/CSNP), respectively. Both can be conveniently used for avoiding many master data screens when it comes to quick changes of costs in the model. As an example, Fig. 4.5 shows the planning version-dependent penalty costs for product P2 at customer C1 in the transaction /SAPAPO/SNP113; cf. the same costs in the location product master data in Fig. 3.9 on p. 58. 4.2.3 Working Towards Steady Results – the SNP Optimization Bound Profile In some cases there is the business objective to increase the stability of the results from one SNP planning run to the next. This can be accomplished by including additional constraints in the model restricting the deviations of the decision variables from their values after a prior optimization run. The SNP optimization bound profile – if specified when executing the planning run – defines these permitted deviations as percentages above/below the values of a prior optimization result, which is not limited to the one originating from the immediately preceding run.3 Deviations can be time-dependent; e.g., 3

In case the reference value is zero the base value for the calculated deviation can be set to the minuimum, the maximum, or the average of the non-zero values across all time buckets.

88

4 Optimization in SAP APO

c SAP AG Fig. 4.5. Central optimizer cost maintenance.


allowed deviations can be smaller in the beginning of the planning horizon and can get bigger or unconstrained towards the future to reduce last-minute plan changes. The SNP optimization bound profile is maintained in the transaction Advanced Planning and Optimization → Supply Network Planning → Environment → Current Settings → Profiles → Define SNP Optimization Bound Profiles (S AP9 75000249). 4.2.4 Lot Sizes for Shipments – the SNP Lot Size Profile If shipments are subject to lot size constraints, this profile will have to be specified in the Lot Size Profile field in the product-specific means of transportation in the transportation lane master data (cf. Fig. 3.31 on p. 76). The SNP lot size profiles are created and maintained in the transaction Advanced Planning and Optimization → Supply Network Planning → Environment → Current Settings → Profiles → Define SNP Lot Size Profiles (Transportation Lanes) (S AP9 75000095). Possible entries are minimum and maximum lot sizes for the shipment as well as rounding values in case shipments are restricted to integer multiples of a certain lot size. Naturally, discrete optimization has to be chosen in the SNP optimization profile in case the minimum lot size or lot size integrality constraints are to be used in the model.

4.2 Optimizer Setup

89

4.2.5 Decomposition Methods and the SNP Priority Profile Decomposition is the method in SAP APO to deal with large problems that would take excessive amounts of memory and/or processing time to solve. If activated in the optimization profile (cf. Sect. 4.2.1), the (MI)LP will be subdivided – decomposed – into several sub-problems that are solved sequentially. There are three decomposition methods in SAP APO: time, product, and resource decomposition. The SNP priority profiles help in decomposing by product and resource.

c SAP AG Fig. 4.6. An example priority profile.


The transaction Advanced Planning and Optimization → Supply Network Planning → Environment → Current Settings → Profiles → Define SNP Priority Profiles (/SAPAPO/OPT PRIOPROF) is the entry to maintaining priority profiles for product and resource decomposition. Figure 4.6 shows an example profile that assigns product P1 priority one and both products P2 and P3 priority two as a suggestion for product decomposition. In our example optimization runs later on we will not use decomposition. 4.2.6 Settings in SAP APO Customizing – the SNP Planning and Parallel Processing Profiles There are two profiles relevant to optimization that are accessible via SAP APO customizing only: the SNP planning profile and the parallel processing profile. They hold settings of global SNP planning procedures and of dividing background jobs into parallel processes, respectively. The SNP planning profile defines over 30 parameters determining global SNP settings and the behavior of the planning procedures, such as considering

90

4 Optimization in SAP APO

the goods receipt processing time defined in the location product master data or details of planned order integration with mySAP ERP. Describing them all would go beyond the scope of this section, but we think it is worthwhile to mention the impact of two of them as it may help debugging a model that does not behave as expected: • Opt.: Transp. Lot Sz determines whether lot size information for transportation lanes is taken from the SNP lot size profile specified in the transportation lane master data or additionally from the location product master data. In the latter case certain rules of precedence exist in case lot sizes are maintained for both the transportation lane and location product. • Opt.: Lot Formtn determines the creation of orders depending on lot size data maintained for the location product and the PPM: production quantities are either (1) split into multiple planned orders representing a fixed lot size or maximum lot size or (2) converted into one planned order representing the whole quantity ignoring the mentioned lot size settings. One field in the SNP planning profile links to the parallel processing profile which defines how background jobs are organized and distributed among the available hardware resources. The parallel processing settings are defined by SNP sub-module and hence contain an optimizer-specific setting. This is why we mention the parallel processing profile here. SAP APO customizing is accessed via Tools → Customizing → IMG → Execute Project (SPRO) and clicking the SAP Reference IMG button on the upper part of the screen. The SNP planning profile is then accessed via mySAP SCM - Implementation Guide → Advanced Planning and Optimization → Supply Chain Planning → Supply Network Planning (SNP) → Basic Settings → Maintain Global SNP Settings and the parallel processing profile is accessed via mySAP SCM - Implementation Guide → Advanced Planning and Optimization → Supply Chain Planning → Supply Network Planning (SNP) → Profiles → Define Parallel Processing Profile, respectively. For executing a customizing activity, click the green check mark next to the menu entry. 4.2.7 The Time Bucket Profile Last not least, the time bucket profile defines the number and length of the time buckets in scope for SNP. Often a higher level of detail is desired at the beginning of the planning horizon, which results in time buckets being shorter in the beginning and getting longer towards the end. For example, we may use seven daily, three weekly, five monthly, two quarterly, and two yearly buckets to represent a planning horizon of three years. In our example we will use a planning horizon of half a year, all in weekly time buckets. Figure 4.7 shows how a time bucket profile such as the one we

4.3 The Planning Run

91

c SAP AG Fig. 4.7. An example time bucket profile.


use for our example is defined. It spans a period of 26 weeks (first line of the table) which is subdivided into weekly time buckets (second line of the table). By pressing the Period list button all time buckets in the profile can be displayed in tabular form for checking the definition. The associated SAP APO transaction is Advanced Planning and Optimization → Supply Network Planning → Environment → Current Settings → Maintain Time Buckets Profile for Demand Plng and Supply (/SAPAPO/TR30).

4.3 The Planning Run Now, after defining the supply chain model in the SAP APO master data and the optimization parameters in the various profiles, we are ready to perform an SNP optimization planning run. In order to execute this optimization planning run in an instructive way we make use of the planning book concept of SAP APO which is not optimizationspecific. For didactic reasons, however, we will give a short introduction into planning books here rather than in the more general sections of Chap. 3. 4.3.1 SNP Planning Books Planning books in SAP APO provide an overview of the demands, supplies, stocks, etc. in the supply chain. They are used in both DP and SNP and show primarily transaction data in a spreadsheet-like layout. As it is well outside the scope of this book to explain all issues relevant to the planning book in detail we refer to the SAP APO on-line documentation on the internet4 and to Dickersbach (2004, [17]). For our purposes it is sufficient to use the standard SNP planning book with one view on the displayed data and give an extremely abbreviated introduction into how to use it here. However, we once more explicitly encourage the reader to explore the SAP APO system 4

http://help.sap.com/ Documentation → mySAP Business Suite → SAP Supply Chain Management

92

4 Optimization in SAP APO

aside from the path of this cookbook-like example. We will exploit only an extremely small portion of the capabilities and flexibility of the SNP planning books. The planning book is invoked via Advanced Planning and Optimization → Supply Network Planning → Planning → Interactive Supply Network Planning (/SAPAPO/SNP94). At first it shows an empty spreadsheet on the right side of the screen and four sub-windows (so-called selectors) on the left hand side. The rows of the spreadsheet are called key figures in SAP APO. In order to fill it with data like shown in Fig. 4.8 we first select a data view of the pre-set standard SNP planning book 9ASNP94. For minimized setup effort we select the standard view SNP94(1) SNP PLAN by double-clicking on its name.

Fig. 4.8. The SNP planning book setup for the example case (see text for details). c SAP AG


By clicking the Selection window icon the data context is chosen. We select all location products in the planning version SIMPLE as Fig. 4.9 shows it. In the selection window the selection can be saved so that next time it is available under the pencil icon in the Selection profile selector window on the left. In case the planning version is not initialized a pop-up window offers to initialize it (please do so in that case). The data is then loaded into the spreadsheet by selecting all location products (by holding down shift or ctrl or by clicking the Select all button) and then clicking the Load data icon. Because we want to plan in weekly time buck-

4.3 The Planning Run

93

c SAP AG Fig. 4.9. Selecting all location products of planning version SIMPLE.


ets we select the Period Structure Settings button and select a time buckets profile with weekly buckets.5 At last the aggregate/disaggregate features have to be enabled in the planning book. This is done by displaying the header data (button Header On/Off ) and then selecting APO Location and APO Product as the characteristics for drilling up and down (button Header Information Settings). In the same row as the header button are buttons for expanding the data view by switching the selector windows on and off and the “pencil” button that toggles between display and change mode. The optimizer can only be started when the planning book is in change mode. 4.3.2 Continuous Variant of the Model We start from a situation mid-year with zero initial stock and five demand forecast elements as given in Table 4.2. For an easier display of the results we execute the planning with weekly time buckets. Demand date Demand week Product Customer Quantity [pieces] Aug 15 33 P1 C2 15,000 Aug 15 33 P2 C2 18,000 Sep 1 35 P2 C1 5,000 Sep 1 35 P3 C3 10,000 Oct 1 39 P1 C1 10,000 Table 4.2. Demand forecast in the supply chain example

In the SNP planning book – in order to limit setup effort for the SNP application we use the standard planning book 9ASNP94 and change the time bucket profile to a weekly one like briefly explained above – the situation looks like displayed in Fig. 4.10. In order to fit more data on the screen we switched off the selector windows (via the leftmost button next to the pencil button on top). Note that in this figure all demands for all locations are aggregated. We also observe that there are multiple demand categories (such as Forecast 5

In most cases such a profile will already exist in the system. If not, see Sect. 4.2.7 for a brief description of time bucket profile maintenance.

94

4 Optimization in SAP APO

Fig. 4.10. The example demand pattern in the SNP planning book. The total demands for all products and locations in the supply chain model are displayed. c SAP AG


and Sales Order ) and that they are summed up in the expanded Total Demand key figure. There are no receipts so far in the empty Total Receipts line that could be expanded to show the different receipt key figures via a double-click. The Supply Shortage increases with each added demand item. To get a better overview the planning book offers disaggregation and aggregation functionality as demonstrated in Fig. 4.11 where we restrict the display to quantities relevant to the customer C1 and disaggregate the quantities by product reflecting the appropriate demands in Table 4.2.

Fig. 4.11. The example demand pattern in the SNP planning book. Only demands for customer C1 – APO Location: C1 – are selected and disaggregated by product c SAP AG – APO Product: Details (all).


4.3 The Planning Run

95

Clicking on the Optimizer button in the planning book leads to the rather empty-looking optimization screen in Fig. 4.12.6 This screen is the entry to starting the optimization run, input and output log file analysis and inspection and changing of the optimizer profiles. Underneath the fields for selecting the optimization, cost, and optimization bound profiles there are six buttons: • • • •

Start optimization run starts the optimization run (well...), Optimization Log File displays the log files from recent optimization runs, Optimization Profile, Cost Profile, and Optimization Bound Profile open the respective profiles for editing, and Selected products displays a list of location products in scope for the optimization run, sorted by location.

c SAP AG Fig. 4.12. The optimization entry screen in interactive SNP.


After starting the optimization run on this screen a series of status messages appears informing the user of the progress in three steps along with date and time information. In the first step master and transaction data is read for building the model formulation. In our case we get the message that we have 5 products, 6 locations, 17 location products, 12 transportation lanes, 3 PPMs and 5 demands. The next step is a consistency check of the model along with the solution process which – in our case – ends with announcing the finding of the optimal solution and the end of calculations. In the third 6

The planning book has to be in edit mode for that; if an error message occurs a click on the little pencil icon on the top part of the screen activates the edit mode before entering the optimization screen.

96

4 Optimization in SAP APO

step the optimization result is written back into the SAP APO application data structures as planned production orders, stock transfers, etc. In our case it results into creating 30 stock transfers, 25 purchase requisitions, and 9 planned orders. More information on these messages, in particular if they are warnings, is accessible in the Message Log tab on the optimization screen. The system presents a view like Fig. 4.13 to the user after the optimization run has finished. At the first glance a cost distribution gives an idea whether

c SAP AG Fig. 4.13. Cost overview after a successful optimization run.


the result is plausible, especially when the calculations are re-done after some fine-tuning the model or when the input data have changed. A comprehensive overview of what data actually went into the model, the raw results from the optimization run, and technical logs are available in the optimization log files which are kept for a configurable time span after the planning run was executed. They can be viewed in SAP APO or downloaded to the client machine in text format. Figures 4.14 and 4.15 show examples of an input and an output log from our supply chain model. From outside the optimization entry screen in interactive SNP the log files are accessible via the transaction Advanced Planning and Optimization → Supply Network Planning → Reporting → Optimizer Log Data (/SAPAPO/SNPOPLOG). In the output log displaying the planned orders suggested by the optimizer one effect of LP optimization is well visible: the suggested production quantities are not necessarily integral, but rational numbers according to the balancing of costs performed by the algorithm.

4.3 The Planning Run

97

Fig. 4.14. The optimizer input log: transportation resource availability in the exc SAP AG ample supply chain.


c SAP AG Fig. 4.15. The optimizer result log: created planned orders by PPM.


Another way of evaluating the optimizer result, and this is the way the production planner would usually go, is in the SNP planning book. Figure 4.16 shows the resulting data for location F1 broken down by product. For the demand in week 33 the optimal solution starts building up inventory of the components in week 29 and starts producing finished goods in week 30. By this means the solution respects the capacity constraints and avoids late demand penalties.

98

4 Optimization in SAP APO

Fig. 4.16. The optimizer result in the SNP planning book: stock balancing at the c SAP AG factory F1.


4.3.3 Discrete Variant of the Model In Fig. 4.15 the suggested order quantities are far from being “round” in the sense of integral multiples of the PPM reference quantity of 1000 pieces. Looking at the suggested stock transfers from the suppliers to the factory we would see even fractional numbers because there is no mechanism that favors integer quantities in the continuous case. In order to clean this situation up we introduce integrality constraints for the PPMs. Hence, the optimizer creates orders with quantities that are integer-multiples of the reference output value of 1000 pieces P1, P2, and P3. For including these constraints the optimization profile has to allow discrete optimization and activate the desired integrality restrictions. Figure 4.17 shows a part of the different integer constraint types and a choice of validity periods that can be defined for each type. If, for example, planning takes place in weekly time buckets followed by monthly and quarterly ones it may be desirable to consider discrete constraints only for the weekly buckets in the nearer future in order to increase the overall planning performance. Actually executing the planning run in our case leads to a quick solution of the very simple MILP – the second integer solution is optimal already. The initial conditions are the same as in the continuous case: no orders consist in the supply chain apart from the demand forecast given in Table 4.2. As expected the overall costs of 12,801,500.00 are slightly higher than the costs of 12,796,333.33 in the relaxed case, but still without any late demand penalties (see Fig. 4.13 compared to Fig. 4.18). Production and procurement costs stay

4.3 The Planning Run

99

Fig. 4.17. The optimization profile activates discrete optimization and the Integral c SAP AG PPMs/PDS constraint is active for the first 26 weeks of planning.


c SAP AG Fig. 4.18. Cost overview after the MILP run.


the same since they do not depend on lot sizes and because the demand happens to be an integer multiple of the production lot sizes so that the integrality conditions do not force any excess production. Production capacity expansion (overtime) and storage costs however are increasing in the discrete case. From comparing the suggested production quantities in the two cases in Figs. 4.15 and 4.19 we observe a tendency to produce earlier and in more production runs balancing storage, overtime, and late delivery costs.

100

4 Optimization in SAP APO

c SAP AG Fig. 4.19. Planned orders in the discrete case.


4.4 Some Observations From what we described in this first part of the book it should be obvious that the mathematical and the “business software” approaches differ significantly. Model building in particular is a completely different process in the two domains, but also the approach to optimization is not the same. 4.4.1 A Mathematician’s View The mathematician – including Operations Research professionals with appropriate optimization-related training – will translate reality into equations representing and including all elements relevant for solving the decision-making problem. A prerequisite is understanding what the problem actually is, a prerequisite with professional and social aspects. Talking to business people the mathematician will very often be challenged with barriers resulting from a lacking common language and a different kind of analytic thinking.7 Once the barriers are overcome and appropriate knowledge and information transfer has started, the mathematician will start formulating the model.8 This formulation will be custom tailored to the particular problem and will respect all business objects and constraints deemed to be of relevance for making the right business decision. Often simplifications and assumptions 7

8

A part of Operations Research (OR) is dealing with bridging those gaps in understanding by educating people in applied optimization. Having an OR background can help in this phase, but care must be taken not to focus on software more than on understanding the underlying mathematics. It is very important to mention here that the interaction between the individuals formulating the optimization model and the client does not stop here and recommences when the application is delivered. In fact, constant communication on model details and reality checks are essential for a successful project.

4.4 Some Observations

101

about reality need to be made due to model building or performance restrictions. For example, it might be tolerable in certain cases to model non-linear relationships in a linear model approximately resembling reality. In other cases where a MILP is the appropriate modeling approach it might be tolerable to lift integer constraints that lie outside a certain time horizon because lot size restrictions are not that critical for planned production further ahead than, say, six months. Of course these simplifications have to be applied very cautiously and it needs quite some experience in optimization and mathematical modeling to come up with an efficient and usable result. Given one or more existing IT systems the client uses, the model is subsequently implemented and – in principle – ready to be used by the client. Depending on the development framework of the optimization application some sort of user interface has either to be built or adapted. One of the biggest challenges in implementing such an application is interfacing it with all involved business software systems and getting the right data out of them for the optimization process and back into them after the process. Chap. 9 will deal with such cases, where SAP APO itself is treated as a “legacy system” and own optimization applications are integrated into a planning process involving SAP APO business processes and other optimizers. 4.4.2 The Standard Business Software View When it comes to optimization, standard business software products such as SAP APO do not offer LP or MILP modeling per se on an equation level, but provide a standard MILP formulation suitable for a wide variety of real-world problems that is configured by manipulating data objects in the business application. Hardly anywhere terms such as variable or constraint can be found, the model parameters are set by defining supply chain-related objects such as products, locations, transportation lanes, lot sizes, resource capacities, etc. Formulating the model becomes more a task of setting up these master data elements and selecting which are to be considered by the optimization run. Because of the master data concept originating from ERP systems parameters for the planning algorithm are often scattered throughout the master data screens in the system (as an example of how to improve this it is worthwhile to mention the central cost maintenence for the SNP optimizer shown in Fig. 4.5). Additionally, there usually are profile screens for the planning algorithm containing optimization-specific data and settings that do not fit in the ERP master data concept. After appropriate customer demands or demand forecasts are created the optimization can be started. The results are typically visible in the standard software tool’s user interface immediately after the optimization run has finished, e.g., as planned production orders that are covering the demand. At the same time the data is ready to be processed further (converting into actual

102

4 Optimization in SAP APO

purchase or production orders, for instance). At the first glance there is no need for actually understanding the applied optimization algorithm any more. But how to interpret the quality of the calculated plan and how to know whether the right algorithm was selected for solving the problem? Typically systems like SAP APO offer several algorithms for solving supply chain problems, optimization being one of them. Depending on the individual business objectives an algorithm such as a simple heuristic method may be sufficient for a client with a very simple supply chain structure who is looking at mathematical algorithms suspiciously. Domain expertise in mathematical modeling including optimization is necessary for choosing the right algorithm, explaining the appropriate method to the client and to create trust in the planning system as a whole. Without understanding (at least the basics of) optimization it may be very difficult to understand and correctly interpret the results of an optimization run. Many supply chain projects are delayed and/or seriously jeopardized at a late stage when the first production plans are presented to the planners. The APS software itself might help by providing a built-in explanation tool which helps in the interpretation. This is unique to APS because fine-tuning such a tool depends on a standard model and would not be practical with tailored mathematical formulations. Again it is trust in the planning system that needs to be built and this does not work when there are open questions and no one on the project team can adequately explain the behavior of the planning algorithm.9 These two examples underline the need for individuals experienced in optimization accompanying implementation projects of APS software whenever planning algorithms are used (and this is the prime reason to deploy an APS). On the bright side, APS provide – depending on the vendor – a more or less sophisticated methodology for interfacing with ERP systems. Some are so tightly integrated that part of the model can be built automatically based on data transferred from ERP; SAP APO and its integration with mySAP ERP is an example for this. The first steps of building an optimization appliction is very easy then as no thoughts need to be spent on mathematical basics such as appropriately defining variables and data mappings between the ERP software and the planning engine (keeping in mind that interpreting the results later on needs quite some optimization knowledge). Additionally, the standard model built in an APS makes supporting the application much easier than in an environment where specialized optimization consultants (in-house or external) implement a solution and no care is taken of continued support.

9

As no vendor of APS known to the authors reveals the actual mathematical optimization model formulation, explanations of issues concerning the planning algorithm are limited to the product documentation and optimization theory.

Part II

Detailed Case-Studies

5 Planning in Semiconductor Manufacturing

Semiconductor manufacturing is a rather complex process in the high-tech industry. In order to understand the typical business challenges it is vital to have a look at how the actual transformation of raw silicon into microchips is performed. This is valid even for supply chain planning at an aggregate level (such as master planning). Due to the nature of the semiconductor industry advanced planning methods play an important role: the production equipment is very expensive, lifecycles of the products are very short, and customer demand varies very quickly compared to the production lead times. This is why the majority of the leading semiconductor manufacturers use one or the other kind of optimization and/or constraint propagation algorithms for planning; sometimes a customdeveloped application based on optimization engines such as ILOG’s CPLEX is R used, sometimes APS such as SAP APO or i2
are deployed. Because of confidentiality issues in the industry we do not describe a specific SAP customer case where the SNP optimizer is used, but explain the key business drivers in the semiconductor business and give an example of a successful SAP APO implementation using the constraint propagation-based CTM algorithm.

5.1 Semiconductor Manufacturing Figure 5.1 states the four phases characteristic for manufacturing semiconductor devices from a raw silicon wafer together with depicting the schematic input and output products of each step. Here we do not discuss producing wafers from raw silicon, a crystal-growing and slicing process, but look into how a microchip is made starting from a silicon wafer. The four steps we are looking at are called fabrication (or short fab), sort (also called probe), assembly, and (final) test. After going through these steps a silicon wafer is transformed into a number of semiconductor microchips ready to go to the (end) customer for being built into electronic devices.

106

5 Planning in Semiconductor Manufacturing

Wafer Fabrication

Wafer Sort

Front-end

Assembly

Test

Back-end

Fig. 5.1. A schematic view of the semiconductor production process. See text for a description of the steps

Often the four steps are grouped into the front-end and back-end processes consisting of fab and sort (front-end) and assembly and test (back-end), respectively. In the following we will very briefly characterize the four principal steps of semiconductor production sufficient for the subsequent discussion of the planning processes in our case study. Solid state physicists and experts in semiconductor manufacturing may excuse our superficial explanations. 5.1.1 The Manufacturing Process Wafer fabrication (or short fab) starts with a raw silicon wafer on which it creates a pattern of integrated circuits while going through a series of up to several thousand production activities taking up to several weeks total processing time, depending on the complexity of the microchip to be produced. Operations performed on the wafer include modifying the surface by adding layers of new material or diffusing ions into the surface, etching patterns into a layer, implanting ions, photo lithography, etc. At a German chip manufacturer, for instance, fabrication of memory and logic chips can be seen as a two-stage process for master planning purposes: gate which takes about 30 days of “silicon work” (etch, photo, implant) and metal which takes about 10 days of “wiring” (deposit, etch, photo, clean). In principle fabrication happens on few different pieces of equipment, but the wafer visits each of them multiple times during the fab step. Today most waferfab facilities use wafers 200 mm or 300 mm in diameter holding a range from about a dozen to several hundreds of chips each, depending on chip size and complexity as well as on wafer diameter. The wafer sort process tests the individual chips on the fabbed wafers (also called die) and determines the so-called die bank, the inventory in terms of good die and source of shipments to assembly or directly to customers. The

5.1 Semiconductor Manufacturing

107

tests themselves are conducted by connecting to the contacts of the die on the wafer and performing electrical tests. Results from these tests are used to continually improve the fab yield of good die by evaluating patterns of malfunctioning chips on the wafer and other process parameters. Optional production steps in the sort process include backgrinding to reduce wafer thickness and power consumption and applying gold to the back of the wafer for better package adhesion. During the assembly process the wafer is cut up into the die. The good die are then attached to a package base, lead wires are bonded to the die and the lead frame and finally the package is sealed with a lid. The last step in our mini-description of semiconductor manufacturing is the final test process which consists of the last quality control before a chip is actually shipped to the customer: During the burn in the device is put under working conditions for a while; this is because most of the malfunctions of a semiconductor device will happen during the first minutes of its operation and become obvious in this electrical test. Depending on the purpose of the specific device a series of additional tests are performed, e.g., environmental tests (hot/cold/room temperature), binning for grading and failure analysis, mechanical tests for bent leads, etc. The last operations are marking, packing, and shipping of the chip. 5.1.2 Semiconductor Business Challenges ”This [the semiconductor] industry is fundamentally unstable – it is driven by deterministic chaos” – said an executive of a large semiconductor manufacturer.1 He referred to the effects of large lead times on the one hand (the fab process can take many weeks) and high market volatility on the other hand. To complicate the market behavior, technological advances happen very fast and at the same time cyclic market up- and downturns are a characteristic of the semiconductor market since its formation after the Second World War. Avoiding the negative side effects of these up- and downturns by moving the business to other regions in the world is no option because the semiconductor business operates globally. Partly this is because of transportation cost being not significant compared to the value of the goods. So it is common practice to have the front-end processes and in many instances the test process at the company headquarters (e.g., in Europe or the US) and the assembly outsourced to low-wage countries in the Far East. The sorted wafers and assembled chips are then transported via air freight to minimize delays and lead times. Moore’s Law predicts doubling the complexity on an integrated circuit of a given size every year (Moore, 1965, [71]). Even though the time scale of this 1

For phycicists this statement on chaoticity is no surprise, of course. Any dynamic system with more than two degrees of freedom can show chaotic behavior...

108

5 Planning in Semiconductor Manufacturing

“law” has been changed since the 1970’s, exponential advance in semiconductor technology is still observed, which translates into accordingly high market velocity. Consequently, proper inventory management is one key factor for success in the semiconductor market. The effects of rapidly advancing technology cause goods in inventory to depreciate very fast, which may lead to considerable losses in case of a steep market downturn. Too little inventory of the right product, on the other hand, can cause significant losses in terms of opportunity costs if high customer demand cannot be satisfied due to the long manufacturing lead times of up to one quarter. Finally, the vast majority of fixed assets is the very expensive front-end equipment which translates into high costs for wasted capacity (e.g., idling, making the wrong product) in fab and sort. As a consequence, maximized front-end capacity utilization is an important constraint in semiconductor planning. Again, the striking imbalance in the processing times of the four steps described above have to be taken into account: fabrication takes up to many weeks, all the remaining steps have cycle times in the range of some days.

5.2 Supply Chain Business Practices Covering the SCOR source-make-deliver chain along with its plan process, we can categorize SCM functionality into five main areas: demand management, capacity planning, master planning, production planning, and order fulfillment. Obviously, these five processes are tightly integrated with each other and hence cannot be seen as completely independent. On the other hand, typical software and/or algorithmic functionality required for covering the processes with an IT system varies. Several successful implementations of SAP in the semiconductor industry (cf. http://www.sap.com/) suggest that SAP meets the planning requirements for the industry on the whole. While demand management (including demand planning) and order fulfillment are dominated by functionality like statistical forecasting, general transaction processing like data exchange with other in-house and external IT systems, and implementing business rules of transactional nature, the remaining areas provide room for optimization. Capacity planning and master planning are addressed by SAP APO Supply Network Planning (SNP) and production planning by Production Planning and Detailed Scheduling (PP/DS). Following the focus of this book, we set the PP/DS part aside and concentrate on SNP applications for semiconductor dealing with typical processes and business objectives in mid-term planning. In this chapter we discuss not only optimization, but also the CTM (Capable-to-Match) planning algorithm due to its origin: originally CTM was developed for planning at semiconductor manufacturers in the late 1990’s and has successfully been enhanced for general use ever since.

5.2 Supply Chain Business Practices

109

The following sections give an overview of mid-term planning processes often encountered at large semiconductor manufacturers. As a complete description of supply chain practices in the semiconductor business would easily fill a book on its own we will only briefly discuss the according issues listing the key planning requirements in the industry. We call the processes capacity planning and master planning; depending on the semiconductor manufacturer their naming may vary. After that we will state some aspects to keep in mind when modeling a semiconductor supply chain and impacts on modeling in SAP APO. 5.2.1 Semiconductor Capacity and Master Planning Based on demand forecast data, the first step in mid-term planning is typically capacity requirements planning which starts with an assembled demand forecast2 followed by a rough-cut capacity plan resulting in a production target for the individual business lines of the semiconductor company. Capacity planning is based on models containing the relevant and current supply chain constraints, probably on a somewhat aggregated level. Even though capacity planning is technically very similar to master planning and sometimes is based on the same supply chain model, it is usually kept separate due to (political and organizational) business reasons. The result of the capacity planning run is the assignment of shared (fab) production capacity among the business lines. This happens on a strategic level, driven by demand, current fabrication load, and business rules such as customer or product group priorities. Typically, global capacity planning is run every week and the planning horizon is 18 months with decreasing granularity in time – starting with daily time buckets, followed by weekly, monthly, and quarterly ones, for instance. Very similar to capacity planning, the objective of semiconductor master planning is to find the best match between supply and demand. The driving factor is again the customer demand, the limiting factor the constraints that exist in the supply chain. Master planning is usually run on the business line level using the capacities allocated before. A typical planning horizon is again 18 months, but in contrast to capacity planning master planning is generally run daily to achieve an appropriate response time in customer order confirmation (Available-to-Promise, ATP). In case not all demands can be fulfilled in time there is a set of business preference rules. The highest priority business rule is based on demand and customer. A possible ranking of customers might be partner → strategic account → key account → first-come-first-serve, for example. Similarly, there is a product or product group ranking. Confirmed orders always have the highest priority over forecast with the exception of some customer programs. 2

We assume that the demand forecast is assembled taking into account the input from all relevant stakeholders such as sales, marketing, etc.

110

5 Planning in Semiconductor Manufacturing

There are also manufacturing business rules based on inventory policies, sourcing strategies, and resource utilization. Such a rule might translate into a soft constraint that balances the resource load across all fab facilities, for instance. The tasks of master planning are dealing with customer order confirmation, manage inventory stock targets, and releasing orders to the supply chain. These planned orders are production (or work) orders to manufacturing for each production stage and transfer orders for material transportation between locations. Master planning is typically concluded by a review by the planner and probably some manual plan changes. When the planner is satisfied, the plan is published and released. 5.2.2 Semiconductor Supply Chain Modeling A semiconductor supply chain model is a series of operations from fab to final test separated by inventory points and move operations between facilities, and limited by constraints. Inventory buffers consist of raw wafer inventory, die bank, and finished goods. The supply chain constraints consist of capacities, lead times, work-in-process inventory, and inventory points. The inventory and decoupling points within the semiconductor supply chain are: material stock, metal bank, die bank, and finished products. Material stock is the raw wafers purchased from wafer suppliers. Wafers are sliced from ingots, cleaned, polished and sent to fabrication sites for wafer processing. Metal bank is inventory of wafers that have gone through a certain number of masking steps, and die bank is an inventory control point of finished wafers ready for dicing and packaging. Finished products are built from either metal bank or die bank. The three typical supply chain strategies for semiconductor include buildto-order, assemble-to-order, and make-to-forecast depending on which inventory point the orders draw the associated material. While build-to-order demands include fabrication operations consuming supply from the metal bank, assemble-to-order demands use up inventory at the die bank level. Often, some products operate within all three models. For example, the assemble-to-order strategy for most customer orders draws material from die bank, while specific customer programs will follow make-to-forecast. A gate for manufacturing is set based on customer/product combination. This gate is a point in time that decouples the customer and the order. Prior to this point, manufacturing is making to forecast, after this point it is maketo-order. A forecast later than this point is expired due to insufficient time to manufacture determined by the manufacturing lead time. Raw material procurement, metal bank, and die stock inventory levels are planning driven, while production to customer programs, finished goods regional stock, assemble-to-order from die stock, production from metal bank to order, and pure make-to-order are order driven activities.

5.2 Supply Chain Business Practices

111

The flow of goods through the supply chain is controlled by several entities. Waferfabs control the flow of goods from raw wafers to die bank, and the backend sites control the goods from die bank through the assembly and test steps to the finished goods warehouse. Warehousing and distribution controls the delivery of goods to regional distribution centers, to just-in-time (JIT) stores, vendor managed inventory (VMI) sites, and delivery to customers. Globalization is a one-face to the customer initiative consisting of better managing global accounts, global forecasting, order entry, product distribution, and customer service. Reduction in customer order cycle time is accomplished through daily order release to manufacturing centers, direct shipment from back-end sites, and quickly reacting to changes in demand by running demand and capacity planning more often. Forward integration focuses on customers throughout the supply chain by extending the supply chain control points to include JIT deliveries, VMI programs, and expand the utilization of EDI and E-Commerce. Integrated supply chain modeling and planning has to reflect this global structure. Separating the planning and order driven key processes in the supply chain results in separating supply chain management and manufacturing control: Waferfabs deliver to die bank, and back-end sites deliver to customer orders. In other words, we have to deal with planning driven activities up to die bank (push), and demand-pull from die bank for customer orders. 5.2.3 Semiconductor Supply Chain Planning and SAP APO Supply Network Planning in SAP APO allows modeling the key supply chain planning requirements of semiconductor manufacturers as they are discussed in the preceding sections. The presence of complex business rules in planning requires advanced planning algorithms such as optimization and constraint propagation; a simple heuristics-based method like the one described in Sect. 1.4.1 is not sufficient. Below we describe the Capable-to-Match (CTM) constraint propagation algorithm that was originally developed for the semiconductor industry and aspects of how the SNP optimizer satisfies the planning requirements. 5.2.3.1 Capable-to-Match for Semiconductor During the semiconductor market upturn in the late 1990’s, the CTM algorithm was originally developed for semiconductor manufacturers. The objective was to implement the typical semiconductor business rules in a market environment that is characterized by demand exceeding supply, which at that time automatically provided for fully utilized fab capacities. Therefore, focus was laid on implementing demand prioritization rules rather than looking at maximized waferfab utilization at the same time. In CTM, demands are put in a sequence based on their priorities and the algorithm matches the demand elements with available supply (material

112

5 Planning in Semiconductor Manufacturing

and capacity) according to this sequence using constraint propagation (cf. Sect. 1.4.2). Demand priorities can be chosen almost arbitrarily, popular examples are prioritization according to order date, product groups, customers, etc. Whenever the algorithm has to choose between sourcing alternatives preset priorities and quotas are used. These priorities and quotas are defined on the transportation lane and production process model level. CTM considers limited production capacities, transportation capabilities between locations, safety stock levels based on absolute quantities or target days of supply, and deals with time-dependent process parameters in order to respect yield learning curves essential in semiconductor manufacturing. Transportation capacity restrictions are not included in CTM planning as this is not seen as an important constraint in semiconductor planning. CTM planning always results in a feasible plan in terms of capacity and material restrictions. Different planning strategies help CTM in fulfilling constraints such as high fab utilization. Using forward scheduling (instead of backward scheduling) in conjunction with early demand fulfillment set at an appropriate value will plan fab operations as early as possible to ensure fab capacity is utilized. Unwanted inventory points between processes (PPMs/PDSs) are modeled by defining a maximum pegging length for the two adjacent processes: e.g., zero stock of unsorted wafers is modeled such that the sort process has to begin immediately after the fab process is finished by setting the maximum pegging length between fab and sort to zero. As CTM does not consider stock level restrictions directly, the overall inventory level is controlled by an order creation frame parameter that defines the maximum total time span from a demand back to the first planned production order created by the planning run. This limits the time a product is stored in inventory and lowers the overall stock levels. The priority and order based sequential planning approach is congruent with the mindset of semiconductor planners because it ensures that highpriority customers and demands are processed first and forecast is matched to the available capacity after customer order fulfillment. Due to the sequential planning and the tracked pegging relationships connecting supply and demand elements, it is transparent to the planner which planned production or transportation order was created for which demand element. In certain situations it may be desirable to sell a higher-grade product for fulfilling a demand for a lower-grade product. In the CTM planning run this down-binning process can be modeled as substitution rules or a PPM/PDS converting the higher-grade into the lower-grade product via operations like re-marking or “burning fuses” to avoid overclocking of a lower-grade CPU, for instance. A graphical floworiented view of these relationships for individual demand elements supports the evaluation. The downside of this sequential approach is of course the lack of a global view of the algorithm on the supply chain while solving the planning problem. This may cause conflicts in case there are “single chain” products requiring

5.2 Supply Chain Business Practices

113

processing on a particular, say, fab resource and “multi chain” products that can be manufactured on a variety of such resources. If, for instance, CTM assigns an operation for fulfilling a high-priority “multi chain” demand to this resource the operation will not be shifted to an alternative resource when during the same planning run CTM encounters a low-priority “single chain” demand requiring processing on the same resource. The “single chain” demand may then be fulfilled late or not at all even though a global algorithm (such as optimization) would shift the “multi chain” demand to an alternative resource fulfilling both demands without violating the constraints. If the supply chain structure is such that these conflicts can occur, a common workaround is to plan “single” and “multi” chain products in consecutive planning runs, but then care must be taken regarding demand prioritization. In case a new customer demand is to be confirmed net change planning allows executing a planning run with all already created planned orders fixed resembling order promising functionality. This results in a relatively quick planning run because only the new customer order is planned using the available capacity – of course the new demand is implicitly assigned the lowest possible priority in this case. The next complete planning run will consider the “right” priority of the demand. The algorithm has been continuously enhanced since it was added to the SAP SCM portfolio. Descriptive characteristics for demands, for instance, are available as of SAP APO release 3.1 and allow more flexible prioritization rules and configurable forecast consumption of existing sales orders. Forecast consumption is vital for semiconductor manufacturers as it controls how customer orders are set against forecast quantities. Product substitution and supersession functionality, which is available as of SAP SCM release 4.0, supports product lifecycle planning which is another characteristic of the semiconductor business. 5.2.3.2 Optimization for Semiconductor By its nature, optimization does not operate in a sequential way like constraint propagation does in CTM planning. It rather treats the supply chain planning problem as a whole and results in a globally optimal plan in terms of the specified costs given the variables and constraints defined in the model. By including the right constraints in the model and appropriately adjusting the cost structure and the profile settings relevant to the SNP optimizer, the business rules explicitly included into CTM can be adhered to by optimization based planning. This gets evident by comparing the functionality of CTM for semiconductor described in Sect. 5.2.3.1 with the description of how to build and run a model for optimization in Chapters 3 and 4, including executing a planning run that leaves all existing orders untouched and only plans fulfillment of new demands. An overview of the costs considered by the optimizer is given in Table 1.1 on p. 19. Demand prioritization, for instance, is accomplished by adjusting the penalty costs for late delivery and non-delivery;

114

5 Planning in Semiconductor Manufacturing

down-binning is typically implemented via PPMs/PDSs technically converting one product grade into another. In this context it is important to understand that designing the cost structure leading to the desired planning results requires considerable expertise in mathematical optimization and project team members who are sufficiently educated and experienced in optimization are essential for a successful implementation. Other strategies like the single chain/multi chain product problem or forward/backward scheduling leading to features explicitly implemented in CTM are automatically supported by optimization due to the global character of the algorithm. Naturally, the underlying issues of minimum fab utilization and resource assignments are solved by observing the model constraints. The same holds for inventory issues because the SNP optimizer includes constraints restraining inventory levels. With limited effort constraints such as smooth capacity utilization across facilities and over time can be implemented with support from SAP, smooth capacity utilization over time can additionally be addressed by the optimization bound profile (cf. Sect. 4.2.3). One reason why the optimizer has not been chosen in some cases of SAP APO implementations at semiconductor manufacturers may be because the results of a purely rules-based algorithm like CTM are easier to explain to planners and business people who are used to priority and strictly rules based planning. This match with the way the users are used to work and think is a very strong asset difficult to overcome with an algorithm that is seen as a black box and hence is not trusted. Frequently, a strong reason in favor of CTM is the consequence of the algorithm being order driven rather than quantity driven: the pegging relationships that are created by the planning run connect demand elements and related supply elements. In connection with pre-set quotas and priorities it is easier to explain why a particular planned order has been created for a certain quantity, on a certain resource, and at a certain time. The optimizer – working quantity based – creates a network of orders fulfilling the demand in an optimal way (given the constraints and costs), but does not provide a tool for easily explaining why a certain order has been created in a certain way or why a particular demand is fulfilled late whilst others are not. Only sufficient knowledge of mathematical optimization can create trust in the results, which requires thorough understanding of optimization based planning and education of the planners. This, again, underlines the need for optimization experts closely involved in any optimizer implementation. On the other hand, large semiconductor companies often have highly educated operations research groups who develop optimization logic in-house directly based on engines like ILOG CPLEX or Xpress-MP. Mostly, those specialists are convinced that supply chain planning implies significant potential for competitive advantage and often management at such high-tech companies is of the same opinion. As a result there is often quite some internal pressure to utilize MILP-based optimization at such companies which may result in

5.3 The Semiconductor Case Study

115

implementing a tailored optimization model that is interfaced to an APS (or ERP) or optimization within a suitable APS such as SAP APO.

5.3 The Semiconductor Case Study The case we describe in this section is based on a SAP APO implementation at a manufacturer of application-specific integrated circuits (ASICs) that went live with SAP APO release 3.0 mid-2001 planning the worldwide production network and subcontracting partners. The SAP APO implementation was part of a larger supply chain project including SAP R/3, SAP APO, and R SAP
BW (the SAP Business Information Warehouse, a data warehouse solution) extending an existing SAP R/3 installation. It took approximately six months. Mid-2002 the company completed the SAP SCM ramp-up program upgrading the existing SAP APO system to the 3.1 release implementing enhanced planning functionality. 5.3.1 The Business Objectives and Project Scope As just mentioned, the SAP APO supply network planning implementation is to be seen as part of a bigger-scale supply chain project. The overall project objectives read quite general on the top level, but when looked at in detail they link well to the business challenges we mentioned earlier in this chapter: • Optimization of the supply chain planning process on both tactical and operational level • Integration with the SAP R/3 system and extending SAP R/3 where needed • Improve the sales and distribution process between production locations and the final customer by optimized inventory management of final product and intermediate stocks and establishing a consistent production planning process between SAP APO and SAP R/3 • Setup of SAP BW as global reporting environment Implementing SAP APO was the second step after establishing demand management and forecasting. The business scope is planning and sales order promising, both in SAP APO, and logistics execution in SAP R/3 which includes transaction processing with the numerous subcontractors used for all four processes fab, sort, assembly, and test. Here we will focus on the planning part that additionally has some impact on sales order promising. Supply chain planning is seen as a combination of two processes which correspond to capacity and master planning we mentioned in Sect. 5.2.1: business planning with a longer and customer order fulfillment with a shorter time horizon. The objective of business planning is to deal with and try to predict the

116

5 Planning in Semiconductor Manufacturing

size of the future business. It does that by identifying bottleneck situations and triggering solutions such as suggesting investments in certain classes of equipment and results in allocating products to possible production locations. This allocation is then used by the operational customer order fulfillment planning, which operates on a shorter time horizon than business planning and is responsible for on time delivery of customer orders. The customer order fulfillment planning results are triggers for production starts in the production units. For implementing the planning processes in SAP APO the CTM algorithm for SNP was chosen, mainly due to the positive result of an analysis matching business rules and functionality and the understandability and explainability of the algorithm for the end users (production planners). 5.3.2 The Supply Chain Structure

F

Sort

W/K

A

Test

T

M.F.

Fi ni sh ed

de vi ce s Te st ed

em As s

Assy

go od s

ic e bl ed

af er s w So rt e d

U ns o

Fab

de v

(W

s er af rte

d

w

w af er s St ar t

S

s

)/

di

es

(D

)

The structure of the modeled supply chain follows the flow of semiconductor manufacturing with an added mechanical finish step that converts tested devices (T products) into finished goods (G products). Figure 5.2 gives a schematic view of the different product types in the supply chain model.

G

Fig. 5.2. The different kinds of products in the supply chain (simplified) – M.F. stands for machanical finish (see text)

As shown in Fig. 5.3, outsourcing is possible at every step in the supply chain and hence the outsourcing partners are included in the supply chain model in order to get accurate planning results. In total the supply chain model consists of about 15 locations that are connected by product-specific transportation lanes, over 200 resources, over 2000 products, and over 2000 PPMs. While fab is usually done in-house at one of the internal facilities, the remaining steps sort, assembly, and final test are typically performed in Asia. The assembly process is always outsourced.

5.3 The Semiconductor Case Study

Wafer Fabrication

internal / external

Wafer Sort

internal / external

Assembly

external only

117

Test & Mechanical Finish internal / external

Fig. 5.3. Internal and external processes in the semiconductor case

5.3.3 SNP Implementation in SAP APO As both processes business planning and customer order fulfillment are based on the same supply chain definition and essentially differ only in their planning horizons they are both based on the same SNP supply chain model. Based on the different objectives of these two processes they are used by different departments and are run at different times: the longer-term business planning is executed every month whereas the operationally oriented customer order fulfillment is run on a weekly basis. Both business planning and customer order fulfillment integrate to the legacy demand management tool in the sense that the planning processes check the feasibility of the forecast data in terms of available capacity. The resulting so-called constrained forecast is then written back into the demand management system which thus reflects the most up to date demand picture. Sales order promising uses the planning process in case the Available-toPromise (ATP) functionality cannot confirm a customer order. In this case, a net change planning run is executed with the objective to get an approximate confirmation date. As the demands in the system are prioritized and the new demand is put at “the end of the list” this date will be more pessimistic than the one after the next complete planning run. If net change planning does not find a suitable confirmation date for the customer order the order is confirmed after the next complete customer order fulfillment planning run. The implementation of SAP APO met the planning requirements on the whole successfully modeling the business planning and customer order fulfillment processes with SAP APO. Implementing SAP APO and SAP R/3 at the same time enables taking full advantage of the very tight integration between the two systems which is offered by SAP as the core interface (CIF). Doing such a parallel implementation allows a wider range of fine tuning both systems than in cases where one system is productive already and the other needs to be adapted to its configuration. During and after the project the choice of the algorithm was revisited occasionally, with the result that while optimization might provide direct solutions for issues CTM needed workarounds for, the advantages of staying with

118

5 Planning in Semiconductor Manufacturing

CTM prevailed. Prime criteria in favor of CTM were the explainability of the rules of the constraint propagation-based algorithm and the fixed pegging as a “natural” outcome explicitly connecting demands and supplies. Key benefits from the implementation project address the objectives which were set beforehand. Clear indications for adding business value were seen in the areas of achieving integrated supply chain planning and execution, implementing automated and streamlined business processes with a minimum of manual entry, improved tracking of inventory, increased information accuracy, and readiness for further integration (focusing on business-to-business processes based on the high-tech standard RosettaNet).

6 Consumer Products

The consumer products industries span a rather wide range of business types including apparel & footwear, beverage, food, home appliances, etc. Nevertheless there are common characteristics and business challenges they have to cope with. As the consumer market is saturated in large parts of the world, opening new market segments is very difficult and the pressure for increased competitiveness in the whole supply chain is accordingly high.

6.1 Supply Chain Challenges Characterizing the Consumer Products Industry Competing with other market players companies are frequently introducing new products for stimulating the consumers’ buying behavior, in many cases along with a promotion campaign for the new or intermittently available product. Relating to this, most retailers keep very little inventory in order to be ready for quickly changing customer demand patterns. For the manufacturer these volatile demands translate into the need for efficient demand planning and delivery processes. Another reason for typically low inventory levels at retailers is product expiration. Goods such as food and beverages, medicine, seasonal items, etc. have a certain shelf-life after which they have to be discarded or sent back to the manufacturer. Seasonal demand variations will put substantial stress on supply chain planning, especially if we consider constraints such as shelf-life and quick product changes. In the particularly hot summer in 2003, for example, it was almost impossible to get air conditioners in Germany. They were sold out after few hot weeks. By 2005, two years later, the prices have dropped by almost half, suggesting excess production after 2003 that still filled the warehouses. All of the above mentioned characteristics make supply chain planning particularly important for the consumer goods industry.

120

6 Consumer Products

Accurate forecasting, for instance, targets reduced finished goods inventory allowing a quicker response to changed customer buying behavior. Ideally, this happens in the framework of a collaborative demand planning process involving forecasts of key resellers that are fed into the planning logic of the manufacturer. Similarly, sophisticated production planning can help in better utilizing available capacity and in avoiding bottlenecks in the production process and thus increase on-time deliveries from the manufacturer. Scheckenbach and Zeier (2003, [84]) list various characteristic SCM requirements for the consumer products industry, among them those listed in Table 6.1. In the following section we describe how problems related to consumer products can be solved with SAP APO based upon a successful SAP APO optimizer implementation in the beverage industry. Industry Characteristic frequent promotions

SCM System Requirement promotion planning

demand-driven

demand-driven network planning algorithms

process manufacturing

process planning methods (material dependencies, campaign planning, etc.)

production process

joint production, sequence planning, minimize wastage (e.g., in cutting operations)

line production

assign production to different lines, sequencing

product lifecycle

plan with short product lifecycles

international supply chain

take country specifics into account

proof of origins

adequate batch management

limited shelf life

planning and forecasting have to respect shelf life constraints

Table 6.1. Some consumer product industry-specific characteristics and requirements (cf. Scheckenbach & Zeier, 2003, [84])

In a supply chain management case study described on the public SAP website http://www.sap.com, a South African beverage bottler and distributor who implemented mySAP SCM inlcuding SNP optimization in SAP APO reduced lost sales due to stock outs by 5%, reduced inventory levels by 26%, and achieved 92% on-time delivery.

6.2 The Carlsberg Case Carlsberg A/S Denmark is Scandinavia’s biggest and the world’s 6th largest beer brewer. In addition to their product portfolio of about 300 beer products

6.2 The Carlsberg Case

121

they also distribute approximately 150 Coca-Cola products in Denmark. The supply chain optimization project, conducted by team members from a Scandinavian consulting company and SAP, went operational end of 2002. The case description is based on Kreipl and Pinedo (2004, [61]) and Pinedo (2005, [77]). 6.2.1 The Carlsberg Business Objectives and Project Scope Along the lines of the supply chain challenges in the industry we mention in Sect. 6.1 the project was focused on increasing the overall “speed” and customer service in the supply chain. High inventory levels at the distribution centers in conjunction with sub-optimal transportation and manufacturing strategies made it difficult to adequately react to quick market changes. The company was limited in its ability to satisfy short-term customer demand changes and depended on the quality of demand forecasting. A more general, but competing objective was to increase the customer service level, a goal intrinsically conflicting with lower inventory levels at delivery points. Thus, the specific business objevtives were • • • • •

increase customer service level decrease inventory costs (avoid too high inventory at DCs) optimize sourcing decisions (lower transportation and production costs) cost-optimal production change business into a more demand driven process

Translated into modules of SCM business software, the scope of the SCMproject was spanning the whole range from long term planning, medium term (master) planning for the whole supply chain, and short term production scheduling. In SAP APO, the tool chosen by Carlsberg, the involved modules are Demand Planning (DP), Supply Network Planning (SNP) & Deployment (this is where SAP APO’s SNP optimizer is used), and Production Planning/Detailed Scheduling (PP/DS). Because of our focus on (MI)LP we will concentrate on the SNP optimizer piece in SNP & Deployment and refer to Kreipl and Pinedo (2004, [61]) and Pinedo (2005, [77]) for a more detailed description of the complete SCM process and its implementation in SAP APO. The references also include some details of additional topics such as advanced safety stock methods for maintaining the desired customer service levels and PP/DS. 6.2.2 The Supply Chain Structure in the Carlsberg Case The modeled supply chain has three stages: beer production at two plants, a centralized warehouse/distribution center (DC), another central DC coinciding with one of the plants, and a number of local warehouses/DCs. Transportation to the local warehouses can originate from the central warehouse

122

6 Consumer Products

Fig. 6.1. The Carlsberg supply chain structure

or directly from a factory. There are some constraints limiting the possible transportation paths, such as not all local DCs can be serviced from the first plant. Figure 6.1 sketches this structure. In the plants there are three principal production steps: brewing including fermentation of the beer, filtering and filling into trading units. All three steps are capacity constrained, but the bottleneck is usually the filling process. At the two plants there are two and four filling lines, respectively, with different costs and processing times. Integer variables are introduced into the model by lot size constraints on the brewing and filling steps. Due to the fixed size of the brewing tanks orders of less than the size of the tank are rounded up to one full tank and larger orders are rounded up or down to represent an integer multiple of the tank size. With the filling lines representing a capacity bottleneck, the filling quantities are to be chosen such that the filling resources are utilized to 100% capacity. Typical process durations in industrial beer production are about 15–20 days for brewing, 3–4 days for filtering, and one day for filling. Figure 6.2 shows a diagram of the production process. The products are segmented into categories A, B, and C according to their sales volumes allowing different business processes to apply for the different segments. A is made up of the fast moving mass-products (Carlsberg Pils and Tuborg Green) representing more than two thirds of the total business volume, B and C consist of the slow moving and more expensive seasonal products. After the actual production processes the beer is transported from the plants to the regional distribution centers – either via the central DC or directly from the plant depending on the transportation quantity and the individual product. Here, again, lot size constraints occur and of course lanespecific transportation durations have to be taken into account.

6.2 The Carlsberg Case

123

Fig. 6.2. The production process at Carlsberg (simplified)

6.2.3 SNP Optimization Implementation in SAP APO The medium-term SNP process covers 12 weeks with 4 weeks in daily and 8 weeks in weekly time buckets. Discrete constraints (lot sizes) caused formulating the problem as a MILP problem. Several hundred products and several thousand location products result in a MILP problem with several hundred thousand variables, over a hundred thousand constraints and many tens of thousands of discrete variables. The cost minimization model including • • • • • •

production cost storage cost transportation cost late delivery cost non-delivery cost safety stock deficit penalty cost1

is subject to the constraints • • • • • •

production times in brewing, filtering, and filling capacity of filling resources (daily and weekly) resource consumptions / set-up times transportation times between locations stock balance lot size constraints.

While production and transportation costs can be determined in a straightforward way, other cost types in the model represent Carlsberg’s priorities and are much more complicated to compute. For instance, large efforts were 1

The safety stock levels are calculated in a separate process taking into account the desired service level, replenishment lead time, lot size, forecast error (forecast history vs. sales history), and future forecast (see Kreipl & Pinedo, 2004, [61]).

124

6 Consumer Products

spent for constructing a model for storage cost in the different warehouses in order to resemble Carlsberg’s desired strategies for transportation and replenishment minimizing the effects of late deliveries in conjunction with safety stock violations in the different types of warehouses. Typical for a (MI)LP, the cost types are strongly interconnected and require good understanding of the whole cost structure to avoid unwanted results. While this may not be a surprise to a mathematician, it required much effort to explain this to the business people during the implementation project. The medium-term SNP optimization run results in a production plan for the next 12 weeks giving details on planned production quantities in the three production steps down to the level of bottles filled at each filling line and on the planned transportation quantities between the locations. Planned stock quantities at each location are a direct result of this plan. The next step is detailed scheduling including sequencing on the bottleneck resources which is done using evolutionary algorithms (we refer once more to Kreipl and Pinedo, 2004, [61] and Pinedo, 2005, [77] for a more thorough description). As one of the goals was to be able to run the SNP optimization daily, performance was an important issue. To improve performance of solving the MILP problem the project team applied product decomposition techniques. At first, manual decomposition results in three runs for the Carlsberg products, taking into account that slow movers can typically be filled in certain filling lines only and hence planning these first, then the B products and at last the two A products. Each of these three optimization runs itself – having between 100,000 and 500,000 variables and 50,000 to 100,000 constraints – uses product decomposition in SAP APO resulting in 5–10 subproblems to be solved for each MILP problem. The exact numbers depend on initial conditions like number of customer demands to be planned and on the exact number of time buckets (a planning run on Monday has more daily buckets than one on Friday because the first four full weeks are planned daily). Given all sorts of consequences of decomposition per se an acceptable runtime of about 10 hours for an optimization process was achieved allowing a daily SNP optimization run. Effects like occasional huge gaps of up to 400% between the LP relaxation and the MILP solution have still to be explained to the users very carefully (usually the gap is 0.2% – 10%; cf. Kreipl and Pinedo, 2004, [61]), especially because Operations Research and/or optimization knowledge very often is missing in the customer teams when implementing business software like SAP products. Huge gaps like this often result from a demand that can be fulfilled by the LP relaxation, but not by the MILP problem due to lot size constraints, for instance. Excess production resulting from discrete lot size constraints is one typical example requiring “OR coaching” – under certain circumstances the optimizer would suggest to round up production to the next full lot avoiding late demand penalties rather than falling short in supply avoiding excessive inventory cost... All in all, it is very important to explain techniques like discretization (MILP) and decomposition along with how they might effect the planning result very carefully.

7 Customized Optimization Solutions for the Automotive and Chemical Industries

This chapter1 describes two case studies: a planning problem in the automotive industry and a scheduling problem in the chemical industry. Both are examples of external optimization applications integrated into a SAP system landscape that supplement the standard SAP APO functionality. Almost all projects in the area of Supply Chain Management at axentiv begin with a Supply Chain Assessment, or SCA. Within a four to eight week time frame, axentiv consultants work closely with customers to identify areas of the supply chain in which the most benefit can be achieved. The SCA includes a feasibility study in which actual customer data are imported into the axentiv Supply Chain Lab and several scenarios are evaluated. Through the Supply Chain Assessment it may become clear that the standard planning processes in SAP APO do not meet a customer’s needs. In this case, axentiv is one of few companies able to integrate customized optimization solutions into an SAP landscape. Although the majority of SCM projects at axentiv successfully use standard SAP APO, the areas of optimization and integration are also considered core competencies within the company. The two case studies described below are examples of successful implementations involving integrated customized optimization solutions.

7.1 Automotive Case Study This case study involves projects at a company in the automotive industry. The company considered standard-software based solutions for the following planning tasks: order-driven planning as well as forecast-driven areas of budget planning and master production planning. In order to get the best fit to their planning situation, the company became interested in an integrated optimizer 1

Ruth Wassermann, Matthias Lautenschl¨ ager, Boris Reuter & Christian Steiner, axentiv AG, Darmstadt, Germany, e-mail: {ruth.wassermann, matthias.lauten schlaeger, boris.reuter, christian.steiner}@axentiv.de, http://www.axentiv.de

126

Customized Optimization Solutions

which was customized to meet their specialized needs. In each case, an initial feasibility study with axentiv was performed in order to build an optimizer and prove its effectiveness. In the implementation phase of the projects, again carried out by axentiv, ILOG’s cartridge technology described in Sect. 9.2 was chosen to connect the custom optimizer to the standard software. In all cases, the CPLEX solver was called from ILOG’s OPL Studio, which was used to model the underlying linear and mixed integer linear programming models. In this section, we give an overview of two integrated optimization solutions built for a German automobile company. For each of these solutions, the planning scenario is first discussed in general terms. Next, the corresponding mathematical model is described. Finally, we elaborate upon the user interface and the “checker”, an analytical tool used to evaluate optimized plans. 7.1.1 The Complete Planning System Meyr (2004, [70]) classifies several planning levels in the German automobile industry. In Fig. 7.1, rectangles identify planning tasks and arrows illustrate the flow of information. We will concentrate on optimization extensions in the following areas: long-term, strategic planning and mid-term production and sales planning. In addition, an optimization extension was developed for the area of order-driven planning, which is depicted in Fig. 7.2, as it is no longer based on forecasts and uses real order information. First, we describe the planning tasks of budget planning, master production planning and allocation planning, as classified in Meyr. At our particular customer, these planning tasks were partially rearranged and took place at a different level. We identify the differences to the Meyr classification system. Budget Planning: an annual plan identifying production and sales quantities of car models for the next year on a monthly basis. Master Production Planning: plan with a rolling horizon providing a higher level of detail (i.e., weekly, rather than monthly) than a budget plan. Allocation Planning: plan in which the aggregated quotas are assigned to a more detailed level. 7.1.2 Strategic Planning The goal of this planning task is to create a long-range plan for up to four years in the future. The plan does not include the current fiscal year and finds good feasible solutions for the following three fiscal years. Inputs to the plan are projected monthly sales figures for various demand regions, provided by the marketing department. On the production side, capacity is identified at a monthly, weekly and daily level. In addition, ramp-up information as well as various sales constraints are taken into account. The plan includes desired regional growth and enables the user to investigate various capacity situations. In addition, validity date information is passed to the optimizer. In this way,

7.1 Automotive Case Study procurement

production

distribution

sales

Budget planning production

take rates

volume goals, earning goals, annual working time

production

MRP plans

(monthly) aggregate quotas

sales forecasts, take rates

(monthly) production & sales plans

demand planning

requests of regions

Master production pl. production

supply plans

sales (weekly) aggregate quotas

(weekly) production plans overtime suppliers

127

allocation planning detailed quotas

requests for models

retailers

plants

Fig. 7.1. Overview of (mainly) forecast-driven planning in the German automotive industry

procurement

production

distribution

aggregate quotas

(weekly) production plans, overtime

specified orders

plant assignment

with due dates

(weekly) production orders per plant

MRP & lot-sizing

daily buckets

Line assignment & model mix planning

procurement lot-sizes

suppliers

JIT-calls SILS

car sequence

sequencing

cars

allocation planning datailed quotas

specification changes

distribution

customer & retailer orders

order promising promised dates

daily buckets

MRP

sales

customer orders

final customers

Fig. 7.2. Overview of order-driven planning in the German automotive industry

the model takes into account country-specific requirements and model year changes. Results of this plan are used to identify necessary personnel and equipment changes. For example, a planner may look into the costs and benefits of closing a plant during a given floating holiday in order to make an informed decision on closing the plant for the day. Such a decision must be made well in advance,

128

Customized Optimization Solutions

as it must also be approved by the workers’ representative. In another example, a planner may simulate increased capacity on an assembly line. In order to reduce costs of additional development and maintenance, the mathematical model used for budget planning was kept as similar as possible to the model used for master production planning. The model for master production planning is described in detail below. 7.1.3 Mid-Range (Budget and Master Production) Planning The goal of this planning task is to create a mid-range plan for the current fiscal year. In our example, the goal of this planning step is to develop a single plan which encompasses the goals of both Sales/Distribution and Production. Inputs to this plan include information from both areas. Once a year, distributors are asked to forecast their sales volumes for the next fiscal year on a monthly basis. These values are then updated once a month. This information is at the model level, with additional information such as motor and specific features. After some negotiation, the distributors are provided with guaranteed volumes of automobiles per month for the next year. These volumes are referred to as “quotas”. Quotas are used to distribute the vehicles fairly among the markets – both in the case where the market demand is higher than production capacity as well as when the production capabilities are higher than the volumes demanded. In addition to the quota values, Sales/Distribution is also able to give input on specific planning constraints. For example, one such constraint might be that 40% of all right-hand driven automobiles in a given month should be shipped to Great Britain. The Production department provides details on ramp-up activities for new production areas, as well constraints due to resource capacity and supply of components. These constraints include modelmix constraints, such as at most 35% of all automobiles produced in a given week may have a 6-cylinder motor or maximum 25% are allowed to be fivedoor models. A plan is created using this information as well as various weights to penalize undesired outcomes. From this plan, we know the number of automobiles of each model / motor type as well as various attributes to be produced in each plant on each day. A separate step for the allocation plan is not required. In our example, the problem is solved at an aggregated Distributor Group level, where each group member has the same penalty weights. After the optimal plan has been found, the automobiles are proportionally divided among the group members based on the originally requested amounts. The plan also identifies which distributors have shortages and surpluses per month and per fiscal year. The developed optimizer creates a single mid-range plan which encompasses the defined planning tasks of budget, master and allocation planning.

7.1 Automotive Case Study

129

7.1.3.1 Goals In general, goals of the mid-range planning problem can be assigned one of two categories: production-oriented goals and sales-oriented goals. Both areas provide inputs into the optimization problems, creating solutions acceptable to both parties. The overall business goal is to create a plan in which total profit is maximized, taking into account the various resource and other constraints. Available capacities should be so well put to use that the vehicles and markets are emphasized, which have the highest profit margins or the highest chance of sale. The profit maximization objective is not modeled directly. Instead, the differences to market demand and desired resource utilization are evaluated and penalized. Penalty values are calculated based on priorities among the various vehicles and markets. Secondary goals are the balanced and high level of resource use as well as delivery within the month demanded. Goals of the mid-range planning include the following: • All distributor demands should be met as far as possible, while taking production constraints into account Production Goals: • Use production resources at their desired utilization levels • Avoid fluctuations in resource utilization Sales Goals: • Accommodate the distributors’ yearly demands at the level required (model, motor, some features) • Divide all demand shortages and surpluses equally among all distributors and vehicles of similar type • Accommodate the distributors’ monthly demands with as little early and late fulfillment as possible • Respect maximum and minimum supplies to distributors All automobile models and distributors can be assigned individual weights, so that differences to desired demand involve those model and distributor combinations with lower priorities. 7.1.3.2 Constraints The model contains the following constraints. • Evaluation of the difference to meeting the required demand, both per month and per year • Evaluation of the differences in demand fulfillment among various distributors and vehicle types

130

• • • •

Customized Optimization Solutions

Consideration of the model year change in fulfilling demand Coupling of the number of vehicles demanded and the number of vehicles produced Definition of the difference to the desired utilization of the resources Taking into account the upper and lower limits of the utilization of each production resource and other planning constraints

Note that several of the constraints define variables which are penalized in the objective function. 7.1.3.3 Decomposition In this example, an initial decomposition takes place based on model type. Models can be broken into groups which neither require the same production resources nor have the same planning constraints. A second decomposition takes place in finding a good integer solution quickly. First, the linear programming problem (LP) is solved. This solution solves the mid-range planning problem, except that the number of vehicles produced and provided to a given market must be an integer. The mixed integer problem (MIP) is used as a sophisticated rounding mechanism, where the appropriate variables are integer and the solution meets all constraints. In the next step, solution to the LP problem is used to restrict the values of the integer solution. Values in the LP solution which are already integer are fixed at this integer value. Non-integer values in the linear programming solution are used to form upper and lower bounds for the non-integer variables. For the case where an infeasibility occurs, these bounds are broadened and the problem is resolved. In real examples this has not been a problem. 7.1.3.4 Checker A checker was implemented to allow a planner to quickly identify strengths and weaknesses of a plan using several key figures. The following Key Performance Indicators (KPI) are calculated in the cartridge based on the optimization results: •

total yearly quota / total yearly demand for each fiscal year and model year in the optimization • average utilization of a production line per day • total production line utilization In addition, general information is displayed for each order and each resource: • information on each resource and planning constraint: utilization, upper and lower bounds on utilization After running the checker, the planner decides whether to save or discard the plan and corresponding checker results.

7.1 Automotive Case Study

131

7.1.3.5 User Interface The entire process of transforming data in order to be able to build the optimization model, transferring data to the optimization server as well as the actual optimization process itself remain hidden from the user and happen “behind-the-scenes”. The custom optimizer used in the strategic and midrange planning is completely represented inside a shared SAP user interface. Master and transactional data as well as optimization parameters are maintained here. Where data for the mid-range and strategic planning were not available as standard SAP planning objects, the required user interfaces for data input were developed. Master data maintenance includes information on resources, validity dates and dates for the model year change. In order to influence the optimization results, profiles can be created containing sets of weights. These profiles can be saved and reused for future optimization runs. Each optimization run is started from the optimization cockpit, which enables the selection of master data, weights and optimization parameters such as time allocated for the optimization. After starting the optimizer, all relevant data are read and a data validation takes place. Depending on their severity, resulting validation errors cause a warning to be issued or the optimization to be stopped. A log is created, allowing the user to see all warnings and errors. In addition, the checker is fully integrated into the optimization cockpit, enabling the user to evaluate the results directly after the optimization is completed. If desired, the user can begin a new optimization with another set of parameters and compare results. Once the planner has decided a given plan should be used, these results are sent back to the Business Warehouse (BW) system. These saved results are used in creating next month’s plan, in order to avoid unnecessary turbulence when new plans are created. Both quota and resource capacity information resulting from the mid-range planning are considered in the order-driven planning. The quotas are used as guidelines for the number of orders a distributor can and must place. All orders within the quota values are taken into account in the order-driven planning. On the production side, the resulting mid-range production values as well as supplier quantities are also considered in the order-driven planning. These values are used in negotiations with suppliers and are binding for both parties. 7.1.4 Order-driven Planning Meyr classifies various planning tasks of order-driven planning below. See Fig. 7.2. Here, the planning tasks are triggered by actual orders, either from individual customers or retailers. Plant Assignment: a plan in which the production orders have been assigned to the plants.

132

Customized Optimization Solutions

Line Assignment and Model-Mix Planning: a plan in which the production orders are distributed among the assembly lines and then assigned to a production day. Sequencing: a plan is created where the actual sequence of cars to be produced on the assembly line is determined. In our example, the goal of this planning task is to identify which order will be produced in which plant on which day. This single plan encompasses the tasks of plant assignment and line assignment and model-mix planning described above. The actual sequencing of the automobiles was not within the scope of the project. Side constraints are taken into account allowing for resource capacities as well as other planning restrictions. 7.1.4.1 Decomposition In order to substantially decrease solution time, the main problem was decomposed into smaller problems. First, a linear program problem was solved which found a plan using weekly time buckets. Next, a mixed integer program problem was solved using weekly time buckets, where the solution space is reduced by using the solution of the weekly linear program. Finally, daily mixed integer programs are solved successively in order to place orders in a specific day. In all models, the production period determined is a day. In the weekly model, the resource capacity is considered only at the aggregated weekly level, but an initial production day is calculated. In the daily models, the difference to this day is evaluated and the model penalizes changing the planned production day. 7.1.4.2 Goals Plan objectives are dependent on the time frame involved. In the short-term planning horizon (next several days), it is important that the available production capacity be used. Gaps in the production line should be avoided, as then the daily production capacity is not used. In the following weeks, the objective is balanced production, which enables incoming orders to be produced on many different days. Bottleneck situations should be avoided to ensure that a specific order requiring a given feature or combination of features does not need to wait weeks to be produced. The mid-range planning results provide assigned planning months for the individual orders. This distribution of orders leads automatically to smooth production. Goals include the following: • • •

minimize the difference to a given desired utilization value of the production resources smooth the use of resources over time minimize difference to the customer’s desired date of delivery

7.1 Automotive Case Study

133

• •

minimize difference to previously planned production month use weights for the priority assignment of an order to a certain production site • penalize the number of unplanned orders • (only for the daily MIP problem) penalize the difference to the production day found in the weekly MIP • minimize the difference to the previously assigned production month from the mid-range planning All resources and orders can be assigned individual weights, so that differences to desired utilization take place on lower priority resources and differences to the customer’s desired delivery date involve lower-priority orders. In addition, weights may be time-dependent, so that certain restrictions can be especially weighted in certain time periods. 7.1.4.3 Constraints The model contained the following constraints: • •

No production of vehicles takes place outside of the defined validity dates Resource capacity is taken into account (aggregated to a week for the weekly LP, weekly MIP) • Define the maximal difference from the customer’s wished delivery day • Define the maximal difference from the previously planned production month Several of these constraints define variables penalized in the objective function. 7.1.4.4 Checker As in the other planning problems, a checker was implemented to allow a planner to quickly identify strengths and weaknesses of a plan. The following Key Performance Indicators (KPI) are calculated in the cartridge based on the optimization results: • average difference from the desired delivery day • average utilization of a production line • number of days with underused production line capacity • variance of the resource utilization In addition, general information is displayed for each order and each resource: • •

information on each order: planned day of production, difference to desired delivery date, production plant where produced information on each resource: absolute utilization, percentage utilization, difference to the desired utilization

After running the checker, the planner decides whether to save or discard the plan and corresponding checker results.

134

Customized Optimization Solutions

7.1.4.5 User Interface The optimizer for the order-based planning is also fully integrated into the SAP user interface. This user interface includes standard screens for the relevant master and transformational data and customized screens for the optimizer-specific parameters and control mechanisms, similar to those used in the strategic and mid-range planning. The customized screens were created in such a way that users do not notice a difference between the standard and customized screens. From the user interface, acceptable results can be sent to SAP APO. After the order-driven planning step is completed, SAP APO performs any necessary changes to the customer order, such as changes to the production date, status or location. In addition, internal tables containing resource usage are updated according to the replanned orders. 7.1.5 Conclusion The implementation of the Order-Driven Planning project was completed within six months. The Mid-Range Planning project was also completed within six months, after an extensive two-month blueprint phase in which axentiv was heavily involved. A project manager, an integration specialist, an optimization specialist as well as user-interface development were required for both projects. As a result of the two projects, the time required to create feasible plans in the areas of Order-Driven Planning and Mid-Range Planning was significantly reduced. Previously, much time was spent by the planners creating feasible plans which were not nearly as detailed as the plans currently created by the optimizer. Much of the tedious work has been eliminated and planners spend more time attempting various scenarios and analyzing the optimized plans.

7.2 Chemical Case Study This case study involves a project at one of world’s leading chemical companies, which has divisions in the following areas: agricultural products and nutrition, oil and gas, performance products, chemicals, and plastics. This case study focuses on the short-term detailed scheduling of a product in one of the European divisions of the chemical company. Approximately 500 products including commodities and specialized items are sold by the division. The products are wrapped in different packaging leading to a total of 1,500 saleable items. From the logistic point of view the products can be combined into product groups by considering characteristics relating to the production process. In this case study, we will first define the overall planning scenario in which the cartridge is embedded. Next, we describe in detail the production process

7.2 Chemical Case Study

135

for which the customized optimization solution and cartridge were built, as well as discuss the approximation methods used in the SAP APO Production Planning/Detailed Scheduling (PP/DS) module. Finally, we will elaborate on the actual cartridge and optimization problem, providing details on the flow of data, the user interface, and the objective function and constraints of the formulated optimization models. 7.2.1 The Architecture of the Complete Planning System The detailed scheduling of the cartridge is part of a planning system implemented using SAP APO. The overall planning process is made up of the following components (cf. Fig. 7.3):

Fig. 7.3. Planning levels in the chemical case

• • • •

Demand Planning (cf. Appendix A.2) Supply Network Planning PP/DS and ILOG Cartridge (cf. Appendix A.2 for PP/DS) SAP R/3

In the demand planning (DP) module, planned sales quantities - demands are collected from customers, forecasted by experienced planners or calculated by statistical models. The planning horizon is twelve months with a bucket size of one month.

136

Customized Optimization Solutions

The demands are the basis for mid-term planning in Supply Network planning (SNP), where resource capacity and material availability are taken into account. The planning horizon here is also twelve months with a bucket size of one month. The results of this planning step are SNP planned orders which give the amount of product to be produced per month in each location as well as the amount of raw and other input materials available per month. Short-term planning using Production Planning and Detailed Scheduling (PP/DS) supports the scheduling of orders released by SNP. Because of some special planning requirements described below, an extension with ILOG Cartridge Technology was implemented for the three-month horizon. The results of this planning level are PP/DS planned orders, which give the exact production times of each product on each resource (machine). A further result is the dependent demand of input materials. At this point, the planning information flows into the operational system, SAP R/3. Here, the PP/DS planned orders are transformed into process orders in SAP R/3 PP. 7.2.2 Production Planning and Detailed Scheduling In this section, we give a detailed view of the production process. Some products are created by mixing two melts. The melts are created in smelters, which allow variable throughputs. Each smelter has a minimum and maximum throughput and changes to the melts on the smelter result in setup times, as well as a certain amount of associated waste product. To keep production running smoothly, the number of smelter setups as well as changes to the smelter throughput should be kept to a minimum. After leaving the smelters, the product flows directly into the extruders (cf. Fig. 7.4). The final product produced depends on the smelter mix as well as possible additives. Each extruder has a minimum and a maximum allowed throughput and changes to the throughput are allowed within this range. The number of these throughput changes should also be minimized although these changes are able to be made more frequently than those to the smelters, as they are less costly and time-consuming. It is important to note that this is a continuous process. If the smelter throughputs remain constant and the throughput on one extruder changes, the throughput on another extruder must be adjusted as well. All product which leaves the smelters must go through the extruders. For example, assume the current smelter campaign sets the throughput of smelter 1 at three tons per hour and of smelter 2 at two tons per hour. For simplification purposes, assume we have only three extruders attached to the smelters and that four end products are produced. Product 1 is made up of 70% Melt 1 and 30% Melt 2. Product 2 is composed of 60% Melt 1 and 40% Melt 2. Product 3 is made up of 50% Melt 1 and 50% Melt 2 and Product 4 is made up of 40% Melt 1 and 60% Melt 2. Initially we produce Products 1, 2 and 3 on the extruders according to the plan shown in part a) of Table 7.1. Suppose

7.2 Chemical Case Study

137

Fig. 7.4. Production layout in the chemical case

more Product 1 is needed. There are several alternatives, as shown below. The three alternatives shown increase the throughput on the first extruder to 2.0 tons per hour. This increase must be offset by another extruder (Alternatives 1 and 2) or by an adjustment to one of the smelters (Alternative 3). This small Ex 1 2 3

Product t/h Melt 1 Melt 2 Prod 1 1.5 1.05 0.45 Prod 2 2.0 1.20 0.80 Prod 3 1.5 0.75 0.75 a) Initial Production

Ex 1 2 3

Product t/h Melt 1 Melt 2 Prod 1 2.0 1.40 0.60 Prod 2 1.0 0.60 0.40 Prod 3 2.0 1.00 1.00 b) Alternative 1

Ex 1 2 3

Product t/h Melt 1 Melt 2 Prod 1 2.0 1.40 0.60 Prod 2 2.0 1.20 0.80 Prod 4 1.0 0.40 0.60 c) Alternative 2

Ex 1 2 3

Product t/h Melt 1 Melt 2 Prod 1 2.0 1.40 0.60 Prod 2 2.0 1.20 0.80 Prod 3 1.2 0.60 0.60 d) Alternative 3

Table 7.1. The left column in all four windows displays the extruder, the entries in the “Melt 1” and “Melt 2” columns are specified in t/h.

example shows the complexity involved in adjusting extruders and smelters to produce the desired products.

138

Customized Optimization Solutions

7.2.3 Approximation Methods in SAP APO PP/DS Mathematical optimization was not used in the SAP APO Production Planning / Detailed Scheduling (PP/DS) module. A general, “out-of-the-box” exact model would often have required extremely long solutions times, making approximation models the better choice. In the PP/DS module in SAP APO release 3.0 which is the release this case is based on, two approximation optimization techniques are available: evolutionary algorithms and constraintbased programming. In general, the evolutionary algorithms work well on planning problems where there is little difficulty finding a feasible solution. Here, the difficulty lies in finding very good solutions. Constraint-based programming works well on complex planning problems in which numerous dependencies and constraints make finding a feasible solution difficult. 7.2.3.1 Goals In order to improve production order sequencing and assignment to resources, the planner provides weights for several objective function components. Depending on the type of solution desired, each of the following can be weighted: total throughput time, total setup time, total setup cost, maximum cost of lateness, total late costs and sum of the costs for machine use. In addition to selecting the approximation method and defining the penalty weights for the objective function, the planner enters a time allotted for finding a solution. 7.2.3.2 Constraints Here, we differentiate between hard constraints (which absolutely must be met) and soft constraints (which may be violated, provided a penalty cost is paid). Hard constraints include the following: • • • • •

input materials and resource requirements time constraints between production activities pegging constraints resource calendar which keeps track of working days and holidays sequential and resource-dependent setup times

Soft constraints were only used to consider customer order due dates. 7.2.4 Cartridge Initially, axentiv conducted a feasibility study to see whether standard SAP APO PP/DS (release 3.0) could be used to carry out the short-term detailed scheduling. The results of the study indicated that some important desired features could not be achieved in the standard. A major point was that smelter

7.2 Chemical Case Study

139

and extruder throughputs are variable values between a minimum and maximum value. In order to model this in SAP APO, each allowable value would be assigned a PPM mode. Further, the PPM identifies the length of production. These two factors lead to an explosion in the number of PPMs to be maintained: for each of the 500 products, a separate PPM is required for each smelter or extruder with over 100 modi. Further, using the standard PP/DS heuristic would not be possible, since the heuristic would simply choose the fastest mode. A further modeling issue was that the setup times for the smelters were dependent on the throughput before the setup takes place. That is, there are constant volumes of product which are lost as waste in a setup, and thus the setup time depends on the throughput. In SAP APO PP/DS, the setup matrix only allows for constant times. 7.2.4.1 Cartridge Planning Scenario Inputs to the problem include the monthly SNP planned orders, which provide the amount of each product per month to be produced as well as the location to be produced. Other information includes master data found in SAP APO such as product and location descriptions as well as calendar information. Finally, custom tables in SAP APO are used to store optimizer-specific information. The plan for the current month is used as input and considered fixed. Using the input data, the cartridge performs some preprocessing and data validation, prepares the database for the optimizer and calls the optimizer. The optimizer results are used to define the PP/DS process orders as well as create a corresponding PPM mode. These process orders are then transferred into SAP R/3. 7.2.4.2 Optimization Problem (Overview) A mixed integer program (MIP) was written in ILOG’s OPL Studio with the CPLEX solver to solve the optimization problem. The optimization problem should deliver a schedule for the smelters and extruders for the next three months. That is, the product sequence, throughput and length of production on each smelter and extruder will be specified. This schedule takes into account resource constraints. In addition, raw material demands can be derived from the plan. 7.2.4.3 Decomposition In order to substantially decrease solution time, the main problem was decomposed into smaller problems. First, the melt products are assigned to the smelters and simple extruders, which have only one attached smelter.

140

Customized Optimization Solutions

Next, products are assigned to the complex extruders which have two attached smelters. The assignment of the complex extruders is time-consuming. By simplifying the problem and first assigning the melts for the complex extruders, a significant reduction in running time can be achieved. 7.2.4.4 Smelter/Simple Extruder Model In this model, the exact days a specific product should run on a smelter as well as the desired throughput is determined. The smelter throughput specifies how many tons of product go through the smelter per hour. In addition, the extruder assignment for all extruders connected to only one smelter is optimized. For this model, several penalties multiplied by their corresponding variables are minimized in the objective function. These penalty values are set by trained users. Several profiles were developed, enabling a user to choose a profile depending on which penalties he or she would like to emphasize. For example, the user can choose a profile with high penalty cost for not fulfilling demand or a profile in which smooth production is the most important goal. Because adjustments to the smelters are costly (both in terms of changing melts and throughput adjustments), the number of smelter setups as well as the number and absolute volume of smelter throughput changes are penalized. There is a target value for the smelter production and the difference to this value is penalized. Further, a penalty exists for going below a target campaign length of a product on a melter or extruder. Products can often be produced on more than one extruder. There is usually a desired extruder for production, which is given priority 1. Less favorable extruders are given priority 2 or 3 and production of the product on these extruders will incur a penalty cost. In addition, penalty values exist for the number of days an extruder remains idle as well as early production leading to storage costs. The objective function includes the number of smelter setups, the number of smelter throughput changes and the number of production days using less favorable machines. Initial conditions must be considered to ensure the correct setups and throughput adjustments of the smelters and extruders at the beginning of the planning horizon. Here, the previous planned values for the time frame directly before the new plan begins are used. If production does not follow plan, the actual values are used. Calendar information is also considered. No production should take place on a smelter during a day defined to be “idle” and smelter setups may only take place on specially defined setup days. Further, smelter and extruder throughputs must lie within their upper and lower bounds. Logical constraints to be met are, for example, the amount of melt used by the extruders must equal the amount produced by the smelters and at most one melt can be produced per smelter and day. A setup takes place each time a new product is produced on the smelter and product balance constraints are fulfilled.

7.2 Chemical Case Study

141

7.2.4.5 Extruder Model This model determines the optimum assignment of products to complex extruders and reoptimizes the throughput of the attached smelters. From the solution we know which products will be produced on which of the complex extruders on which days using which throughput. In addition, the solution contains optimized melt information for the attached smelters. The objective function of the optimization problem contains several components to be minimized. In addition to the penalty values listed above for the Smelter/Simple Extruder model, some penalty values are required for this specific model. Here, there is a penalty for the number of extruder setups and throughput changes as well as the total absolute volume of extruder throughput changes. The Extruder Model has constraints analogous to the Smelter/Simple Extruder Model. In addition, the mix relationships of the products must be taken into account, since these products are formed using more than one melt. There are also constraints which ensure that products are allowed to be produced only when the correct melts are in the smelters. 7.2.4.6 Checker A checker was developed in order to enable a planner to compare plans. Here, a planner can modify an optimizer plan and use checker results from both plans to identify strengths and weaknesses of the plans. Checker results are displayed as key figures in tabular form. These can be saved to a file in order to compare several solutions. Several KPI and other information were displayed, including the following: • • • • • •

Total amount of demand not met by the plan Total amount of goods produced using priority 2 resources for the product Total amount of goods produced using priority 3 resources for the product Total amount of unused smelter capacity (per smelter) Number of days a smelter is not used (per smelter) Number of days an extruder is not used (per extruder)

After running the checker, the planner decides whether to save or discard the plan and corresponding checker results. 7.2.4.7 User Interface In order to view the results more efficiently, a special graphical user interface (GUI) was developed. Our experience has been that a well-designed user interface greatly increases end-user acceptance. The user interface in this case provides the following functionality: •

load data

142

• • • •

Customized Optimization Solutions

optimize save and load solutions check send results to SAP APO

Further, the GUI enables a planner to view the results in a way which makes sense for the problem. The planner chooses the location for which he or she would like to see results. In the top half of the screen, the smelter results are displayed. Below these the extruder results are displayed. Zooming capabilities allow the planner to view results over a one week, one month or three month timeframe. The planner has the ability to modify a solution, run the checker on the modified solution and save the results if desired. Several of the desired GUI features were not possible using the standard PP/DS planning table. These include viewing the melt information in the top half of the planning table and the corresponding extruder information in the bottom half. In addition, starting the checker and viewing results would not be possible using standard SAP APO PP/DS. 7.2.5 Conclusion The implementation of this project was completed in November 2003 and the planning process has been in use since that time. In addition to the overall project manager, an optimization specialist, a user-interface developer and an integration specialist were involved in the cartridge portion of the project. In June 2005, another area went live with a slightly modified version of this cartridge using the overall planning scenario. User acceptance is high. One reason for this is the specially developed user interface and Checker, which enable users to modify an optimized plan in the GUI and to validate this modified plan as well as compare it to the original optimized plan.

7.3 The Future These case studies provide examples of successful implementations of optimization extensions which are fully integrated into a standard software environment. Through the development of a customer-specific optimizer, the best possible fit to the customer’s requirements can be achieved. Further, the optimizer can be fully integrated into the customer’s planning process. Through the judicious choice of optimization extensions and standard planning functionality, the advantages of both areas can be exploited and a more efficient overall planning scenario can be achieved.

8 Operative Planning in the Process Industry

In this chapter we discuss a multi-location, multi-period planning problem of deriving production plans for a network of multi-purpose chemical reactors. The full problem included finding optimal strategies in time and capacity for opening or closing down reactor facilities; however, as this a beyond the capabilities of SAP APO we do not consider this feature here but refer the reader to Kallrath (2002, [50]). Although this production planning case study focusses strongly on the MILP model it describes a typical case in which a complete optimization solution has been implemented in industry prior to the introduction of SAP APO. The questions then arises whether it is possible to replace the system by SAP APO or to interface it as a tailored model. In order to do so, we add appropriate SAP APO related comments at the various parts of the model. In addition, this case provides a good example of what is needed in terms of documentation if a model external to SAP APO is to be developed or maintained.

8.1 Problem Description A company produces six products at four production sites. The production uses five different raw materials. At two of the sites it runs a multi-purpose reactor which can produce in three different modes. The finished products are sold from seven sales points. Years ago, in the time when SAP and SAP APO where not yet so popular the company developed a MILP based optimization model. The model was implemented in Dash’s modeling language mp-model and using the associated solver mp-opt – both are part of Dash’s optimization package Xpress-MP1 . The optimization model enabled the planner to create production, distribution, logistics and inventory plans based on user defined customer and market 1

Xpress-MPTM is a registered trademark of Dash Optimization (http:/www.dashoptimization.com).

144

8 Operative Planning in the Process Industry

information while observing all relevant supplier, production, distribution, inventory and customer constraints. Demand usually means aggregated demand over a product for several customers; in some cases a demand can represent a single customer. The overall objective was to maximize the companies total revenue for a one years planning horizon. In addition, the following objectives were considered: 1. Maximize contribution margin for the fixed design. No reactors will be opened or closed. 2. Maximize the contribution margin while guaranteeing a minimum percentage of demand to be met. 3. Minimize costs while satisfying full demand. In order to avoid feasibility problems a sufficient amount of external purchase should be allowed for. 4. Maximize total sales neglecting costs. 5. Maximize net profit. This includes opening and closing reactors as described in Kallrath (2002,[50]). 6. Multi-criteria objectives, e.g., maximize profit and minimize transport costs. 7. Maximize total production for the fixed design. No reactors opened or closed. 8. Maximize total production of products for which demand exists for the fixed design. No reactors opened or closed. 9. Maximize revenue. In this list of objective functions the following cost terms were considered: production, mode changes, raw material, external vendor-specific product purchase, transport and inventory. The optimization model enabled the human planner to create production, distribution, logistics and inventory plans based on user defined customer and market information while observing all relevant supplier, production, distribution, inventory and customer constraints. The problem was modeled based on 12 time slices (each one had a length of one month). In Section 8.2 the MILP model and its solution approach is described. Using this model, the following solution was obtained, for instance. ===================================================== Name of this scenario

NiceCompany

TURNOVER (REVENUE)

174727273

Objective Function Scenario Objective Function Value

9 174727273

COSTS

8.1 Problem Description Variable Production Purchase of raw materials linear cost nonlinear cost fix and penalty cost global, across period start-up/cancellation Transport: between demand points Transport: sites to demand points Transport: between sites Change-over cost Inventory: demand points Inventory: sites Inventory: rented (in/out) Inventory: throughput cost Inventory: working capital transit Inventory: one time cost Inventory: disposal cost Product purchase Unbalanced Product Swap Cost Delay cost TOTAL COSTS (excl. design cost)

97192020 24827824 23825324 0 0 1002500 0 0 231732 75953 575000 3514 261704 0 0 0 0 0 11429720 0 0 134597467

TOTAL COSTS (incl. design cost)

134597467

(Partial) NET PROFIT and CONTRIBUTION Contribution Margin

40129806

TOTAL NET PROFIT and CONTRIBUTION PRODUCTION (mass unit) production at SITE 1 6705 production at SITE 2 10168 production at SITE 3 62445 production at SITE 4 38222 Total production over all sites 117540 Total external purchase demand p. 0 Total external purchase sites 13460 Total flow of raw materials Total use of raw materials

0 41146

Total Total Total Total Total Total

51425 66115 19909 46206 0 46206

charged between reactors charged to tanks used from tanks net operative flow -> tanks net logistic flow -> tanks net product flow -> tanks

PLANT SYSTEM (days)

145

146

8 Operative Planning in the Process Industry Days available during horizon Days mode reactors were active Days needed for change-overs Number of change-overs change-overs at SITE 1 Plant system utilization rate

1260 414 50 50 0 1.55

TRANSPORT RESULTS (mass unit) total amount shipped (mass unit)

61537

INVENTORY STATUS (mass unit) total initial stock total at the end of the horizon

2250 2250

total initial stock (raw mater.) total end stock (raw material) DEMAND STATUS (mass unit) Total demands requested Total demands satisfied Total demands unsatisfied

1950 450

55858 46346 9512

=====================================================

In Section 8.3 we provide an SAP APO view on this problem.

8.2 A Tailored MILP Model The basic objects of the model are: 1. products p: this includes raw materials, intermediates, finished products and salable products 2. modes m: the reactors of the multi-stage production scheme may operate in several modes, also called production modes, described by a general product-mode relation. The reactors are subject to sequence-dependent mode changes; one-to-one relations between products and modes are treated as special cases 3. production sites s (plants): place where production and storage is possible . . .have set of reactors for the multi-stage production 4. demand or sales points d: place where sales demand is generated and storage is possible and from which products are sold 5. reactors r: have attributes such as capacities (tons/day), minimum utilization rate, they obey topological relations 6. inventories i: site inventories and demand point inventories; demand point inventories may be dedicated tanks, variables tanks or containers. Inventories can be located at production sites, demand points or storage sites,

8.2 A Tailored MILP Model

147

i.e., places where storage is possible. This maps to the model’s concept of production site. This is needed for the interface to handle the possibility of creating a location that only contains a group of tanks (or storage entities) that is connected to production sites and demand points by transport. This could be a tank terminal or an off site warehouse for example that receives rail and ship shipments from production sites and ships out trucks to demand points. 8.2.1 Basic Assumptions and Limitations of the Model The model is based on the following assumptions and limitations: 1. For exact modeling of sequence-dependent mode changes, one has to observe that only one mode change per period is permitted. This assumptions seems not to be a very serious restriction since a period has a length of a month and typically only one setup-change per month occurs. 2. Transport times are treated exactly if the time for transport corresponds to the discretization chosen for time or is smaller than the length of time slices. If this is not the case shipment amounts are treated probabilistically (Kallrath 2002c, [50, Section 4.3]). In even longer-term scenarios transport time should be neglected. 3. Only variable inventory costs are considered. They are based on capital bound and interest rates, or operating costs. 4. Production utilization rates and associated constraints refer to utilization per production time slices. 5. In order to support net present value considerations all cost related data are discounted over time with a discount rate of p%. Discounting is only applied in the design scenario. 6. Multi-mode inventory entities are modeled on the assumption that only one product can be stored; the change to another product be stored happens in zero time; cost for changing products in a tank are only considered in the post-optimal analysis. 8.2.2 General Framework of the Mathematical Model 8.2.2.1 Indices Throughout this model description the following set of indices will be used: b c d h i k

∈B ∈C ∈D ∈ Hsrpm ∈I ∈K

:= {1, . . . , N B } := {1, . . . , N C }

: : : H := {1, . . . , Nsrpm }: := {1, . . . , N I } : := {1, . . . , N K } :

break points (nonlinear price structure) sales categories demand points remaining shelf-life time inventory entities or tanks production periods

148

8 Operative Planning in the Process Industry

m ∈ Msr o ∈O p ∈P r ∈R s ∈S t ∈T v ∈V w ∈W y ∈Y

:= {1, . . . , Msr }

:= {1, . . . , N T }

: : : : : : : : :

modes (depend on site and reactor) origins, Odpcw feasible origins for a demand products reactors production sites / plants commercial periods (sales periods) vendor (supplier) packing or wrapping types transport means

8.2.2.2 Index Sets and Indicator Tables For some constraints it is useful to consider the sets r ∈ Rs and p ∈ Ps of reactors products at site s. Ps can be realized by the indicator table
 1, if product p is produced on reactor r at site s SRP Isrp := 0, else which also gives the scheme for how all indicator symbols are named; similarly, SR SRP P Rs is represented by Isr . Isrp is derived from the production rates Rsrmp as ⎫ ⎧

⎨ +1 , x > 0 ⎬  SRP P 0,x=0 . with sign(x) := := sign −1 + Rsrmp Isrp ⎭ ⎩ −1 , x < 0 m∈Msr Another indicator table we use is
1, if reactor r at site s is subject to mode-changes MCR Isr := 0, else

 .

MCR If we would use Isr as an input table it would tell us whether a reactor MCR is subject to mode changes. Alternatively, we might derive Isr from the P production rate table Rsrmp as ⎞ ⎛ M sr   ⎜ ⎟ MCR P := sign ⎝−1 + Rsrmp Isr ⎠ ; m=2 p∈P |RP >0 srmp

note that the sum covers m = 2 and higher, because any reactor has at least P also helps us to define the set Msr mode m = 1. The production table Rsrmp ⎧  ⎫ ⎨   ⎬    P  P Msr := m  Rsrmp > 0 = m  ∃p ∈ P Rsrmp >0 . ⎩  ⎭ p∈P However, we still keep numerical indices for m, i.e., Msr := {1, . . . , Msr }.

8.2 A Tailored MILP Model

149

RM The indicator table Isp tells us whether product p is a raw material. The P ipi indicator table Isrpi


P ipi Isrpi :=



1, if at site s reactor r can extract product p from inventory i 0, else

P ipo establishes the topology. Similarly, we introduce an indicator table Isrpo


P ipo Isr

:=

1, if at site s reactor r can charge product p to inventory i 0, else



Finally, we define the reactor-pre product table ⎞ ⎛ M sr   PP ⎝ Rsrmp
p ⎠ Isrp
= sign m=1 p∈P |p=p


indicating whether reactor r at site s uses the product p as a pre-product at PP all; Isrp
is derived from the product-recipe table Rsrmp
p . EIN V The table Idp indicates whether there exist any inventory entity at EIN V demand point d which could store product p. Idp follows from EIN V Idp

= sign



CC Sdip

i∈I

The indicator tables allow us to define further subsets    ss < NK Ssdk := sd ∈ S sd = s ∈ S ∧ k + Tss d    ss Ssk := sd ∈ S sd = s ∈ S ∧ k > Tss , d    sd K Dsdk := d ∈ D k + Tsd < N ,    dd < NT Ddk := dd ∈ D dd = d ∈ D ∧ t + Tdd d

,

.

Another useful set is the set Odpcw of feasible origins associated with a specified demand Ddpcwt . If no demand attributes are specified we have Odpcw = O. For further details see Section 8.2.3.9. 8.2.2.3 The Problem Data The problem data are transferred as 78 ASCII files declared as sparse tables: P Sdpt Ddpcwt ED Pdpt ES Pspk

salesp demand extplims extplimd

sales prices in $/ton demands in tons external purchase limits (tons) external purchase limits (tons)

150

8 Operative Planning in the Process Industry

ED Cdpt ES Cspk CsB CsBA F IX Csr O Csr SD Csr SDA Csr A Ddp DtP Ddpcwt ∆srm ∆F srmk C Msr F Msr Msr T Msrm 1 m2 M Psp PsS SC Psp SP Pspk SP Psk P Rsrp P M CR Rsrmp P min Rsrp U min Rsrp CR Sspk CE Ssp CC Ssp CM Ssp CT Ssspk CS Ssp PE Sdp PC Sdp PM Sdp PT Ssdpk PS Sdp P Tdd P Tsd C Tss PM Tdd PM Tsd CM Tss PD Tdpt

cstprchd cost for external purchase in $/ton cstprchs cost for external purchase in $/ton cstbuy total cost for buying a plant cstbuya annual cost for buying a plant cstfix fix cost to operate a reactor cstopen total cost for opening a reactor cstsd total cost for shutting down a reactor cstsda annual cost for shutting down a reactor dmndattr demand attribute timedpp days per commercial period demforce force demand to be satisfied prodstrt initial state of all reactors of all plants planfix fixed states of all reactors (derived from previous run) chngmax max. number of mode changes on reactor r at site s chngnot forbid mode changes on reactor r at site s in period k nummodes number of possible modes on reactor r at site s chngtime time needed for mode changes on reactor r at site s minprc s-c minimum production requirement of products minpri minimum production requirement for each site minpric minimum production requirement per site & product minprick min. production requirement per site, product & period minprik min. production requirement per site & period prodrate production capacity of reactor r at site s for product p prodratM prod. cap.: reactor r, site s in mode m for product p prdminr min. production requirement for reactor r at site s produtil min. % production utilization for reactor r & product p invrmax capacity of additional product stock invrend minimum requirement of product stock at end invsmax capacity of stock of products invsmin safety stock at site inventories trpastss transport originating before first period invdini initial stock of site inventories invdend minimum requirement of product stock at end invdmax capacity of demand point inventories invdmin safety stock of demand point inventories trpastsd transport originating before first period invdini initial stock of demand point inventories trtmdd transport times between demand points trtmsd transport times between sites and demand points trtmss transport times between sites trmindd minimum transport requirements of products trminsd minimum transport requirements of products trminss minimum transport requirements of products trpastd transport from past

8.2 A Tailored MILP Model PS Tspk F Tdp Ust

trpasts cifprice timeslic

151

transport from past specifies who pays freight number of production time slices in period t

In addition the problem is characterized by the following control parameters: DtP IFKTO ND N K , NsK N M , NsM NP NS OBJT Y P E

: : : : : : : :

days per commercial period flag: keep track of origins number of demand or sales points number of production time periods, at site s maximum number of modes occurring at any site, at sites s number of products number of productions sites type of objective function

Most of these control parameters are fixed once. Some others are computed automatically by the user interface as a function of the data. 8.2.2.4 Time Discretization The time discretization allows the user to adjust the planning horizon and its resolution to his or her needs. There are only a few input steps to be followed: 1. The planning horizon is divided into N T (commercial) time slices. Note that N T does not depend on location. 2. The next step is to assign a number of dates to each time slice. In the simplest case this number is the same for all locations. 3. To model sequence-dependent mode changes for each site separately, the commercial time slice can be divided into any number of production time slices. This allows for different numbers of production periods for each N T if desired. 4. The user interface reports the calender time for each commercial and production time slice. We divide the entire planning horizon (case period) into N T time slices. Typical we consider 12 months planning periods which equate to a year plus, or a quarter of a year, respectively. The time slices can be of different length. The starting point and length of the planning horizon (case period) can be chosen by the user using calendar dates or Julian dates. Each commercial time slice t is supposed to have a length of DtP days. For each site and commercial time slice we define Ust production time slices with equal length. We divide the entire planning horizon into NsK production time slices of DtP /Ust days, where Ust is the number of production time slices embedded in that commercial period. Regarding delivery or sale, usually a commercial time scale of 12 periods (months) is chosen. Note that there is not a hard-wired structure which would restrict us to 12 commercial periods. A possible scenario is, for

152

8 Operative Planning in the Process Industry

instance, to cover a production plan with 16 periods: the first 12 with a length of about 30 days, and four additional ones with length of 120 days. Thus the production plan would cover a total time of two years. In most cases, the production schedule has a finer resolution than the commercial plans for sales and shipping. Using two time scales, the resolution is chosen adequately for the purpose of both production planners and marketing people. The function
0 , if t = 1 ks (s, t) := ks (s, t − 1) + Ust−1 , if t > 1 gives the number (minus one) of the production time slice starting at the beginning of commercial period t at site s, and, with ks referring to a production time slice embedded in the commercial time interval t, k(s, t, u) := ks (s, t) + u gives the absolute number k(s, t, u) of that production time slice within the production time scale referenced by t and r at plant s, and connects both time scales. For abbreviation, if sums cover the whole planning horizon, we use k rather than k(s, t, u). Note that NsK = k(s, N T , UsN T ) for all s. If the production time scale and the commercial time scale are identical, we have Ust = 1, and k := k(s, t, u) = t. The different time scales embedded allow us to have smallest time slices relevant to production which may be of the order of just a few days while the commercial periods may cover even a few years. The inverse function, tk (s, k), returns the commercial period to which the production time slice k at site s belongs to. It can be expressed in terms of the function ks (s, t) defined above: tk (s, k) = the smallest t with ks (s, t) < k ≤ ks (s, t) + Ust = arg min {t|ks (s, t) < k ≤ ks (s, t) + Ust } . t

Scenarios different from the 12 month scenarios are possible. As a first example we discuss the case of a 5 years planning horizon in which the commercial data are available on an annual basis and the production should be considered with a fineness of one month. In that case we have: N T = 5;

DtP = 360

∀t;

Ust = 12 ∀{st}

In a second example focussing more on asset evaluation the time horizon covers 10 years with 2 production time slices per year which leads to N T = 10;

DtP = 360 ∀t;

Ust = 2 ∀{st}

Note that the production rates should be entered as tons/day, times for mode changes and period reduction times in days. Let us summarize all the changes in input table which become necessary if Ust is changed:

8.2 A Tailored MILP Model

153

1. the number Ust of production time slices per commercial period t needs to be defined for all t 2. the sales price and demand table need to be adjusted and defined according to N T 3. the transport table for transport between demand points needs to be adjusted and defined according to N T 4. the transport table for transport between sites or from sites to demand points need to be adjusted and defined according to NsK 5. the availability table for external product purchase needs to be rescaled, i.e., the amount of externally purchased product available must really match what you can get in DtP /Ust days 6. all tables including data depending on production time slice k need to be complete, or at least specified for k = 1 7. the first-opening possibility table for reactors has to be adjusted to account for that k might have a different meaning for this time discretization 8. the break-point volumes in the nonlinear pricing scheme of the product purchase has to be adjusted (it has the units mass units/length of production time slice) In order to support net present value considerations all cost related data are discounted over time with a discount rate of p%., i.e., if C1 denotes the cost applicable to the first time slice, then the cost, Ck and Ct , for the production and commercial time slices are given by  Ck = C1 / 1 +

p k−1 1200

;

∀k ≥ 2

and

 p t−1 Ct = C1 / 1 + ; ∀t ≥ 2 . 100 This discounting scheme is only considered in the design scenario (OBJTYPE=5) but not in the short term scenarios. 8.2.2.5 The Concept of Modes

The concept of modes developed for this application is suitable to model the production of multi-purpose plants frequently used in the food or chemical process industry, or to model strategic design decisions of opening or closing units as described in Kallrath (2002, [50]). In each mode such a reactor can produce several products according to free or fixed recipes (joint production, co-production) leading to a general mode-product relation described by a set of yield coefficients: in a certain mode several products are produced (with different maximum daily production rates), and vice-versa, a product can be produced in different modes. Mode changes correspond physically, for instance, to a change of the temperature or pressure of a reactor, put the reactor in a new feasible mode and result in a considerable loss of production

154

8 Operative Planning in the Process Industry

time, which in our case is sequence-dependent, and are modeled as a proportional lot sizing and scheduling problem (PLSP, Domschke et al., 1997, [20, p.150]), i.e., based on discrete-time formulation with at most one setup- or mode-change per period; see also Kuik et al. (1994, [63]) for a survey on lot sizing problems. Each reactor has its own set of modes. That is reflected by the symbol ∀m ∈ Msr in Sect. 8.2.3.1. Let us give a simple example with one site only (not shown in the table), two reactors with two and four modes, and three products to illustrate the flexibility of the concept of modes. The relevant input quantity associated with the modes is the mode-dependent production P rate, Rsrmp , also called yield coefficient and usually specified in tons/day. P Note that (8.16) allows to produce at rates smaller than Rsrmp . reactor mode product P Rsrmp

R1 1 P1 90

R1 2 P1 80

R1 2 P2 15

R2 1 P1 85

R2 R2 2 3 P2 P1 70 60

R2 3 P2 22

R2 4 P2 55

P1 and P2 are produced on several reactors. P1 is produced on R1 and R2 in two modes. Mode 1 on R1 corresponds to exactly one product, P1, while mode 3 on R3 allows two products to be produced. Note that mode 1 and 2 on R1 are different from mode 1 and 2 on R2. For modes allowing more than one product produced at a time, one needs to check whether the permissible products are produced in fixed-ratio co-production or at independent variable or free rates. 8.2.2.6 The Variables Here we give an overview on the variables. For convenience, some of the definitions will be repeated when we discuss the constraints. A group of non-negative (continuous) variables describes the production pA sp pD srr
pk pP srpk pPM srpmk pT srpk pU srpk uSsrpk

: : : : : : :

aggregated production (in tons) of product p at site s amount of product p charged from reactor r to r in period k production (in tons) of products p on reactor r in period k production (in tons) of products p on reactor r in mode m amount of product p charged from reactor r to local tank amount of product p used (converted) on reactor r in period k amount of product p reactor r takes from storage in period k

For mode-changing reactors (MCRs) we need to know how many days we spent in a mode m during the period k. This quantity is described by the non-negative continuous mode-duration variables mD srmk : time (in days) reactor r at site s is in mode m during period k

.

8.2 A Tailored MILP Model

155

The current modes and states of the MCR-reactors (selected by the condition MCR Isr = 1) are traced by the state variables δsrmk ∈ {0, 1},
1 , if reactor r at plant s is in mode m at the end of period k . δsrmk := 0 , otherwise In order to describe sequence-dependent mode changes we introduce additional binary variables with the following meaning   MCR 
1 , if δsrm1 k−1 = δsrm2 k = 1 ∀ sr Isr =1 ξsrkm1 m2 = ; 0 , otherwise ∀m1 , m2 ∈ Msr , ∀k
1, if reactor r is in mode m for some time in period k (8.1) αsrmk := 0, otherwise
βsrmk :=

1, if mode m is started at the MCR-reactor r in period k (8.2) 0, otherwise




1, if mode m is terminated at the MCR-reactor r in period k 0, otherwise (8.3) and finally the binary variable χsrk
1, if a mode-changed occurred on reactor r in period k χsrk := 0, otherwise γsrmk :=

indicating whether a mode change occurred on reactor r at site s in period k or not. To trace the stock we use the non-negative continuous stock variables sSspk : stock (in tons) of product p at site s at the end of period k sD dpt : stock (in tons) of product p at demand point d at the end of period t sR dpt : additional or rented stock capacity of product p at demand point d The stock variables are generated only if a maximum capacity entry exists for the index combination sp. In addition we have the dimensionless, non-negative semi-continuous transport variables dd  σdd
pt : amount of product p shipped between demand points d and d sd σsdpk : amount of product p shipped from site s to demand point d ss  σss
pk : amount of product p shipped from site s to site s

Finally, we need some non-negative semi-continuous variables (in tons) describing the sales of end-products and the purchase of products from external suppliers (vendors or even competitors)

156

8 Operative Planning in the Process Industry

sLdpcwot : sales of product p from origin o at demand point d : external purchase of product p from vendor v in period k at site s pES spvk : purchase of product p from vendor v in period t at demand point d pED dpvt (8.4) In addition, we might want to use the sales variables sLS dpicwot where the additional index i indicate from which storage entities the amount of product p is extracted. Note that the sales variables are only generated for consistent combinations of the indices d, p, and o. The external purchase variables are subject to an upper limit. If in addition a lower limit is specified they are interpreted as semi-continuous variables, i.e., ELL EUL pE ≤ pE p = 0 or pp p ≤ pp

This allows us to model the situation in which a vendor or competitor is willing to provide support but asks for a minimum quantity to take if support is offered. Note that most of the variables are not needed for all combinations of indices but rather for a few combinations indicated by some logical qualifiers; therefore we refer to these variables as sparse variables. Let us assume that the modeling language keeps track automatically of sparse variables appearing in constraints. Thus, we give the logical qualifiers only at the first instance the variable occurs in this report and we do not repeat them in the formulation of constraints. 8.2.3 The Mathematical Model – the System of Constraints 8.2.3.1 Modeling the Production Modeling production involves the concepts of multi-stage production, joint production (co-production) and mode-changes. Note that all reactors have an index for mode changing. If a reactor cannot undergo mode-changes then it MCR has just the index m = 1 in the list; the table Isr indicates whether reactor r at site s is a mode-changing reactor, i.e., has more than one mode. In any case, for production, the following data are needed: DtP Hsrk

timedpp

R Hsrm prodrdcp 1 m2 k

T1 Msrm chngtim1 T Msrm chngtime 1 m2 P Rsrmp prodrate

days per commercial period number of days available for production and possibly mode changes on reactor r at site s in period k number of days available for production on reactor r at site s in period k if a mode change from mode m1 to m2 occurs in period k time for a mode change to mode m time for a mode change from mode m1 to mode m2 production rates in tons per day, the amount of product p which could be produced in mode m in one day on reactor r at site s

8.2 A Tailored MILP Model P min Rsrp U min Rsrp RC Rsrmp
p FR Rsrmp 1 p2

prdminr produtil prdrecip prdfixrc

157

min. production requirement of reactor r at site s min. production utilization of reactor r in percent recipe coefficient to convert p → p fixed ratio for joint production of p1 and p2

Notice that Hsrk depends on k which gives us the opportunity to model temP porary shutdowns (maintenance, test runs, etc.). The production rates Rsrmp will also be used to indicate whether product p can be produced on reactor r P at site s at all. If Rsrmp = 0 this is not possible. It is possible that a certain product can be produced in several modes. For mode-changing reactors we set    MCR   =1 ∀ sr Isr R T Hsrm1 m2 k = max 0, Hsrk − Msrm1 m2 (8.5) ; ∀m1 , m2 ∈ Msr , ∀k where by definition T Msrmm =0 ,

  MCR  ∀ sr Isr =1

;

∀m ∈ Msr

.

(8.6)

R Note that Hsrk or Hsrm is not required to be an integer quantity. 1 m2 k We will now first describe the mechanism of mode-changes, and in a later sub-section multi-stage production scheme.

8.2.3.2 Modeling Mode-changing Reactors Reactors subject to sequence-dependent mode-changes are characterized by the state variables δsrmk ∈ {0, 1},
1, if reactor r is in mode m at the end of period k δsrmk : = (8.7) 0, otherwise, i.e., in any other mode  MCR = 1 , ∀m ∈ Msr , ∀k ∈ K . ∀s ∈ S , ∀r ∈ Rs Isr These variables can be used to guarantee that at the end of time interval k reactor r at site s is in a unique mode, e.g., by equations of the form ∀s ∈ S  MCR =1 δsrmk = 1 ; ∀r ∈ Rs Isr m=1 ∀k ∈ K M sr 

.

(8.8)

However, as will become obvious below, it is not necessary to add the equations explicitly to the systems of constraints. Note that some initial data ∆srm = δsrm0 have to be provided to define the known status of reactor r at plant s before we start planning. Of course, these initial data must satisfy the condition M sr  m=1

∆srm = 1 ;

  MCR  ∀ sr Isr =1

.

(8.9)

158

8 Operative Planning in the Process Industry

Exploiting Fixed Setup Plans Sometimes the state of all plants may be given in advance, and one may want to fix the states of all plants to the states known from another optimization run. Therefore, the model provides the option to use the states of all plants according to the bounds   MCR  δsrmk = ∆F ; ∀ sr Isr = 1 ∧ I∆ = 1 , ∀m ∈ Msr , ∀k srmk where ∆F srmk give the states of all reactors of all plants during the whole period TP and I ∆ is a switch specifying whether a fixed plan is to be used (I ∆ = 1) or not (I ∆ = 0). This switch, the default is I ∆ = 1, allows fixing the setup while all other variables can be optimized with respect to the fixed modes. Keeping Track of Mode Changes It is one of the most fundamental assumptions in this model that we can have at most one mode change per period. If the states variables take the values δsrm1 k−1 = δsrm2 k = 1 we have a mode change from mode m1 to m2 in time interval k. Both the continuity of modes and mode changes are traced by the binary variables  MCR
1 , if δsrm1 k−1 = δsrm2 k = 1 ∀{s ∈ S , r ∈ Rs Isr = 1} ; ξsrm1 m2 k = 0 , otherwise ∀m ∈ Msr , ∀k ∈ K This variable is unity if at the end of period k − 1 reactor r of plant s is in mode m1 and at the end of period k it is in mode m2 . ξsrkm1 m2 is a variable not only describing whether a change-over occurs or not but it tells us whether production continues. If the reactor is in mode m both at the end of period k − 1 and k then we have ξsrkmm = 1. The state variables and the mode-changes variables will now be coupled by some additional binary variables:
1, if reactor r is in mode m for some time in period k αsrmk := (8.10) 0, otherwise
βsrmk :=

1, if mode m is started on reactor r at site i in period k 0, otherwise

and finally
1, if mode m is terminated on reactor r at site i in period k γsrmk := 0, otherwise

,

.

These binary variables are related to the mode changing variables by the constraints    MCR  βsrmk = ξsrkm1 m ; ∀ sr Isr = 1 , ∀m ∈ Msr , ∀k m1 ∈Msr |m1 =m

8.2 A Tailored MILP Model

and γsrmk =



ξskmm1

;

  MCR  ∀ sr Isr =1 ,

159

∀m ∈ Msr ,

∀k

.

m1 ∈Msr |m1 =m

To express whether mode m is used at all in period k we have    MCR =1 ∀ sr Isr αsrmk = δsmk−1 + δsrmk − ξskmm ; ∀m ∈ Msr , k = 2, . . . , N T

,

and αsrm1 = ∆srm + δsm1 − ξs1mm

;

  MCR  ∀ sr Isr =1 ,

∀m ∈ Msr

, (8.11) denotes the known status of reactor r at plant s before

where ∆srm = δsrm0 we start planning. Note that it is not necessary to declare ξ, β and γ as binary variables if we have declared δ and α as binary variables. Finally we have the following block of constraints: γsrmk = δsrmk−1 − ξsrkmm

  MCR  ∀ sr Isr =1 ,

;

∀m ∈ Msr k = 2, . . . , N T

,

or γsrm1 = ∆srm − ξsr1mm

;

  MCR  ∀ sr Isr =1 ,

∀m ∈ Msr

,

and βsrmk = δsrmk − ξsrkmm

;

  MCR  ∀ sr Isr =1 ,

∀m ∈ Msr k = 2, . . . , N T

.

The constraints above complete our description of mode changes as far as the binary variables are concerned. Now we can also see why (8.8) is not required any longer. This follows from (8.9) and inspection of (8.11)      MCR  αsrm1 = 1 + δsrm1 − ξsr1mm ; ∀ sr Isr =1 . m∈Msr

m∈Msr

m∈Msr

 If in the first period a setup-change takes place then m∈Msr ξsr1mm = 0 but  αsrm1 = 2 since production is possible in exactly two modes. Thus m∈Msr we have m∈Msr δsrm1 = 1. If no setup-change occurred then production was  possible in only one mode which gives α = srm1 m∈Msr m∈Msr ξsr1mm = 1  which again leads to m∈Msr δsrm1 = 1. For convenience we also introduce the variables   MCR  C F ∀ sr Isr = 1 , ∀k | Msr < N K ∨ Msr =1
1, if a mode change occurred at s in k χsrk : = 0, otherwise

160

8 Operative Planning in the Process Industry

indicating whether a mode change occurred on reactor r at site s in period k or not. Note that the variables are only generated for those reactors r at C sites s for which Msr < N K , i.e., the maximum number of mode changes on reactor r at site s is smaller than the number of periods, or mode changes are F forbidden completely in period k, i.e., Msr = 1. The binary variables χsrk are related to ξsrm1 m2 k by   χsrk = ξsrm1 m2 k ; m1 ∈Msr m2 ∈Msr ,m2 =m1

 MCR   C  F ∀ srk Isr = 1 ∧ Msr < N K ∨ Msr =1

.

The total number of mode changes during the entire production period on reactor r at site s can be restricted by K

N 

C χsrk ≤ Msr

;

  MCR  C ∀ sr Isr = 1 ∧ Msr < NK

.

(8.12)

k=1

It is also possible to forbid mode changes on reactor r at plant s in period k by adding the lower bound    MCR F F χsrk ≤ 1 − Msr ; ∀ sr Isr = 1 ∧ Msr =1 ∀k . Mode Capacity Constraints The mode-duration variables mD srmk ≥ 0 number of days on reactor r plant s in period k is in mode m tell us the number of days (fractional days are allowed) in which the reactor is in mode m during period k. Let us now start to formulate the mode capacity constraints as a function of the change-over variables restricting the number of days the plant is in a certain mode. We first note that (8.13) R mD srmk < Hsrmmk αsrmk

;

  MCR  ∀ sr Isr =1 ,

m ∈ Msr ,

∀k

(8.13)

is a valid upper bound. Remember that αsrmk carries the information whether mode m is used in period k or not. If the plant is never in mode m during period k then αsrmk = 0 and the plant indeed spends zero days in mode m. If mode m is chosen in some period k, i.e., αsrmk = 1, the inequality reduces to mD srmk < Hsrk due to (8.6). Fractional values of αsrmk during the LP relaxation or within the tree reduce the time the plant can be in mode m leading to smaller amounts of the products being produced in this mode. Next, we want to compute the available capacities subject to mode changes. These constraints read mD srmk

≤

M sr  m2 =1

R Hsrm 2 mk

ξsrkm2 m +

 MCR  ∀ sr Isr =1 , 

M sr 

R Hsrmm ξsrkmm2 2k

m2 =1|m2 =m

∀m ∈ Msr ,

∀k

(8.14)

8.2 A Tailored MILP Model

161

and for ∀{srk} M sr 

mD srmk ≤ Hsrk −

m1 =1|Hsk =0

M sr 

M sr 

∆srm1 m2 ξsrkm1 m2

.

m1 =1|Hsk =0 m2 =1|m2 =m1

(8.15) Constraint (8.14) defines the upper limit on the number of days of production of product p on reactor r at site s in period k as a function of the mode changing variables. Days for mode m become available in period k only if either the reactor status switches to mode m in period k [first term in the right hand side of (8.14)] or the site status switches from mode m in period k (i.e., has status m at the end of period k − 1). When the mode of the reactor is m at the end of period k − 1 and k (i.e., ξsrkmm = 1 and no changeover R occurs in period k), the value of the available capacity Hsrkmm is counted once in the first terms. In any integer solution, by constraint (8.14), at most two modes have a positive upper bound on available days in each period. The inequality (8.15) defines the global available capacity in period k to be equal to the number of days available minus the number of days used for mode change. The second term can only be applied if ∆srm1 m2 ≤ Hsrk . Otherwise, we should fix ξsrkm1 m2 = 0 because there is not enough capacity in period k to perform the mode change from mode m1 to mode m2 . Inspecting the variables and constraints depending on the index m, we see that we have, so far, 5M + M (M − 1) = M (M + 4) variables per reactor and per time slice; 2M of them are binary variables. There are 5M constraints. Coupling Modes and Production The mode-duration variables mD srmk are connected to the variable pP , srpk pP srpk ≥ 0 ,

tons of product p produced on reactor r at site s in period k

P . The indicator table by the production rates Rsrmp



SRP P := Rsrp + Isrp

P Rsrmp

;

∀ {srp}

P m∈Msr |∃Rsrmp

tells us whether product p can be produced at site s and reactor r at all. The number of days available per mode and tons of product p are connected by  MCR   =1 ∀ srm Isr P D (8.16) pPM ≤ R m ; srmpk srmp srmk ∀p ∈ P E ; ∀k and pP srpk

=

 sF >0 m∈Msr |Isrp

pPM srmpk

;

 MCR   =1 ∀ srm Isr ∀p ∈ P E , ∀k

.

(8.17)

162

8 Operative Planning in the Process Industry

Note that all (8.16)’s are inequalities. Even if the reactor is in a mode in which a certain product could be produced there is no need to produce at D full capacity. For reactors subject to design decisions (Isr = 1) we require in addition pP srpk ≤

M sr 

P Hsrk Rsrmp θsr

;

 SRP   MCR D ∀ srpk Isrp = Isr = Isr =1

P m=1|Rsrmp >0

8.2.3.3 Multi-stage Production A certain reactor r is connected in a just-in-time fashion to one (or possibly more) preceding reactors r . This topology is described by the indicator table T opo Isr which takes the value 1 if reactor r can charge to reactor r. Reactor r
r converts the product p produced by preceding reactors r into the product p, or possibly into several co-products. This product p can be taken just in time from the reactor r or from an intermediate storage space. The total amount of product p reactor r uses to produce p is therefore  S pD ; (8.18) pU srp
k = usrp
k + sr
rp
k T opo SRP r
|Isrr
>0∧Isr
p
=1

 PP  P ipi =1 ∀ srp Isrp
= 1 ∧ Isr 

,

∀k

,

PP  where Isr
p
indicates whether reactor r uses p as a pre-product at all, the SRP indicator table Isrp controls which reactors at site s can produce product p, and uSsrp
k is the amount of the preceding product p taken from the storage P ipi (if Isr = 1, i.e., if reactor r is –via pipeline– connected to the inventory and can extract material from that inventory). Note that uSsrp
k appears as a loss term in the stock balance equation (8.36). For p =P1 (8.18) reduces to    PP S P ipi pU ; ∀ sr IsrP = 1 ∧ Isr =1 , ∀k , (8.19) srP1 k = usrP1 k 1

because P1 is not produced on any reactor, and therefore SRP IsrP =0 1

;

∀{sr} .

To model raw material availability it has to be ensured in the input data that uSsrP1 k has no upper bound. Multi-stage production, i.e., the amount of product p produced on reactor r at site s is described by the recipes equations of the form    PP   RC PM U Rsrmp ; ∀ srpk Isrp .
p psrmpk = psrp
k
> 0 m∈Msr p∈P |I SRP >0 srp (8.20) It is a matter of taste whether we apply the recipe coefficient to p or p. In the case of (8.20) RRC means: in order to produce 1 mass unit of product

8.2 A Tailored MILP Model

163

p we need RRC mass units of pre-product p . Note that reactors in a given mode m may produce several products p simultaneously and that the recipe coefficients depend on modes. In addition to the multi-stage concept we also have to consider joint production. If the conversion of product p produces two products p1 and p2 in a fixed ratio, we have  FR   FR PM pPM ; ∀ srmp1 p2 ∃Rsrp >0 , ∀k , srmp1 k = Rsrp1 p2 m psrmp2 k 1 p2 m FR where Rsrp defines the mode-dependent fixed ratio between the produc1 p2 m tion of product p1 and product p2 . Modeling co-products or joint production can cover several real world situations: fixed recipe situation such as described in Kallrath and Wilson (1997, Sec. 5.1), situations in which the co-product is seen, for example, as waste water, for which a disposal cost has to be paid, or free recipes. Especially, for free recipes, capacities for the production of co-products have to be specified. If a co-product is produced and the co-product is a waste product, the conversion cost are interpreted as the cost of disposal. The solver will evaluate the sum of the costs of the primary out and the co-products to determine if it is worth while to produce the primary product. The concepts described so far apply for all reactors, especially also for the MCR-reactor. The equations also hold for separated chains of reactors at one T opo site. Note that the reactor topology is completely described by Isr
r . The amount of products producible on reactor r at site s in period k is P limited by the capacity Rsrp specified in tons/day, i.e., max pP srpk ≤ Psrpk

;

 SRP   MCR ∀ srp Isrp = 1 ∧ Isr = 1

,

∀k

,

(8.21)

max where Psrpk is the production capacity of reactor r in tons in period k. It is based on the following assumptions:

1. Production of product p is with respect to capacity completely separated from the production of other products. 2. The discretization is appropriate to model the just-in-time requirements. P There may be also a minimum requirement on pP srpk . Therefore, psrpk is a semi-continuous variable or subject to the disjunctive constraints, resp.  P   min max pP ∨ Psrp ≤ pP ; ∀ srp ∃Rsrp , ∀k srpk = 0 srpk ≤ Psrp

with min P min U min P Psrpk := Hsrk Rsrp = Hsrk Rsrp Rsrp

,

max P Psrpk := Hsrk Rsrp

.

(8.22)

For those reactors subject to opening or shut-down decisions or belonging to plants which might be purchased the capacity balance reads

164

8 Operative Planning in the Process Industry

pP srpk = 0

min max Psrpk θsr ≤ pP srpk ≤ Psrpk θsr  P   D ∧ ∃Isr ∀ srp ∃Rsrp , ∀k .

∨

;

(8.23)

The amount pP srpk of produced product p is charged to a local tank (site inventory) or charged to subsequent reactors. The distribution of products is described by the distribution equation    SRP   SLP pP pTsrpik + pU ∀ srpk Isrp = 1 = Isrp srpk = sr
pk ; P ipo i∈I|Isrpi =1

T opo r
∈R|Isrr
>0

where pTsrpik is the amount of product p charged to the tank (site inventory) by pipeline. The site-balance equation (8.24) for site inventories (also called local inventories) couples multi-stage production, intermediate storage space and transport (between sites, and between sites and demand points), i.e., ∀{spk}   S sSspk = sSspk−1 + Sˆspk − uSsrpk + pT srpk P ipi P ipo SRP r∈R|Isr =1 r∈R|(Isrp =1∧Isr =1)    mss ss msd sd mdd dd Tsd σsdpt−T dd − Tss σssd pk − Tsd σsdpt−T sd − d sd dd s∈S d∈D d∈D sdk sdk dk   mss ss mss ss + (1 − ωss sk ) Tssd σss spk−(1−π)T ss + ωss sk Tssd σss spk−π−(1−π)T ss ss ssd ss ∈S  d ES ss ∈S + pspvk v∈V

(8.24) ES p describes external purchase opportunity at site inventories. Note v∈V spvk that (8.24) supports a soft coupling of both reactor chains. Of course, if no intermediate storage capacity is available the minimum and maximum inventory limits are set to zero and (8.24) reduces ∀{spk} to    ES S pspvk + Sˆspk − uSsrpk + pT 0= srpk P ipi v∈V SRP =1∧I P ipo =1 r∈R|Isr =1 r∈R|(Isrp ) sr    mss ss msd sd mdd dd − Tss σssd pk − Tsd σsdpt−T sd − Tsd σsdpt−T dd d sd dd s∈S d∈D d∈D sdk sdk dk   mss ss mss ss + (1 − ωss sk ) Tss σ + ω T σ ss sk ssd ss spk−(1−π)T ss ss spk−π−(1−π)T ss d



ss ∈S

ssd

ss ∈S

ssd

(8.25) 8.2.3.4 Minimum Production Requirements A typical constraint in production is the requirement that a certain production U min = 0.8 or 80% of a utilization rate is achieved in each time period, e.g., Rsrp max max certain theoretical capacity Psrpk should be achieved. For constant Psrpk and min max Psrpk = 0.8Psrpk this leads to    MCR = 1  min ∀ sr Isr min P max = 0 or P ≤ p = P ; pP srpk srpk srpk srpk  Psrpk > 0 . ∀{pk}

8.2 A Tailored MILP Model

165

min max If the branch Psrpk ≤ pP srpk = Psrpk becomes active, we are sure that at least min Psrpk tons of product p are produced on reactor r at site s in period k, or U min min max equivalently that a utilization of Rsrp := Psrpk /Psrpk is reached. However, P this approach for declaring psrpk as semi-continuous variables is implemented only for reactor which are neither mode-changing, nor design reactors. For mode-changing reactors instead of (8.22) we might consider two alternative approaches: in approach A for minimum production utilization we get min P min D U min P Psrpmk := Rsrp msrmk = Rsrpm Rsrp mD srmk

,

max P Psrpmk := Rsrp mD srmk

min max i.e., Psrpk and Psrpk become depended on mode and on the variables mD srmk . Therefore, our first approach, in which semi-continuous variables and a constant were multiplied would lead to a product of a semi-continuous and a continuous variable. In the second approach we would get min max pPM ≤ pPM Psrpmk ; srpmk = 0 or srpmk  MCR  ≤ min  Psrpmk   = 1 Psrpk > 0 . ∀ srpmk Isr

(8.26)

max The relation pPM srpmk = Psrpmk is already covered by (8.16). Let us now focus on the zero-production branch in (8.26). If we exploit (8.13) we note that PM αsrmk = 0 implies mD srmk = 0, and thus also psrpmk = 0. Production is only D possible if msrmk > 0. The zero-production branch in the semi-continuous condition (8.26) applied to pPM srpmk does not make too much sense in this context because the model has no incentive for the case mD srmk > 0 and pPM = 0; even if mode m is active there is no implication that mD srpmk srmk has to be greater than zero (however, so far, the cases of very small numbers of mD srmk are not yet excluded; if those occur then the batch & campaign feature on mD srmk should be applied). Therefore, we can replace (8.26) (without any loss) by the simple constraint  MCR   P min D U min Rsrpm msrmk ≤ pPM ; ∀ srpmk Isr = 1 ∧ Rsrpm >0 . (8.27) srpmk

The existence of (8.27) in the model file is controlled by setting the control PM parameter DOUTMCR to DOUTMCR= 1. If mD srmk > 0, then psrpmk observes the U min PM utilization rate Rsrpm > 0; if mD srmk = 0 then (8.16) implies psrpmk = 0. For mode-changing reactors, (8.27) needs to be generated for all m ∈ Msr , i.e., = 1, . . . , Msr . For design-reactors which are not mode-changing reactors (8.27) is needed only for m = 1, and for design reactors which are mode-changing reactors, again we need (8.27) for m ∈ Msr . Note that this approach will have a tendency to lead to small values of the variables mD srmk if the utilization constraints cannot be satisfied otherwise. So, the results might often show a 100% utilization rate with the reactors being idle for a time larger than the time required for a mode change. Alternatively, in approach B for minimum production utilization on mode changing reactors we could proceed with the following definition for the utilization rate of a reactor in a given period:

166

8 Operative Planning in the Process Industry

sum of all production over all modes sum over mode-dependent capacity × time spent in that mode

(8.28)

If we introduce the total production on reactor r  pP ; ∀srk} , pR srk := srpk p∈P

and if we define  CAP rsrk :=



P Rsrmp mD srmk

;

∀srk}

(8.29)

P p∈P m∈Msr |Rsrmp mD >0 srmk

to be the theoretical capacity of a mode-changing or design reactor we get the utilization rate pR srk uRT ; ∀{srk} (8.30) srk := CAP rsrk The critical term is the denominator. The variable mD srmk tells us how many days reactor r spent in mode m. If we use the definition (8.28) we get 

M sr 

P p∈P m=1|Rsrmp >0

M sr 



pPM srpmk ≥

U min P Rsrp Rsrmp mD srmk

;

∀{srk}

P p∈P m=1|Rsrmp >0

(8.31) or

M sr 



pPM srpmk = 0 ;

∀{srk} .

(8.32)

P p∈P m=1|Rsrmp >0

Note that this approach is less restrictive than approach A because it puts a constraint only onto the total production in a time slice. In addition it has a nice mathematical property: it is a semi-continuous construct for constraints, not for variables. Xpress-MP supports this directly in the B&B scheme. Simpler minimum production requirements, Csp , not leading to semicontinuous variables, have to be taken into account over the entire production schedule, i.e., NsK   pP ; ∀{sp} . srpk ≥ Csp SR =1 k=1 r∈R|Isr

As in the prior case of bounding the number of change-overs, these conditions (N D N P N K coefficients) are also replaced by the equivalent system of equations with (1 + N K ) coefficients ptot sp

:=



K

Ns 

SR =1 k=1 r∈R|Isr

pP srpk

;

∀{sp}

8.2 A Tailored MILP Model

and bounds

ptot sp ≥ Csp

;

∀{sp}

167

.

Moreover, the total production at a site must not fall below given global production limits Cs , i.e., P

N 

ptot sp ≥ Cs

;

∀s

.

p=1

Finally, monthly minimum requirements Cspt 

K

Ns 

pP srpk ≥ Cspt

;

∀{spt}

SR =1 k=1 r∈R|Isr

remain to be fulfilled. If CTRLSB = 1 the constraint 

tP sp > Q1

(8.33)

s∈S p∈P

is added. Note that Q1 is generated when objective function 4 is used. 8.2.3.5 Batch and Campaign Production Batch and Campaign production is only considered in the short term scenario but not in the design scenario (OBJTYPE=5). The model formulation is based on the concept of adding time-continuity to discrete-time models first developed by Kallrath (1999, [49]). Batch production in the process industry operates in integer multiples of batches where a batchis the smallest unit to be produced, e.g., 200 tons. Several batches following each other immediately establish a campaign. The production may be subject to certain restrictions, e.g., campaigns are built up by a discrete number of batches, or that only campaigns of a minimal size can be produced. It is also possible to model the requirement that a certain timelag between successive mode-changes is observed. Within a fixed planning horizon, T , a certain product can be produced in several campaigns. In discrete-time formulations where variables ppt describe the production [e.g., in tons] of a product p in time-interval t it is not easy to model batch or campaign restrictions if the batch or minimal campaign size is larger than the capacity per period. Assume that production is performed in batches of 200 tons, and that our time intervals have a length of ten days with a daily production rate of 10 tons/day. The minimum time to produce the batch would cover 20 days, or exactly two time intervals. A plan looking like pp4 = 45 tons, pp5 = 100 tons, and pp6 = 55 tons covers three periods (the first and third only partial) to produce exactly 200 tons, and thus provides more degrees of freedom.

168

8 Operative Planning in the Process Industry

Modeling Contiguity To model contiguous quantities, e.g., the amount of production in a certain campaign extending over several time slices, in the framework of discrete-time formulations we proceed as follows: 1. we identify or assign a time-indexed quantity, e.g., a production variable, contributing to a contiguous quantity, e.g., the production in a campaign, uniquely to a contiguous quantity (this requires that we trace the startups of production in the time-slices, and the start-ups of the contiguous quantities); 2. we add the values of all contributing quantities belonging to a certain contiguous quantity (we use indication variables which tell us whether a certain product amount contributes to a certain campaign); 3. we apply constraints to the contiguous quantities. An elegant and numerically more efficient formulation to add time continuity to discrete-time models has been developed recently by Suerie (2005, [93]). However, it seems that this formulation yet needs to be extended to support multi-stage production. Continuous Production Variables and State Variables An important intermediate goal is to compute the amount, pC srpnk , of product p ∈ P produced for a certain campaign n in period k ∈ T , and the total amount pC srpn produced in that campaign. Thus, our idea is to relate the production psrpk to a certain campaign and then to add all contributions establishing this campaign. The mathematical model, for this class of production planning problems in the process industries, is assumed to be, for a certain site, unit, or reactor P r ∈ R, based on some binary state variables δsrpk indicating whether product S p is produced on r in period t, and binary start-up variables δsrpk indicating whether the production of p is started in period t on reactor r at site s. Let − + Prpk and Prpk be bounds on psrpk if psrpk > 0. Once pC srpn is available it is possible to apply specific batch or campaign constraints. Batch and Campaign Conditions We are now in a position to formulate that, e.g., a campaign may just consist of one single batch of fixed batch size Brp , pC rpn = Brp

∀{rpn ∈ N1 }

;

.

Alternatively, campaigns may be built up by a discrete number of batches following each other immediately, i.e., pC rpn = Brp βrpn

;

∀{rpn ∈ N1 }

,

(8.34)

where the integer variable βrpn indicates the number of batches of size Brp within campaign n. Finally, pC rpn , may behave like a semi-continuous variables, i.e., − C + pC ; ∀{rpn ∈ N1 } , (8.35) rpn = 0 or Crp ≤ prpn ≤ Crp − + where Crp and Crp are lower and upper bounds if production takes place.

8.2 A Tailored MILP Model

169

8.2.3.6 Modeling Stock Balances and Inventories The model contains stock of products associated with production sites and stock of products associated with demand points. Concerning stock at demand points it is possible to lease some additional stock capacity. At demand points products can be stored in dedicated product-origin tanks, variable product-origin tanks (both product and origin are variable), variable product tanks (only the product can vary), or in containers. In detail: check tanks, storage tanks, swing tanks and containers. Some of the storage tanks are dedicated tanks reserved for certain products, others can be used for several products each at one time. There is a set of rules when to fill a tank or container with a product. The check tanks have only small capacities and are used to test the product quality. Variable tanks are filled and emptied when sold up to a minimum level, and filled with the new product again. The safety stock of products in variable tanks needs to be discussed (or possibly: aggregated over all tanks). Multi-mode inventory entities are modeled on the basis, that only one product can be stored; the change to another product be stored happens in zero time; cost for changing products in a tank are only considered in the post-optimal analysis. 8.2.3.7 Dedicated Inventories at Sites (Free Origin) If for each product p there is an own tank i available attached to a site then we talk about a dedicated product tank with no restriction on origin. Such inventory entities are called fixed-product variable-origin tanks and are described by the balance equation  E  OS sSsipok = sSsipok−1 + pspvk + tIS uSsrpk lspyk − tlspyk − P ipi v∈V r|Isr =1  + ; ∀{sipok|o = “free”} pT srpok P ipi SRP r∈R|(Isrp =1∧Isr =1) with the source, sSsipok , from the previous period
0 ,k=1 Ssipo sSsipok := sSsipok−1 , 2 ≤ k ≤ NsK

(8.36)

(8.37)

0 OS , and tIS with the initial product stock, Ssipo lspyk (tlspyk ) denoting all incoming (outgoing) transport at site s. The incoming transport tIS lspyk at site s from other sites l can be shipment in transit  S SS Sˆspk := Slspk SS l∈S|∃Slspk

arriving in period k from shipment sent prior to the first period, or incoming transport at site s from other sites, i.e., we have

170

8 Operative Planning in the Process Industry

ˆS tIS lspyk := Sspk +



(1 − ωlsk ) tLL ss + lspk−(1−π)Tss d

l∈S



ωlsk tLL ss lspk−π−(1−π)Tss

d

l∈S

(8.38) where the specific amount of transport is given by M F M IN LL tLL lspt = t(l, s, p, t) := Tlspy Tlspy σlspyt

(8.39)

MF MF including the factor Tlspy , 0 < Tlspy ≤ 1, describing mass loss during transport and the sets are defined as    ss Ssdk := sd ∈ S sd = s ∈ S ∧ k + Tss < NK , d    ss Ssk := sd ∈ S sd = s ∈ S ∧ k > Tss , d    sd K Dsdk := d ∈ D k + Tsd < N ,    dd Ddk := dd ∈ D dd = d ∈ D ∧ t + Tdd < NT . d

The outgoing transport at site s is established by shipments to other sites and to the demand points, i.e.,       tOS tLL tLL tLL lspyk := ssd pk + sdpk−T sd + sdpyk−T dd sd ∈Ssdk y∈Y

sd

d∈Dsdk y∈Y

d∈Ddk y∈Y

dd

The capacity bounds for product stock read SC sSsipok ≤ Ssipo

∀k

;

,

  SC  ∀ ip ∃Ssp

.

The product stock should never fall below the safety stock M IN sSsipok ≥ Ssipo

;

∀{spk}

,

and a possible restriction in the last period, i.e., as forced by INVRULE = 4, CE sSsipok ≥ Ssipo

;

∀{sp}

,

k = NK

.

The constraints applied to the inventory at the final period are selected by the parameter INVRULE according to the following scheme: INVRULE description 0 no condition at all 1 total inventory in final period = total initial inventory 2 stock at the end = INV*INI 3 stock at the end = INV*END 4 stock at the end ≥ INV*END

8.2 A Tailored MILP Model

171

Dedicated Inventories at Demand Points If at demand point d there exists only one dedicated inventory tank for endproduct p the stock balance equation reads (otherwise we use the formulation in Sect. 8.2.3.7) N  ED  mdd dd    L DT + Sˆdpt + pdpvt − sdpcwot − Tdd σdd C

sD dpt

= +

sD dpt−1 

c=1 w∈W o∈O

v∈V K s

s∈S k=1|k+t1 (s,d)≤Ks ,t(k+t1 (s,d))=t K  s

(1 −

s∈S

msd sd ωsdk ) Tsd σsdpk

msd sd ωsdk Tsd σsdpk s∈S k=1|k+t2 (s,d)≤Ks ,∧t(k+t2 (s,d))=t  mdd dd + (1 − ωddd t ) Tdd σddpt−t1 (d,dd ) d∈D|t>t1 (d,dd )  mdd dd SC + ωddd t Tdd σddpt−t2 (d,dd ) ; ∀{dp|∃Sdp }, t d∈D|t>t2 (d,dd )

+

= 2, . . . , N T

with t2 (x, y) := t1 (x, y) + π

xy t1 (x, y) = (1 − π)Txy

,

and π = 1 for short term planning (in that case times for transportation must correspond to the time discretization) and π = 0 for long term planning (in sd this case transport arriving are treated probabilistically). where Tsd denotes P the minimum transport amount and the time Tsd needed to ship products P from site s to demand point d. Note that because Tsd is used in the index it P is required that Tsd is measured in units of the period and that it is integral. DS DS For the first period, t = 1, sD dp0 is replaced by Sdp . where Sdp denotes the initial stock of product p at demand point d and S

DT Sˆdpt

N 

:=

DT Ssdpt

PT s=1|∃Ssdpt

denotes transport arriving in period t from shipment not originating within the current planning horizon. If no inventory is available and there exists a demand Ddpcwt , i.e., ∃Ddpcwt ∧ PC .not.∃Sdp , then the sales variable sLdpcwot is immediately coupled to the transport terms. Stock must never exceed the stock capacity, i.e., R CS sD dpt − sdpt ≤ Sdp

;

∀{dpt}

,

where sR dpt gives the current additional stock in a rented inventory. The additional stock is usually bounded by CR sR dpt ≤ Sdp

;

∀{dpt}

,

172

8 Operative Planning in the Process Industry

and the safety stock bounds are DM sD dpt ≥ Sdp

;

∀t ,

  DM  ∀ dp ∃Sdp

,

  DE  ∀ dp ∃Sdp

.

and the bounds for the last period are DE sD dpt ≥ Sdp

;

∀t ,

Note that these bounds are only considered if the corresponding stock capacities or safety stocks exist. Variable Inventory Entities at Demand Points To follow the stock we first have to compute the maximum number of tanks at a given sales point that can store the same product from the same origin
PC 1 , if ∃Sdpo TP Ndop := 0 , else NdT A := max TO Ndo := max

NdT S := max



CA i ∈ N |∃Sdn

 



OC i ∈ N |∃Sdon

SC i ∈ N |∃Sdn





TP Ndop is 1 if at demand point d a dedicated tank exists which stores product TO p from origin o. Ndo , NdT S and NdT A give the number of product variable, product-origin and additional product-origin variable tanks. As is explained in more detail later in Section 8.2.3.6, at demand points we have dedicated tanks, product variable and product-and-origin variable tanks. Additional (rented) tanks are treated like product-and-origin variable tanks in every respect. The four functions defined above give the number of tanks of each of this types. Note that per sales point, origin and product there exists at most one dedicated tank. If there exist more than one real-world dedicated tank than the dedicated model tank has a capacity which is the total capacity of all of them. The maximum number of tanks at demand point d to store product p coming from origin o is given by
TS TO TP Nd + NdT A + Ndo + Ndop | o = “X” TI Ndop := TS | o = “X” Nd

Note that the origin o = “X” refers to unknown origin, and that our tanks are listed in this sequence: product-origin variable tanks, product variable tanks (can store several product coming from a fixed origin), and, last, the dedicated tank (here, product and origin is fixed) if it exists. Products with unknown origin can only be stored in product-origin variable tanks.

8.2 A Tailored MILP Model

173

For convenience we also define the following sets of indices (which are empty in the case that the corresponding type of tank does not exist):     T TI Ndop := i 1 ≤ i ≤ Ndop    NdT P O := i 1 ≤ i ≤ NdT S    NdT P A := i 1 ≤ i ≤ NdT S + NdT A    TP TO Ndo := i NdT S < i ≤ NdT S + NdT A + Ndo    TV TP TO Ndo := NdT P O ∪ NdT P A ∪ Ndo = i 1 ≤ i ≤ NdT S + NdT A + Ndo T TP TV Ndop , NdT P O , NdT P A , Ndo and Ndo are the sets of tanks which can store product p from origin o, product-origin variable tanks, product-origin and additional tanks, product variable tanks and, finally, all variables tanks. We then define the non-negative continuous stock variables

sDVT dipot ≥ 0

;

∀{dpot}

T ∀i ∈ Ndop

specifying the amount (tons) of product p produced at origin o of stock (tons) stored in tank i at the end of period t at demand point d. Likewise, we define the stock in a rented variable product-origin tank sDVRT dipot ≥ 0

;

∀{dpot}

∀i ∈ NdT P A

and the total amount of stock of product p produced at origin o of stock (tons) stored in containers sDC ∀{dpot} . dpot ≥ 0 ; Note that products can always be stored in containers. We can trace down inventories to the level of trace individual containers, or we treat the containers as aggregated stock capacities. Instead of stock variables with names indicating its type we define generic DT VPT stock variables sdipot and associate appropriate indication tables Idipot , Idipot , VPOT DC R Idipot , Idipot , Idipot indicating whether storage entity i is a dedicated, a variable product or a variable product-origin tank, a container or a rented inventory. To keep track which product is in tank i, we define the binary variables λdipot for variable tanks
1, if tank i at d is filled with p TV ; ∀{dipot|i ∈ Ndo } . λdipot := 0, otherwise At demand points the model provides two inventory entities: tanks and containers. Tanks have upper capacity limits, while the use of containers is only

174

8 Operative Planning in the Process Industry

limited by the physical space available to keep them. Therefore, containers “vanish” if they are empty, and are able to store products from different origins. Tanks can either be dedicated or variable. Variable tanks can store different products from different origins, dedicated tanks are assigned to one product from a specified site or origin, resp. Furthermore, it is possible to consider a strategic minimal stock amount for each product. The stock situation is modeled by material balance equations. These connect incoming and outgoing flow over adjacent (commercial) periods. Precisely, the balance equations connect the ends of the periods by considering the sum of inflow and outflow. This discretization scheme in time is based on the assumption that incoming and outgoing flows in a given period take place in such an order, that the tanks (and containers) neither overflow nor run below zero. This assumption seems not to be critical, since in reality there are certain small “check” tanks, that are not modeled and which can be used as buffers for the rare products which usually have only smaller demands. There are two different approaches to model the balance equations in tanks, or storage entities in general. The first approach based on (8.40) allows in instantaneous flow of material between appropriate storage entities. That way, for a given product, only the sum over all storage entities appears in the inventory balance equations (8.40). The amounts used for sales are extracted from these aggregated inventory balance equation. Alternatively, we might apply inventory balance equations for each storage entity i. Then, in addition, we might want to use the sales variables sLS dpicwot where the additional index i indicates from which storage entity i the amount of product p is extracted. If Idpcw denotes the set of all feasible storage entities which might be used to satisfy a demand Ddpcwt then the more detailed sales variables and the original sales variables are coupled by  sLdpcwot = sLS dpicwot i∈Idpcw

Note that this approach may add many continuous variables to the model. Detailed Tank Modeling For specified “known” origin o the balance equation reads  T i∈Ndop

sdipot + sC dpot = D N 

ds =1|ds =d

 T i∈Ndop

SM dd sdipot−1 + sC spot−1 − Tss σddpot −

SD + Tsdpt + TdDD s dpot

D

−

N 

D ≤N T dd =1|dd =d∧t+Tdd d

R(s,t)  S r=1|t>Tsd

SM dd Tdd σddd pot + d

∀{dpo}

,

IM sd Tsd σsdpk(s,t−T I

sd

C N 

c=1

sLdpoct

,r)

D

N 

ds =1|t>TdD d s T

t = 2, . . . , N

TdSM σddds dpot−T S sd

;

ds d

, (8.40)

8.2 A Tailored MILP Model

175

SM IM S where Tsd and Tdd denote the minimum transport amount and Tsd the time needed to ship products from site s to demand point d. Note that because I I Tos is used in the index it is required that Tsd is measured in units of the period and that it is integral; we could use the simplified transport scheme for variable tanks as well but avoid it here for the sake of simplicity. The sum on the left-hand side of the equation is the total storage of product p from plant s in any available tank. Note that the sum over all tanks on the right-hand side implies that stock can be exchanged between compatible tank at zero cost. For t = 1 the first term on the right-hand side is replaced by the initial product stock TI Ndop

TI Ndop





sdipot−1 −→

i=NdT S +1

PD Sdipo

Co sC dpot −→ sdpo

,

i=NdT D +1

leading to  T i∈Ndop

sdipot + sC dpot =

 T i∈Ndop

SM ss IS −Tss σsspot + Tospt + S

+

N  ss =1|ss =s

TsSS − s spot

R(i,t) 

I r=1|t>Tos S

C N 

c=1

sLdpoct

IM ss Tos σospk(o,t−T I

os ,r)

N 

S ≤N T sd =1|sd =s∧t+Tss

SM ss Tss σssd pot d

d

S N 

+

PS Sdipo + sCo dpo −

ss =1|t>TsSs s

TsSM σssss spot−T S ss s s s

PC ∀{dpot} | ∃Sdpo ∧t=1

(8.41)

Stock has never to exceed the stock capacity, i.e., PC sdN T I pot ≤ Sdpo dop

;

PC ∀{dpot} | ∃Sdpo

The product stock is further subject to safety level  M M sdpoti + sC ∀{dpot} | ∃Sdpo dpot ≥ Sdpo ;

(8.42)

.

(8.43)

T i∈Ndop

Note that these bounds are only considered if the corresponding stock capacities or security levels exist. Additional or rented tanks i ∈ NdT P A , more expensive than regular ones, are described by sd,i+N T S(d),pot − sd,i+N T S(s),pot−1, ≤ sR dipot ∀{dpo},

; T

t = 2, ..., N ,

(8.44) ∀i ∈

NdT P A

,

176

8 Operative Planning in the Process Industry

where sR dipot denotes the rented capacity. Finally, we have to ensure that the variable tanks contain only one product at a time. This is done by coupling the binary variables λdipot to the inventory variables sdipot and later adding the convexity constraints (8.47) and (8.48): OC sdipot ≤ Sdoi λdipot

;

∀{dpot}

TP ∀i ∈ Ndo

(8.45)

for product variable tanks, CA sdipot ≤ Ssn λdipot

;

∀{dpot} ∀i ∈ NdT P A

;

∀{dpot} ∀i ∈ NdT P O

for additional tanks and SC sdipot ≤ Sdn λdipot

(8.46)

for product-origin variable tanks. Note that (8.45) and (8.46) also serve as the capacity constraints for the variable tanks. The unique occupation of a tank is realized by the convexity constraints  TP λdipot ≤ 1 ; ∀{dot} ∀i ∈ Ndo (8.47) p∈P

or



λdipot ≤ 1

;

∀{dt}

∀i ∈ NdT P O ∪ NdT P A

.

(8.48)

p∈P o∈O

guaranteeing that at most one of the binary variables is unity. If a tank is empty at the end of a period, the sums on the left-hand side of (8.47) and (8.48) are zero and the inequalities are inactive. Containers The sum over all product amounts stored in containers at site d is bounded by  CM sC ; ∀{dt} (8.49) dpot ≤ Sd p∈P o∈O

with upper bound or site-dependent container capacity SdCM . 8.2.3.8 Modeling Transport The models considers three types of transport: transport of products between production sites and from production sites to demand points; in some rare cases there is also transport between demand points. The transport is described by transport cost depending on source, destination, product, and transport means and is subject to minimal quantities to be observed and transport times (typically a few days). Regarding the length of the planning horizon and the discretization of time we consider two model approaches to transport:

8.2 A Tailored MILP Model

177

1. transport times are exact multiples of the discretized periods (π = 0), 2. transport times are not exact multiples of the discretized periods (π = 1) and a probabilistic approach is used. π = 0 can, for instance, be used in a short term scenario covering a quarter with a time resolution of one week in which transport times can be approximated by 0 or 1 week. In a years planning scenario (π = 1) with time slices of one month and transport times of two or three weeks we would use π = 1 and the following probabilistic approach. Let DkP K be the length of the time period k, ∆ be the time needed for transport and let us assume that ∆ ≤ DkP K

,

PK ∆ ≤ Dk+1

.

If we assume that shipments during production period k leave the site with uniform probability in period k the product will arrive at the destination site with probability ∆ ∆ ωk := P K = P U (8.50) Dk Dt in period k + 1 and with probability 1 − ωk in period k. Therefore, in the one year planning scenario, we suggest the following heuristic approach to consider transport in the inventory balance equations. If pT is the amount to be shipped (appears as a loss term in at the site where transport origins) we consider (at the destination of shipment) (1 − ωk )pT in the balance equation of period k and ωk pT in period k+1 as gain terms. The probabilistic approach (π = 1) is not recommend if the planning tool is used operationally. But for longer term planning is should be suitable, especially, if there exists some minimum inventory level. To test the probabilistic transport feature, the probabilities could be set to ωk = 0 which should give identical results to the π = 0 scenarios. max Transport subject to product-specific capacities, Tsdp , and conditional msd minimum bounds, Tsdp , is described by non-negative semi-continuous transport variables dd  σdd
pt : amount of product p shipped between demand points d and d sd σsdpk : amount of product p shipped from site s to demand point d ss  σss
pk : amount of product p shipped from site s to site s sd The semi-continuous variables, for instance σsdpk , obey the definition sd msd sd σsdpk = 0 ∨ Tsdp ≤ σsdpk ≤ Tpmax ; ∀{sdpk}

(8.51)

They are only generated if all the following conditions hold in the sense of a logical AND:

178

• • •

8 Operative Planning in the Process Industry

transport costs are defined, transport arrives at destination within the planning horizon there exist demand OR there exist an inventory for the product OR OBJTYPE = 7

Note that in OBJTYPE = 7 transport to demand points without demand or inventory is possible. Note that (8.51) is only used if activated by the user; otherwise the transport variables have only an upper bound, i.e., sd 0 ≤ σsdpk ≤ S + ; ∀{sdpk}

.

A tricky feature to model is originating from site s in production period k arriving at demand point d in commercial period t. The time associated with PK this transport ∆sd , the length of the period is Dsk and thus ωsdk follows from (8.50). Let us first consider the case π = 0; in this case ∆sd is an integer multiple PK of Dsk , i.e., ∆sd Tsd = P K . Dsk Then a shipment originating in period k arrives in period k + Tsd . If the commercial period t consists of Ust production time periods then all shipments originating in periods   k = 1, . . . , NsK |t(s, k + Tsd ) = t . In the probabilistic approach (π = 1) transport is modeled as occurring probabilistically, 1 − ωsdk arrives in period k, i.e.,   1 − ωsdk ; k = 1, . . . , NsK |t(s, k) = t , σsdpk , and ωsdk arrives in period k + 1, i.e.,   ωsdk ; k = 1, . . . , NsK |t(s, k + 1) = t

,

sd σsdpk

.

sd which leads to Note that there are two terms containing the variable σsdpk some complications (column appears twice in a row ) if Ust > 1. The model allows to control that the transport variables are only generated for those indices k if the transport shipped out in period k will arrive within the planning horizon, i.e., if

π = 0: k + ∆sd ≤ NsK π = 1: k + ∆sd ≤ NsK − 1 or, equivalently, if NsK − [k + π + (1 − π)∆sd ] ≥ 0

.

8.2 A Tailored MILP Model

179

Transports adds two types of variable costs to the objective function: costs for D transport and duty. Duty, Csd , ($/mass) must be paid when importing products from another location. Transport costs and duty can be charged to the manufacturer or to the customer. We have neglected the index y  for transport sd sd mean so far. To get the full model we need to replace σsdpk by y∈Y σsdpyk ; transport times, transport capacities etc. then also become dependent on y. 8.2.3.9 Keeping Track of the Origin of Products In some cases customers assign an attribute to their orders. They may wish to get a product from a certain plant only, or they do not want to get it from a particular one, or that shipment should come from one plant only without specifying this plant explicitly. Thus the model incorporates two sparse tables A1 A2 A1 Ddpcwo and Ddpcw with the following meaning: if Ddpcwo is specified for a combination of demand point d, product p, sales category c, packing type w, and origin o then it is interpreted as follows:
1 : shipment of p is allowed to come from origin o A1 Ddpcwo = . 2 : shipment of p must not come from origin o A2 If Ddpcw is specified, i.e., it exists, and has one of the following value


A2 Ddpcw =

A1 1 : at least one constraint is specified in Ddpcwo 2 : shipment of p always come from same origin

.

A2 If Ddpcw is specified the feasible set of origins Odpcw (note it does not depend on time) for demand Ddpcwt is calculated according to the following scheme:   A1 =1 Odpcw = ∪o|Ddpcwo

or, alternatively, Odpcw = O

  A1 ∪o|Ddpcwo =2

Note that in both cases we exploit full complementarity, i.e., the demand attributes for a certain order or demand should, for several origins o, only A1 A1 have Ddpcwo = 1 or Ddpcwo = 2 values. A2 In the case Ddpcw = 2 the sales variables sLdpcwot are coupled to the binary T A2 variables δdpocw generated if Ddpcw = 2 exists. Note that there must be at least A1 one possible origin for the demand, defined in table Ddpcwo , and that these binary variables do not depend on time, i.e., they once enable a connection from an origin o to sales category c at demand point d for product p, or they forbid it for the whole planning horizon. This is ensured by the equations  T δdpocw = 1 ; ∀{spcw} . (8.52) o∈Odpcw

180

8 Operative Planning in the Process Industry

T Let us now couple δdpocw and sLdpocwt . The inequalities T sLdpcwot ≤ M δdpocw

;

∀{dpocwt}

(8.53)

ensure that no sale of product p in category c from origin o at demand point T T d is possible if δdpocw = 0. If δdopcw = 1 then the inequalities (8.53) produce L the redundant bounds sdpcwot ≤ M . Here, M is a sufficiently large upper bound. The best choice [see Kallrath and Wilson (1997, [55, Sect. 9.1])] is M = Ddpcwt . Note that by the considerations made above and definition (8.4) of the sales variables can not be created for origin “unknown” (o = “X”), if A2 Ddpcw is specified. 8.2.3.10 Including Demands and Demand Constraints No more must be sold than is required by the demand, i.e.,  sLdpcwot ≤ Ddpcwt ; ∀ {dpcwt |∃Ddpcwt } ,

(8.54)

o∈Odpcw

where Ddpcwt indicates how many tons of product p at time t are requested at demand point d in sales category c and packing type w. In the “maximize contribution margin” there is no need to satisfy demand, or to satisfy it completely. Therefore, if the control parameter DOFRCDM = 1, F in all objective function scenarios we enforce that a certain fraction, Ddpcwt , of a particular demand has to be satisfied     F F sLdpcwot ≥ Ddpcwt Ddpcwt ; ∀ dpcwt ∃Ddpcwt ∧ ∃Ddpcwt (8.55) o∈Odpcw

The inequality (8.55) is only applied in the objective function scenarios 1,2,5,6, and 9. If a certain demand has to be satisfied exactly, for instance, for a class F A customer, then one might set Ddpcwt = 1. If CTRLSB= 1, in the objective function scenarios 1,2 and 3 the total demand, DT , NT    T Ddpcwt . (8.56) D := d∈S p∈P c∈C w∈W t=1

has to be satisfied up to a maximum amount Q2 , i.e., in addition to the inequality (8.54) it is required that T

N   

sLdpcwot ≥ DT − Q2

;

(8.57)

d∈S p∈P c∈C w∈W o∈O t=1

is fulfilled. The minimum unsatisfied demand, Q2 , can be computed by running the “maximize sales” scenario. The inequality (8.57) is generated if the control parameter CTRLSB is set to CTRLSB = 1.

8.2 A Tailored MILP Model

181

In the “satisfy demand” scenario (OBJTYPE = 2) the demand has to be satisfied exactly, i.e.,  sLdpcwot = Ddpcwt ; ∀ {dpcwt |∃Ddpcwt } . (8.58) o∈Odpcw

Due to lack of capacity it may happen that not all of the demand can be covered by own production. Therefore, it is very important to provide the option to consider external purchase of products. 8.2.4 Defining the Objective Functions The model covers several objective functions: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

“maximize contribution margin” “maximize contribution margin while guaranteeing minimum demand” “minimize cost while satisfying full demand” “maximize total sales neglecting cost” “maximize net profit for design problems” “multi-criteria objectives” (max profit & min transport) “maximize total production” (for fixed design) “maximize total production of products for which demand exists” ”maximize total revenue” (for fixed design) “multi-criteria objectives” (max sales volume & min cost)

The first one maximizes the contribution margin and includes the yield computed on the bases of production and the associated sales prices and the cost. The second one minimizes the cost while satisfying demand. In both cases the following cost are involved: variable production cost, change-over cost, transport between sites, between sites and demand points, and between demand points, inventory cost for product and products, and cost for external purchase of products. The objective functions depend on the following data: P Sdpcwt C Csrm 1 m2 D Cdpcwt V Csrp trdd Cdd pp trss Css dp trsd Csd RM Csrpk SD Csp SS Cdp SR Cdpt ED Cdpvt ES Cspvk

salesp sales price for p (category c) at d in t cstchang cost for mode changes on reactor r at site s cstdelay delay cost after t periods of delay for order {dpcw} cstvprdc variable production cost (conversion cost) csttrdd cost for transport between demand points csttrss cost for transport of products between sites csttrsd cost for transport for sites to demand points cstrawmt cost for one ton of raw material p cstinvd cost for stock of products at demand points cstinvs cost for stock of products at sites cstinva cost for rented inventories of products cstprchd cost for external purchase at demand points cstprchs cost for external purchase at sites

182

8 Operative Planning in the Process Industry

8.2.4.1 Maximizing Contribution Margin This objective function include the revenue T

N    

y=

P Sdpcwt sLdpcwot

(8.59)

d∈D p∈P c∈C w∈W o∈O t=1 P . based on the specific sales prices Sdpcwt Further more, the following cost are involved: variable mode-dependent production cost

V

c :=





M sr 

K

Ns 

V Csrmpk pPM srpmk

.

(8.60)

sR =1 m=1 p∈P k=1 s∈S r∈R|Isr

Note that the variable cost to produce products include the cost for the production process itself and the cost for utilities (energy, water, etc.); however, the cost for these utilities may be computed in the post-optimal analysis. In addition we need to consider the cost to buy products. Here we need to P RDE distinguish different cases. If Ilpv = 1 we simply have LP

:=

c



K



Ns 

LP Cspvk pES spvk

.

(8.61)

s∈S p∈P|∃C RM v∈V k=1 spk P RDE = 2 the situation becomes more complicated. Fix cost If Ilpv T

N 

T

P EN Rspt +

s∈S p∈P t=1

N  

 F IX P EN − Rspt Rspt ωspt

s∈S p∈P t=1

have to be paid if the raw material is used (ωspt = 1), and penalty cost have to be paid if it is not used (ωspt = 0). And, the specific price per ton of raw BP C material purchased is segment dependent. Let Rspbk be the cost to be paid BP V BP V per ton of raw material between Rspb−1k and Rspbk . The accumulated cost at the breakpoint b are given by  BP V  ACC ACC BP C BP V Rspbk Rspbk − Rspb−1k := Rspb−1k + Rspbk ACC BP V BP V = 0. If Rspb−1k ≤ uR with Rsp1k spk ≤ Rspbk , i.e., µspbk = 1, then the total raw material cost for purchase are

RM

c

:=



B

Ns 

K

Ns  

 ACC BP C RBV − Rspbk Rspb−1k µspbk Rspb−1k

s∈S p∈P b=2|∃RACC k=1 spbk

+



B

Ns 

K

Ns 

s∈S p∈P b=2|∃RBP C k=1 spbk

BP C RB Rspbk uspbk

8.2 A Tailored MILP Model

183

or, if a alternative raw material formulation is used, RM

c



:=

K

B

Ns 

Ns 

ACC Rspb−1k µspbk

s∈S p∈P b=2|∃RACC k=1 spbk

+



K

B

Ns 

Ns 

BP C RB Rspbk uspbk

.

s∈S p∈P b=2|∃RBP C k=1 spbk

Next we have the mode changing cost M

c

:=

T





N  U M sr  

M sr 

SR =1 t=1 u=1 m1 =1 m2 =1 s∈S r∈R|Isr

M Csrm ξ 1 m2 srm1 m2 k(t,u)

,

(8.62)

m2 =m1

transport cost for products between demand points P

T dd

c

:=

T

N  N 

T dd M C dd Cdd T σddd pt d p ddd

,

(8.63)

d∈D d∈S p=1 t=1 dd =d

transport cost for products between sites and demand points T

T sd

c

:=

U N   

T sd M P sd Csdp Tsd σsdpk(t,u)

,

(8.64)

,

(8.65)

s∈S d∈D p∈P t=1 u=1

transport cost for products between sites T

T ss

c

:=

U N    s∈S

s∈S sd =s

T ss M C ss Css T σssd ck(t,u) d p ssd

p∈P t=1 u=1

inventory cost for stock of products at demand points T

SD

c

:=

N  

SP Cdpit sdipot

,

(8.66)

d∈D i∈I p∈P o∈O t=1

inventory cost for stock of products at sites T

SS

c

:=

U N   

SC S Cspik sspiok(t,u)

,

(8.67)

d∈D i∈I p∈P o∈O t=1 u=1

inventory cost for rented inventory of products at demand points T

SR

c

:=

N    d∈S

s∈S sd =s

i∈I p∈P o∈O t=1

 R SR SD − Cdp Cdp sdipot

,

(8.68)

184

8 Operative Planning in the Process Industry

D delay cost [the specific delay cost Cdpcwt after t periods of delay could be D D constructed as Cdpcwt = f (t)Cdpcw and f (t) could be any function of time, P e.g., f (t) = t + 1 − Cdpcw ; we skip the details of computing dU dpcwt ] T

DL

c

N    

:=

D Cdpcwt dU dpcwt

,

(8.69)

d∈D p∈P c∈C w∈W t=1

and, cost for external purchase at demand points T

ED

c

=

N   

ED ED Cdpvt pdpvt

,

(8.70)

d∈D p∈P v∈V t=1

and, finally, cost for external purchase at sites T

ES

c

=

U N   

ES ES Cspvk pspvk

.

(8.71)

s∈S p∈P v∈V t=1 u=1

The total variable cost are then given by c = cV + cRM + cM + cT dd + cT sd + cT ss + cSD + cSS + cSR + cDL + cED + cES and the objective function is max

Z1

,

Z1 = y − c

.

(8.72)

The “maximize contribution margin” scenario is probably the one used most often. A frequent question associated with interpreting the output of this scenario is why certain demands are not satisfied. If in this scenario certain demand is not fulfilled it may be due to three reasons: 1. the sales satisfying this demand is financially not attractive, 2. the plant production cannot satisfy this product mix completely because it is at its capacity limits, 3. the Branch&Bound tree search is not completed, i.e., the search was stopped at the nth feasible solution (usually, the first or second one) and optimality is not yet proven. It is hard to tell (unless the third reason applies) which reason caused unfilled demands but the objective function scenario “maximize contribution margin while guaranteeing minimum demand” may give an indication. In order to check out the third reason it is recommended to search for the next feasible integer solution. Note that in the “maximize contribution margin” scenario the total demand has to be satisfied up to a maximum amount Q2 , i.e., in addition to the inequality (8.54) it is required that (8.57) is fulfilled.

8.2 A Tailored MILP Model

185

8.2.4.2 Maximizing Margin – Satisfying Demand If it is too time consuming to exclude that the first reason is active it is recommended to run the “maximize contribution margin” and to check at which percentage level P the demand is satisfied. Then the same objective function (8.72) is used but needs to satisfy the additional inequality T

N   

sLdpcwot ≥ S + ∆S

(8.73)

d∈S p∈P c∈C w∈W o∈O t=1

where the left-hand side of (8.73) describes the total sales and ∆S is of the order of a few percents. If ∆S is chosen too large the problem might turn out to be infeasible. 8.2.4.3 Minimizing Cost While Satisfying Full Demand Exploiting max −c = min c the objective function is simply max

Z2

,

Z2 = −c

.

(8.74)

To avoid zero production, objective function Z2 is only used in combination with (8.58). Infeasibilities due to lack of production capacity are excluded by allowing sufficient external purchase of products. 8.2.4.4 Maximizing Total Sales In this scenario the objective function is T

max

N    

sLdpcwot

.

(8.75)

d∈D p∈P c∈C w∈W o∈O t=1

This scenario may be used to find out the total capacity of the production network with respect to a given demand mix. Note that no cost or sales prices are involved. Therefore, the solution may turn out to be financially not attractive. It can be used to check whether the total production of the model roughly can reproduce the total sales in the business process. Note that it is not recommend to use objective function for differential testing in which results are compared to other optimization software. The reason is the high degree of degeneracy in the objective function. The motivation for this scenario is to handle cases in which the capacity is not sufficient to satisfy all demands but to sell as much as possible with the available production capacities. We assumed that production capacity is not sufficient. So we certainly cannot ask the model to fulfil all demands. If we would neglect the demands

186

8 Operative Planning in the Process Industry

completely we would get a trivial solution: the plant systems produces the products according to highest production capacities and avoids mode changes completely. That is not what we want. Including the yield and cost structure into the problem would in fact lead to the “maximize contribution scenario” and is not compatible with what we associate with “maximize sales” because some production is neglected because is not attractive from the economic point of view. The only consistent approach is the following interpretation: costs are neglected (almost) completely, and yields for all demands are set to an equal value, say, 1 $, or any realistic average yield. So we maximize sales, and thereby total production, by trying to satisfy as much of the demand as possible. Thus the objective function is simply T

max

N    

sLdpcwot

d∈D p∈P c∈C w∈W o∈O t=1

−

Tl  l∈L p∈P v∈V k=1

0.9pE lpvk

−

sr   M

M sr 

Tl 

ξsrmm
k

.

s∈S r∈R m=1 m
=1∧m
=m k=1

The only cost that we consider are cost for external purchase, otherwise the model will just satisfy demands by externally purchased products, because it gets them for free. In addition we put a soft penalty on mode changes. There is one consequence of this simple objective function which might produce solutions which might appear as “strange”. It is observed that much transport will occur. However, first experiments showed that the solution achieved in “maximize sales” scenario can be improved in the “maximizing contribution margin” or “minimize cost” scenario. This approach is supported by two additional output data produced in the “maximize sales” scenario: the total production, Q1 , NsK   pP , (8.76) Q1 := srpk s∈S r∈R p∈P k=1

and the total unmet demand volume, Q2 , T

Q2

:=

N    

Ddpcwt − sLdpcwot



.

(8.77)

d∈S p∈P c∈C w∈W o∈O t=1

These numbers, Q1 and Q2 , are provided to be fed in into the objective function scenarios 1, 2 and 3 as additional constraints. This is controlled by the control parameter CTRLSB to CTRLSB = 1. Note that if initial and final stock are forced to be identical maximizing sales is equivalent to maximizing production. So, this scenario can tell us the total production capacity of the whole production network with respect to a given demand pattern.

8.2 A Tailored MILP Model

187

8.2.4.5 Maximizing Net Profit This objective function is used to analyze investment or de-investment decisions and reads max Z5 , Z5 = y − c − cD , (8.78) where contains all cost related to the purchase of whole plants, the opening or the shut-down of reactors. 8.2.4.6 Multi-criteria Objectives The current version of the software supports two special scenarios involving multi-criteria objectives which we solve by a preemptive (lexicographic) goal programming approach using objective functions ordered according to priorities [see Appendix A, Section B.3]: 1. max. contribution margin and min. total amount of transport, 2. max. total amount of sales and min. variable cost. In scenario 1, the first goal is to maximize (8.72), the second one is to minimize to the total amount of transport K

T

t :=

Ns  

LL LL Tsdpy σsdpyk

.

(8.79)

s∈L d∈L p∈P y∈Y k=1 s=d

The idea of goal programming is to maximize the first objective (8.72), i.e., G1 := max Z1 then derive a target (lower bound) on the first goal which, in the example shown below is 97% of G1 , and minimize with respect to the second goal, i.e., min tT

subject to

Z1 ≥

100 − 3 G1 100

.

This approach can also be interpreted as follows. We optimize with respect to the first goal, then we allow a relaxation from this best value within a 3% limit, and minimize with respect to the second objective. The example below show the input to be provided by the user. The first P selects the preemptive approach, O indicates we wish to use objectives instead of constraints, the next P’s force the numbers 3.0 and 10.0 to be interpreted as percentage numbers. P O MAXIM6 MAX P 3.0 MINIM6 MIN P 10.0 The output the solver produces in objective function scenario 6 looks a little different from what it looks like in other scenarios. The output list the goals, the targets derived on the solution achieved. Usually, the value of the first objective function in the solution coincidences with the value of the target derived for that goal.

188

8 Operative Planning in the Process Industry

8.2.4.7 Maximizing Total Production In this scenario the objective function is K

max

Ns  

pP srpk = max

s∈S r∈R p∈P k=1



tP sp

.

(8.80)

s∈S p∈P

This scenario is primarily used for network testing or to find out the total production capacity of the production network. Note that no cost or sales prices are involved, i.e., this scenario neglects all commercial aspects. Therefore, the solution may turn out to be financially not attractive. In this scenario it is possible to sell more than specified by the demand, i.e., the constraints (8.54), (8.55) and (8.58) are not considered (this is controlled by the control parameter DOSalesB which is set to DOSalesB= 0 if OBJTYPE= 7. Due to this feature it may happen that the sum of satisfied and unsatisfied demand is not equal to the requested demand (because, for individual demands more can be sold than is requested). This scenario is rather used for development and testing purposes. It can be used to check whether the total production of the model roughly can reproduce the production in the business process. Note that it is not recommend to use objective function for differential testing in which results are compared to other optimization software. The reason is the high degree of degeneracy in the objective function. 8.2.4.8 Maximizing Production of Requested Products In this scenario the objective function is K

max

Ns   

pP srpk = max

s∈S r∈R p∈PD k=1

 

tP sp

.

(8.81)

s∈S p∈PD

This scenario may be used to find out the total production capacity of the production network with respect to a given demand mix. It is very similar to the “maximize total production” scenario (OBJTYPE=7) but is a little closer to the economy because it considers only those products in the objective function for which demand exists, and it also considers constraints on sales as specified by the control parameter DOSalesB. One should not be confused that the amount of total production shown in keyres.sum differs from the objective function value. There might be more produced than contributes to the objective function. 8.2.5 Implementation of the Model The mathematical model is fed by data provided either as ASCII files or work areas in an Excel spreadsheet. The model leads to a MILP problem, which, for a scenario of 12 months, might look like:

8.2 A Tailored MILP Model

189

Model Statistics ==================================== Generating 1908 3012 9575 142 2591 0 50 824 0 12 density is

matrix PLAN rows structural columns matrix elements rhs elements bound elements general integer variables binary variables semi-continuous variables partial integer variables directives 0.166612 percent

==================================== The first (or second) feasible mixed integer solution is accepted as the solution. This heuristic is justified because our trials indicate that its associated contribution margin deviates by only a few percent from that of the continuous problem (well within the error associated with the input data) and because it eliminates the need for the time consuming complete search for the absolute optimal solution via a B&B algorithm. Using the first objective function the first feasible integer solution is usually found within 2 minutes using Xpress-MP on a Pentium, the second usually within a few more minutes. 8.2.5.1 Estimating the Quality of the Solution The quality of solutions can be quantified by inspecting the upper and lower bounds derived by the B&B algorithm before reaching optimality. In a maximization problem the upper bound, z U , is provided by the LP relaxations z LP while the lower bound, z L , corresponds to the best integer solution z IP found. The bounds z L ≤ z ∗ ≤ z U on the objective function value z ∗ of the (unknown) optimal solution lead to the integrality gap z U − z ∗ or relative integrality p := 100

zU − zL z LP − z IP = 100 L z z IP

further discussed in Appendix B.2 on page 291. To improve the understanding of the concept of the integrality gap and its relationship to the structure of the model and the input data we consider the following intuitive approach to solve an MILP problem by solving the LP problem neglecting the integrality on the variables and then fixing those variables to nearby integer variables. Sometimes this technique may work but

190

8 Operative Planning in the Process Industry

the following example shows why rounding does not really help and leads to large integrality gaps. Consider max

x1 + x2

−x1 + x2 ≥ 0.5 −0.8x1 + x2 ≤ 1.3

subject to

x1 , x2 ∈ IN0

,

The straight lines S1 : x2 = x1 + 0.5

,

S2 : x2 = 0.8x1 + 1.3

and the x2 -axes establish the feasible region. If we neglect the integrality conditions the solution of the LP relaxation follows as x1 = 4 ,

x2 = 4.5 ,

Z LP = 8.5

.

In this example, the best integer feasible solution is x1 = 1 ,

x2 = 2 ,

Z IP = 3

and thus the gap is about p = 183%. This example shows that the best integer solution may differ significantly from the solution of the LP relaxation. It demonstrates that simple rounding techniques are not sufficient and that the integrality gap can be large. However, the situation could be improved by tightening the original constraints to −x1 + x2 ≥ 1 ,

−8x1 + 10x2 ≤ 13 ,

x1 , x2 ∈ IN0

,

and, eventually, to −x1 + x2 ≥ 1 ,

−4x1 + 5x2 ≤ 6

,

x1 , x2 ∈ IN0

.

The bound on the first one can be increased from the 0.5 to 1 because the sum or difference of two integer numbers – if it has to be greater or equal to 0.5 – also has to be greater or equal to 1. Similarly, we decrease the bound of the second from 6.5 to 6. 8.2.5.2 Comparing Solutions of Different Scenarios Besides operational planning runs the planning tool might be used to analyze different “what happen if ...” scenarios. Typically, one might relax certain constraints (e.g., increase the inventory capacity), or tighten other constraints (e.g., increasing the minimum batch size). If S and S R refer to a certain scenario and its relaxation, then we should observe the following relations for a maximization problem: z U (S) ≤ z U (S R ) ,

z ∗ (S) ≤ z ∗ (S R ) .

(8.82)

However, the solver may stop premature before reaching the maxima z ∗ (S) or z ∗ (S R ) just returning the lower bounds z L (S) and z L (S R ). Unfortunately, due

8.2 A Tailored MILP Model

191

to the mathematics of the Branch&Bound algorithm there exists no inequalities such as (8.82) relating z L (S) and z L (S R ). Thus, for comparing integer solution of different scenarios one has to compute the optimal solution providing z ∗ (S) or z ∗ (S R ), or one just compares the relaxation z U (S) and z U (S R ). Comparing z L (S) and z L (S R ) is only recommended when at least two or three feasible integer solutions are found. 8.2.5.3 Description of the Output The solution of the model produces the following output data: 1. Production Plans: Production characterized by production site, reactor, mode, product, period, tons and days of operation. 2. Mode Changing Plan: Lists all mode changes by site, reactor, mode→mode, period 3. Sales Plans: The amount of demand that can be satisfied at optimum contribution to cost characterized by demand point, product, sales category, packing type, origin, period, tons 4. Inventory Plans: location, inventory, product, origin, period, tons 5. Transportation Plan: Production site, product, period, tons 6. Transportation Plan: Demand point, product, period, tons 7. External Purchase Summary: Demand point, product, period, tons 8. Unmet Demand Summary: Demand point, product, period, tons 9. Cost Summary: The cost summary involves the following information: Production of products by production site, period Inventory of products by production site, period Inventory of products by sales, site, period Transport of products by production site to production site Transport of products by production site External purchases by products, production site, period An example of the financial summary looks like ===================================================== TURNOVER Objective Function Scenario Variable Production Purchase of raw materials Transport: between demand points Transport: sites to demand points Transport: between sites Change-over cost Inventory: demand points

636682156 5 130935514 39602003 0 22122065 6593234 40000 8260095

192

8 Operative Planning in the Process Industry

Inventory: sites Inventory: rented (in/out) External purchases: demand points External purchases: sites TOTAL COSTS CONTRIBUTION Contribution Margin PRODUCTION (tons) production at LOCAT1 production at LOCAT2 production at LOCAT3 production at LOCAT4 production at LOCAT5 Total production over all sites Total external purchase demand p. Total external purchase sites

55493321 0 5045417 0 268091647

368590509

96881 54343 8814 46123 54750 260910 5045 0

Total flow of raw materials Total use of raw materials

160560 64105

Total Total Total Total Total Total

70021 190889 128873 62016 500 62516

charged between reactors charged to tanks used from tanks net operative flow -> tanks net logistic flow -> tanks net product flow -> tanks

PLANT SYSTEM (days) Days available during horizon Days mode reactors were active Days needed for change-overs Number of change-overs change-overs at LOCAT1 change-overs at LOCAT2 change-overs at LOCAT3 change-overs at LOCAT4 change-overs at LOCAT5 TRANSPORT RESULTS (tons) total amount shipped (tons) INVENTORY STATUS (tons) total initial stock

6205 290 8 2 2 0 0 0 0

171894

56200

8.2 A Tailored MILP Model

total at the end of the horizon

193

8461

total initial stock (raw material) 7000 total end stock (raw material) 103455 DEMAND STATUS (tons) Total demands requested Total demands satisfied Total demands unsatisfied

161049 115300 45749

===================================================== 8.2.6 Real Life Issues 8.2.6.1 Diagnosing Infeasibilities Diagnosing infeasibilities is probably the hardest part of modeling and optimization, especially when new data are entered and first optimization runs are performed. Tracking down infeasibility in a large problem can be difficult. Users often ask “which constraint is wrong?” and are surprised when told that this is an ill-posed question. To see why, consider a small shop producing and selling bolts and screws. If the variables b and s denote the numbers of bolts and screws, we might have the constraints b+ s≥6 2b + 3s ≤ 7

(8.83)

The first constraint might be a marketing constraint asking for a minimum demand to be satisfied, while the second one might refer to some labor availability. Neither of these constraints is wrong, they are just inconsistent when taken with the non-negativity constraints of the variables b and s. Thus, we have to have in mind that infeasibilities are related to the fact that certain constraints have to be observed simultaneously. Removing a certain type of constraint may help to retain feasibility again. Infeasiblity can arise from any or all of the following causes: a) bad data, b) the problem really is infeasible for the correct data Simple data entry errors often contribute to cause a), with values like 1.00 being mistakenly typed as 100. Some defensive data checks should be built into the user interface. Displaying data graphically often helps to catch such errors, and is a good reason for holding data in spreadsheets whose graphical facilities are advanced and easy to use. Unfortunately, it is possible that the problem really is infeasible b) for the data specified, and often there is no clear indication what causes the infeasibilities. The notion of Independent Infeasible Sets (IIS) has been implemented in

194

8 Operative Planning in the Process Industry

various software packages. They are not a panacea, but they do help in practice. An IIS is a set of constraints with the property that if any one constraint is removed from the IIS set then the other constraints are consistent. In a sense, an IIS is the smallest set of “nasty” constraints. Sometimes an IIS can have a few members, and inspection of these gives a good guess as to where the problem is; but if an IIS has many members, the search for inconsistencies may still be hard work. Diagnosing infeasibilities may be supported by listing infeasibilities which occurred previously. Infeasibilities have been resolved by: 1. Data Flow : Check whether the data are passed correctly from the spreadsheet or database to the modeling language. 2. Matrix Generation: Check the logfile produced by the modeling language for any problems or warnings. 3. Finite transport times: Since the model includes finite transport times it may happen in the first time periods that some production requirements or inventory constraints cannot be satisfied. This problems becomes severe when modeling only a few time periods. This problem has been relaxed by considering incoming transport which originates before the first period within the planning horizon. However, it has happened that those amounts specified in transport-in-transit data exceeded the capacity of the inventory at the destination which also lead to an infeasible situation. 4. Minimum Demand: It is possible while “maximizing contribution margin” to require that a certain minimum demand is satisfied. If the lower limit is chosen too optimistically the model becomes infeasible. The only thing to do about that is to decrease the lower limit. 5. Inventory Problems: Inventories have attributes attached to them which describes the initial inventory, a target inventory at the end of the planning horizon, safety level and their capacity. The initial stock level must observe the safety level and capacity as lower and upper bounds. The INVRULE flag described on page 170 controls how the target inventory level is interpreted and coded into the model. It is recommend to set it to 0 for initial test runs. Otherwise, the target inventory needs to be consistent with the safety level and capacity. 6. Reactor Topology: There might be problems with newly defined reactors positioning them into the network. During the matrix generation phase two files named indpipei.xpn and indpipeo.xpn are produced in the DATA directory. Use these files to check whether all reactors have access to appropriate raw materials and whether they are capable to charge their products to the local site tanks. 7. Nonlinear Pricing Structure: Nonlinear pricing or the global discounting scheme has been invoked by INDPRDE = 2 or INDPRDE = 3 but the corresponding break point data have not been provided consistently. If none of these cases applies and does not cure the problem we recommend the user relax certain constraints as described in Sect. 8.2.6.3.

8.2 A Tailored MILP Model

195

8.2.6.2 Seemingly Implausible Results Sometimes the first results with new data sets or even new design situation look very strange and not plausible. Usually that is caused by similar reasons which lead to infeasibilities [see Section 8.2.6.1 on page 193]. It is recommended to run a sequence of models with increasing complexity and objective functions types described on page 181: 1. choose objective function type 7 asking to maximize total production: this scenario enables you to check whether production is possible, whether all reactors are attached to the network, and whether the total production matches the expected capacity (note that the model does not see any cost and money related aspects; it will produce as much as it can and fills up all inventories); 2. choose objective function type 8 asking to maximize total production: this scenario is similar to scenario 7 but it pays more attention to the current demand spectrum, but does not pay attention to cost either; 3. choose objective function type 4 asking to maximize total sales: this scenario enables you to check whether the flow from the production sites to the demand points operates correctly; it might happen that demands are just satisfied from inventory (note that the model does not see any cost and money related aspects; it will just sell as much as it can and may just reduce the inventories to their safety levels); 4. if 7 (or 8) and 4 work fine, choose objective function type 1 to maximize contribution margin; 5. if 7 (or 8), 4 and 1 work fine, choose objective function type 5 to concentrate on the design problem The user can activate or switch off certain types of constraints, e.g., controlling whether minimum utilization rates should be considered or not. 8.2.6.3 Relaxation of Constraints Sometimes, infeasibilities are very difficult to analyze. This process is supported by relaxing certain constraints. This concept is outlined using the F following example related to forced demand Ddpcwt , which can easily make (8.55) infeasible. (8.55) can be relaxed if the control parameter DORELSB is set to DORELSB = 1 which replaces (8.55) by     F F sLR sLdpcwot ≥ Ddpcwt Ddpcwt ; ∀ dpcwt ∃Ddpcwt ∧ ∃Ddpcwt dpcwt + o∈Odpcw

(8.84) which includes the additional variables sLR indicating which of the inequaldpcwt ities of the original constraint (8.55) cause the problem. The variables sLR dpcwt enter the cost term of the objective function as

196

8 Operative Planning in the Process Industry T

SLB

c

:=

N    

P 3Sdpcwt sLR dpcwt

.

d∈D p∈P c∈C w∈W t=1

Note that the specific costs associated with each of the artificial sales variables is three time as high as the sales price of the useful product; does not show up in the yield term of the objective function. There is an ASCII output file slr.out generated reflecting the solution values of the sLR dpcwt variables.

8.3 The SAP APO View on this Problem The basis structure of the MILP problem described in Section 8.2 is that of multi-location, multi-period, multi-purpose reactors. The purpose is to derive optimal production plans. On that abstract level one could claim that SAP APO is able to do this. However, the question is whether this is really the case when considering the philosophy of the existing planning approach and taking a closer look when inspecting the various constraints and planning aspects describing the problem in detail. Let us first summarize various aspects on the generic level before diving into the details: • •

Multi-location and multi-stage planning is possible. SAP APO supports a multi-period, discrete-time formulation allowing the user to choose the planning horizon. • Multi-purpose reactors can be modeled, but with an issue to keep in mind: mode changes are not sequence-dependent in SNP, this feature is reserved to short-term planning (PP/DS). A so-called setup matrix determines the setup operations necessary when changing from a specific mode to another and is only available in PP/DS. Section 8.3.4 provides further comments on modeling multi-purpose reactors in SAP APO. • Considering co-production is possible. Thus, SAP APO allows modeling the process industry example model on the whole. Locations, their corresponding location products, resources and the production process models can be defined in the master data. The mode changing aspects cannot be modeled in SNP at this level of accuracy, but in PP/DS they can. The sales of products can be modeled as in the mathematical formulation by including customers, distribution centers, or subsidiaries in the location master data. Locations can be connected by transportation lanes. Let us now discuss a few structural features impacting the overall modeling followed by detailed comments on the tailored MILP model. Where applicable, we will also give some ideas that may lead to the way the model can be formulated in SAP APO.

8.3 The SAP APO View on this Problem

197

8.3.1 (Non)linear Costs According to Sects. 8.1 and 8.2.4, production cost, change-over cost, transportation cost (between sites, between sites and demand points, and between demand points), inventory cost, and cost for external purchase (i.e., procurement) of products and raw materials are included in the model. With the exception of change-over cost for mode changes of a reactor, all of these cost types are directly maintainable in SAP APO (cf. Table 1.1 on p. 19). Change-over cost can be modeled via defining fixed cost in a cost function for a PPM, but this does not directly account for multi-period lots resulting from using the same PPM in two consecutive time buckets. If this is desired, cross-period lot size planning (cf. Sect. 4.2.1) can be used and the optimizer will only schedule one setup operation per production campaign using capacity on a setup resource which can be associated a cost. As nonlinear costs are beyond the scope of (MI)LP modeling, SAP APO uses the same approach of piecewise linear cost functions as the mathematical model does. See Sect. 4.2.1 for defining piecewise linear cost functions. Convex cost functions are characterized by a cost per unit that increases with higher volume and can be modeled in an LP. Concave cost functions (costs per unit decrease with higher quantity) require a MILP model. Material that has to be burnt because of a lack of demand can incur cost when modeled as product with associated shelf-life, for instance. However, a more detailed analysis of the business requirements and impacts on modeling is necessary to come to a final conclusion on this. Overall, these features are sufficient to model the basic idea of the raw material costs described in Section 8.2.4.1. 8.3.2 Objective Functions In SAP APO the mathematical representation of the objective function cannot be defined freely. As a consequence, custom objective functions are implemented either by adjusting the cost structures on the SAP APO application level or with development support from the optimization group of SAP. The model described in Sect. 8.2 supports ten modes of operation defined by ten objective functions as listed in Sect. 8.2.4 (pp. 181): Maximize contribution margin is the “standard” operating mode of the SNP optimizer. Because SAP APO regards the individual non-delivery penalties p of demands as lost revenue and uses a minimization objective function, (8.72) on p. 184 is transformed to its equivalent min(p + c). Maximize contribution margin while guaranteeing minimum demand is based on the same objective function, but the model includes an additional hard constraint that puts a lower bound on the total sales quantity. A constraint exactly like this is not included in the SNP optimizer and including it would require a custom project with the optimization group of SAP. A possible approach is to model this via the minimum lot size in the PPM (which also

198

8 Operative Planning in the Process Industry

applies to production campaigns). On the other hand, such a constraint could probably be implemented by introducing disproportionately high penalties for non-delivery that have to be removed in post-optimization processing. Minimize cost while satisfying full demand includes a hard constraint for exactly fulfilling each demand element, only costs are considered and revenue is ignored. Again, this constraint is not part of the model formulation in SAP APO, but can be simulated by introducing disproportionately high nondelivery penalties. Maximize total sales neglecting cost ignores all cost and maximizes the sales volume. This can be modeled in SAP APO by switching off all costs but the late and non-delivery costs in the SNP cost profile and setting these costs appropriately (cf. Sect. 4.2.2). Maximize net profit for design problems is a similar scenario to the first one (maximize contribution margin), but includes costs for purchasing new plants and opening/closing of reactors. As network design is no longer included in SAP APO this scenario cannot directly be modeled. Multi-criteria objectives (max profit & min transport) and (max sales volume & min cost) optimize regarding the first objective (i.e., max profit), and then seek a solution optimizing for the second objective (i.e., min transport) with an additional constraint limiting the deviation from the first objective function value. This cannot be implemented in SAP APO as-is, but depending on the individual business targets to be achieved similar results may be accomplished by setting an appropriate optimization bound profile (cf. Sect. 4.2.3). Maximize total production (for fixed design) neglects commercial aspects (costs and revenues) as well as limiting the sales volume to actual demand. The objective function is to maximize the total volume of produced product. In SAP APO this works by setting revenue values (non-delivery costs) proportional to sales volume neglecting “real” product prices. Dummy demands “pulling” product through the supply chain may need to be created. Maximize total production of products for which demand exists does the same as the scenario above, but considers producing only those products for which demand exists. Again, commercial aspects and the limitation of sales volume to demand volume is not included. In SAP APO this is modeled as above, but with zero cost for products without demand. Maximize total revenue (for fixed design), finally, is the same as the first scenario (maximize contribution margin), but without considering costs. This can be done in SAP APO by deactivating the appropriate costs in the SNP cost profile (cf. Sect. 4.2.2). 8.3.3 Demand Satisfaction SNP uses an approach different from the formulation in Sect. 8.2.3.10. The quantity of delivered product is of course limited to the total demand. This is equivalent to the constraint (8.54), but we have to keep in mind that SNP

8.3 The SAP APO View on this Problem

199

works based on quantity rather than order meaning the demand is the aggregate over all individual customer orders and forecast elements in a specific time bucket at a specific location. Instead of constraining the service level by including hard constraints on fulfilling a minimum fraction of each demand, the SNP optimizer uses the cost structure to ensure demand fulfillment. Obviously, post-optimization analysis would then be needed to “correct” the non-delivery penalties to reflect the actual revenue. As an example, total demand fulfillment can be enforced by making purchasing product externally accordingly cheap compared to the lost revenue. 8.3.4 Detailed Comments on the Tailored MILP Model The detailed comments in this section follow the structure of Sect. 8.2. The model objects described at the beginning of Sect. 8.2 (p. 146) are translated into master data directly following from our description of modeling in SAP APO in Chapters 3 and 4. 1. Products: They are actually called products in SAP APO and for their location-specific properties the master data element location product is used. By using this concept production, procurement, storage, etc. are modeled by location where the product can occur. 2. Production Modes: In essence, the mode a reactor can operate in defines the available production processes that can be run on the particular reactor. In SNP this is modeled by using one or more production process models (PPMs) per mode. The reactor itself is modeled as a resource the capacity of which is consumed in the PPMs representing the different modes of production. The product to produce along with considerations concerning mode changes determine which PPM is selected. Co-production is part of the PPM and considered by the optimizer. Mode changes are modeled as production campaigns that eliminate setup operations and setup costs if the same PPM is used for production in consecutive time buckets (called time slices in Sect. 8.2). For using such production campaigns cross-period lot size planning which considers setup operations (here: mode changes) for the same PPM in the previous time bucket has to be activated in the optimization profile (see Sect. 4.2.1). Currently (SAP APO release 4.1), in the SNP optimizer setup operations cannot be modeled depending on the mode the reactor is changed from. As a consequence, sequence-dependent mode changes as required by the process industry example cannot be implemented using SNP. Following the hierarchical planning strategy, however, sequence-dependent mode changes can be modeled in PP/DS via the setup matrix . 3. Production Sites: In SAP APO, these are modeled as locations of type production plant that are connected by transportation lanes.

200

8 Operative Planning in the Process Industry

4. Demand and sales points: In SAP APO, these are modeled as locations of type distribution center, customer, or even as production plants that are connected by transportation lanes. Choosing the location type depends on modeling preference and business requirements. 5. Reactors: The basic properties of the reactors are described in the resource master data. The PPMs (see above) connect the reactors to a production network and represent the different modes of production. 6. Inventories: In SAP APO inventory can reside at each location. Depending on the required level of detail inventory constraints such as maximum product-specific storage quantity are specified in the location product master data or modeled more flexibly by assigning storage resources to locations. 8.3.4.1 Basic Assumptions and Limitations 1. The SNP optimizer does not specifically restrict the number of setup operations per period. However, setup costs and setup times will most likely lead to small numbers of mode changes. Note the issue regarding mode changes described in Sect. 8.3.4. 2. Transportation times and costs can be specified using cost functions. It is not possible to provide probabilistic transport times in SAP APO. 3. Variable inventory costs containing the capital binding costs can be modeled in SAP APO. 4. In SAP APO resource utilization rates and constraints on them refer to time buckets. 5. Table 1.1 on page 19 lists the types of costs that are considered by the SNP optimizer. The time-dependent costs can, of course, be discounted over progressing time buckets. Some of the remaining costs (such as production cost, for instance) can be made time dependent when the underlying objects (the PPM, for instance) are made valid for certain time buckets which results in a high number of PPMs to be maintained. 6. Multi-product inventories with product-specific constraints are possible in SAP APO. However, there is no mechanism that restricts the number of different products that can be stored at any given time in the SNP optimizer. Also, sequence-dependent mode changes in inventories cannot be modeled directly. This would require certain sequence-dependent operations such as tank cleaning connected to discarding of remaining inventory – either burning it off or consolidating into other tanks. When moving to PP/DS, container resources might be an option. 8.3.4.2 General Framework of the Model As the mathematical formulation of the SNP optimization model is not publicly available a detailed comparison to the mathematical formulation in

8.3 The SAP APO View on this Problem

201

Sect. 8.2.2 is not possible. Most aspects are implemented in a similar way in SAP APO, some – like time discretization – are approached differently. The time discretization distinguishing between commercial and production time slices would most probably be modeled as a post-optimization planning book feature in SAP APO: the planning itself would take place on the more detailed time buckets and the results would be aggregated in according planning books for the different audiences (sales, marketing, production, etc.). 8.3.4.3 The Mathematical Model – the Constraints Again, we cannot give a detailed comparison of the SAP APO optimization model and the equations in Sect. 8.2.3 due to the confidentiality of the mathematical model formulation. In SAP APO multi-stage production processes are modeled by generating several PPMs which can include co-production. How to deal with modechanges and setup-changes is mentioned above in Sects. 8.3.1 and 8.3.4. Minimum Production Requirements on Products This section includes lower bounds on absolute production quantities as well as bounds on utilization of the reactors. There is a large variety of details involved in these constraints. In SAP APO one possibility is to include constraints on resource utilization by defining resource variants (see Sect. 3.2.4.2); this translates into bounds on utilizing the reactors. Minimum production quantities of certain products cannot be modeled explicitly; workarounds via the cost structure or minimum lot sizes on PPM level exist and have to be aligned with the client’s business objectives. Batch and Campaign Production Batch and campaign production has an aspect regarding mode changes and minimizing setup costs and time and additionally we can limit production quantities to integral multiples of a batch size. The first issue has been mentioned multiple times in this chapter (Sects. 8.3.1 and 8.3.4); the condition of producing integer-multiples of one batch is used in our supply chain example described in Chapters 3 and 4 and is activated in the discrete constraints section of the SNP optimizer profile (see Sect. 4.2.1). Modeling Stock Balances and Inventories In the master data one needs to define which locations have inventory entities. Inventory has the attributes capacity, safety stock, storable product(s). Additional stock capacity can be leased at higher per unit costs than the normal capacity. In SAP APO this is modeled as accordingly higher costs or as a penalty cost term if the regular capacity is exceeded. Depending on

202

8 Operative Planning in the Process Industry

the required complexity storage resources may be used and assigned capacity variants. With the exception of multi-mode inventory that can hold only one product out of many at any given time SNP could handle the functionality of the model. Multi-mode inventory can be modeled using container resources in SAP APO (those can hold only one product at a time), but they are available in PP/DS only. Dedicated Inventories at Sites (Free Origins) SAP APO allows defining inventory points that can store specific products. Via modeling those inventory points as locations with associated transportation lanes we can control possible sourcing of the stored material. Safety stock constraints are part of the SNP model and can be considered at any location in the supply chain. Modeling Transport All three kinds of transportation, between production sites, from production sites to demand points, and between demand points, are modeled as transportation lanes in the same way. The lanes can have product-specific properties such as costs, minimal and maximal lot sizes, and transport duration. Due to the nature of minimal lot size constraints, one might expect they are implemented using semi-continuous variables. The SNP optimizer uses the bucket offset to determine the availability of a transportation operation ending within one time bucket (cf. Sect. 3.2.7). There is no probabilistic approach in SAP APO or a direct way of modeling mass loss during transportation. Keeping Track of the Origin of Products As SNP works quantity driven rather than order driven, order tracing is not supported by the SNP optimizer. The existing mathematical model simulates this tracing by adding an index to each production variable which corresponds to creating a separate product in SAP APO according to its origin (which is, although extremely cumbersome, in principle possible). If production was a single stage process the requirements could be fulfilled by adding and removing transportation lanes. In the process industry example there is also the constraint that there are customers or aggregated demands that must be satisfied from the same unit, but which unit is not fixed. This cannot be modeled explicitly in SNP, the reason again being in the fact that SNP optimization looks at quantities in time buckets, not orders.

8.3 The SAP APO View on this Problem

203

8.3.4.4 Description of the Outputs In principle SAP APO produces the same output as in the output tables mentioned in Sect. 8.2.5.3 above. The difference is that the SAP APO business user will not look at tables like these, but expects an easy to use and to digest representation. Therefore, the optimization results would be fed into one or more SNP planning books (cf. Sect. 4.3.1) that show an arbitrary combination of the output data tables and allows the user to interactively drill up and down, produce interactive graphics, etc. The planning book functionality goes far beyond what we showed in Sect. 4.3.1 and includes macro processing, alerting, drawing diagrams, etc. For diagnostic reasons the optimizer logs show the input and output data for the optimizer in a similar way as displayed in Sect. 8.2.5.3. The log files can be downloaded from the SAP APO application and look very similar to the tab-separated flat files we see in the example here. Therefore, it is a fair statement that SAP APO can produce the same kind of output as the mathematical model for the process industry here, but can display it in a far more user-friendly way. As modes are modeled differently in SAP APO, the production and mode changing plans would need some considerations. Of course the required information is contained in the SAP APO data structures resulting from an optimization run (keeping in mind the functional SNP limitations mentioned above in Sect. 8.3.4): the planned order quantities are connected to PPMs and resources, and these are the elements modes are modeled with. The gap in reporting is origin tracking: as it is – as we mentioned in Sect. 8.3.4.3 – not provided by SNP it is also not part of the output data. 8.3.4.5 Diagnosing Infeasibilities SAP APO produces an application log indicating problems, warnings and other information produced during an SNP optimization run. They are ordered according to their significance (control parameters of the optimizer, etc.). Additionally, there are logs that detail the master and transaction data considered by the optimization run, output logs detailing the individual tables, trace files, cost logs, solution quality logs, etc. However, there is no automated diagnosis of infeasibilities as such (SAP APO release 4.1). 8.3.5 Concluding Statement Once an existing mathematical supply chain model is sufficiently understood, it can be “formulated” in SAP APO with a certain likelihood. We put the word “formulated” within quotation marks as a completely different way of thinking is required when dealing with supply chain modeling tools like SAP APO. Given a fixed set of variables and constraints – and keeping the mathematical consequences of the modeling steps in mind – a surprisingly large variety of

204

8 Operative Planning in the Process Industry

problems can be covered, modeled and solved by SAP APO. The likelihood of succeeding depends on the detailed features and on the degree to which they can be implemented using the fixed mathematical model. In the current case the replacement of the model by the SNP optimizer in SAP APO for simultaneous mid-term and short-term planning turns out to be impractical because too much reality would be lost. Aspects like straightforward production planning, simple mode changes and campaign planning will be implemented successfully if the modeler is willing and able to understand the planning philosophy of SAP APO. On the other hand, features like multimode reactors and inventory and keeping track of origin are simply not part of the built-in model formulation and will act as show stoppers in the tool selection phase. Modeling the multi-mode features to the required level of detail would require significant changes to the mathematical model in SNP and are not likely to be included with manageable effort from both the customer and SAP sides. On the other hand, it has to be noted that SAP APO follows a different planning philosophy, hierarchical planning, and comparing just one component of this hierarchical planning with a simultaneous approach might seem unfair. In this concept, mid-term planning (SNP) operates on a lower level of detail and integrates into short-term planning (PP/DS) operating on a higher level of detail. If it is practical to adopt this layered planning approach for the client, PP/DS will provide the functionality that has been missing in SNP. The decision is dependent on the specific business needs and also on the nature of the model. Some companies therefore decide to adopt the hierarchical planning approach (and accept the different mathematics provided by PP/DS), others use a custom-built optimization application and use the superior evaluation capabilities of SAP APO interfacing the two applications (we elaborate more on this in Chapters 7 and 9). The latter is true especially for companies that are traditionally strong in the nature sciences such as chemistry, physics, and mathematics (e.g., the chemical industry). Another indicator for the bigger flexibility of the “pure” mathematical formulation is the arbitrary definition of objective functions, even of those that do not make sense in an economics environment and are just used for testing the model. But we also observe that most of the “non-economic” objective functions can be simulated in the SNP optimizer. Although it is understandable that there is no detailed public domain documentation of the SNP mathematical optimization model available it makes it very difficult to find out whether SNP maps an existing model well enough or not. Strong expertise in both domains is necessary for successfully conducting an assessment like this. Thus, from the current case we learn that the time and effort to make the differences between SNP and an existing model apparent are not at all negligible.

9 Case Studies – Interfacing Tailored Models to SAP APO

We briefly summarize various case studies in which tailored optimization models have been interfaced to SAP APO. In two out of three cases described in this chapter the SNP optimizer is used and external models complement the SAP APO TP/VS component, in the third case a tailored optimization application is interfaced to SNP. This chapter illuminates indirectly how optimization in SAP APO could be improved, indicates alternative tracks and focusses on problems and issues to be considered when taking such an approach. Section 9.2 and 9.3 have been contributed by R´emi Lequette (ILOG) and Axel Hecker (Mathesis GmbH, Mannheim, Germany), respectively.

9.1 Developing Tailored Models If the decision has been made that an optimization model external to SAP APO has to be built to solve the problem at hand the question is: How do we construct the mathematical model corresponding to the problem? This task is not easy and requires experience. Let us approach this task by the following statements: • • •

there is no recipe to construct mathematical optimization models, experience is important, there is nothing like a model which could be considered uniquely as the correct one, • several models might serve the purpose, • keep the model as simple as possible and as complicated as necessary [Saint-Exup´ery: A draft is not ready if you cannot enhance it any further, but rather when you cannot eliminate anything more]. Despite these difficulties here are a few constructive advises: • Definition of the problem and the purpose of the model: A well formulated description should be the basis for defining the purpose of the model.

206

•

• •

•

• •

9 Case Studies - Interfacing Tailored Models to SAP APO

Defining the limit of the problem: Define clearly what belongs to the problem or model and what not (example: a production planning system for medium- and long-term may neglect those aspects needed in detailed scheduling based on a time resolution of minutes). Identification of important model objects (example: products, production sites, inventories, transport lanes, etc.) and a verbal description of the relations among them. Acceptance and user : The model formulation should be appropriate to the problem, the purpose of the problem and the potential user. Usually, it is problematic and negative for the acceptance of the model if the model builder is not aware of all relevant relations. A vehicle routing system might experience some difficulties among the truck drivers if the modeler was told to minimize the driving costs but each truck driver’s income depends on the value of the goods delivered. In that case, each driver prefers tours with only one piece of valuable furniture rather than tours involving many cheap goods. In the beginning, a scaled-down version of the model might help to develop some basic understanding and to check whether all features were understood properly. This also leads to a good communication base between the modeler and the client. Subproblems and substructures in the model might be treated separately in the beginning to develop efficient formulations. Parts of the real problem may be too difficult. It should be discussed whether they are really relevant or whether they can be approximated.

What is the benefit of the model? A well designed and documented model allows the user to derive rationaly based conclusions and provides transparency. It helps to interpret the problem and may lead to further insight. If the model is properly validated one should still keep in mind that the model reflects only a part of a richer reality.

9.2 The ILOG Cartridge Concept1 In 1999, ILOG introduced the cartridge concept: an external optimizer that extends an SAP APO system, and launched the Optimization Development Framework (ODF), a set of tools and a methodology for building cartridges. Since that time more than half a dozen cartridges have been developed with customers, partners and ILOG Professional Services. The projects undertaken range from medium to large scale, being independent of or embedded in major SAP implementations. Some included graphics (User Interface); all successfully went live or are close to go-live. The aim of this section is to share ILOG’s experience with companies considering an extension to their existing 1

R´emi Lequette, ILOG, 9 rue de Verdun, F-94253 Gentilly Cedex, France, Email: [email protected], http://www.ilog.com

9.2 The ILOG Cartridges Concept

207

or planned SAP APO system to fit specific business needs. We hope this information will help them to gather input before taking a decision. We will not discuss the optimization problem in itself. Of course, the feasibility of an optimizer is a major driver and a showstopper for a project, but this subject is well covered in the rest of this book and can be fairly assessed by specialists. It is also project dependent by nature, and instead we would like to direct attention to other factors that are common to all projects. The first part in Sect. 9.2.1 briefly gives some background about ILOG. The second and the third parts in Sects. 9.2.2 and 9.2.3 present two examples of cartridge solutions developed by ILOG. The bulk distribution cartridge optimizes vehicle routing for the distribution of liquefied gases. The load builder optimizes vehicles loading in the beverage industry. For each project, we describe the supply chain, the reasons to use SAP APO, the motivations for a cartridge, the outline of the solution and give project information: skills and timeline. The fourth part in Sect. 9.2.4 describes the architecture of a cartridge. This is an IT oriented part covering the integration with SAP APO and the internal architecture of the cartridge. The fifth part in Sect. 9.2.5 presents ILOG experience in the methodology for cartridge projects. This part covers the skill requirements, the project phase and the major risks. The project phases are based on the RUP methodology (Rational Unified Process): It starts with the inception phase where the decision to go for a cartridge is taken, followed by the elaboration phase where specifications are developed. The third phase is the construction phase where the cartridge is built. This phase has usually multiple iterations. The last phase is the transition phase covering go-live and support. I want to thank all the people involved in the cartridge business, our customers, our partners (especially at axentiv), the ODF team within ILOG and ILOG consultants, with special acknowledgements to Fred Garrett, principal consultant for ILOG Inc. who contributed the information about the optimizer in the load builder cartridge. In addition to the two case-studies presented in this chapter, Chap. 7 contains two case-studies including cartridges developed by axentiv in the automotive and chemical industries. 9.2.1 ILOG Background ILOG was created in 1987 and is a major supplier of software products in three areas: optimization, visualization, and business rules. The optimization products are ILOG CPLEX for LP (Linear Programming) and MIP (Mixed Integer Programming) and ILOG Solver for constraint programming. ILOG Solver has two extensions: ILOG Scheduler for scheduling problems and ILOG Dispatcher for routing problems. The visualization products are ILOG Views, a C++ library to build graphical user interfaces (GUIs) with advanced 2D graphics such as charts, maps and ILOG JViews products, Java libraries and GUIs for advanced 2D graphics. The business rules product is ILOG JRules,

208

9 Case Studies - Interfacing Tailored Models to SAP APO

a Java-based Business Rule Management System to allow the capture, execution, and management of business rules in software applications by business users using natural language. ILOG customers can embed the libraries in software applications and use the GUIs to develop software applications. These customers may be end users building in-house software applications or ISVs embedding ILOG technology in commercial software. ILOG provides professional services to assist customers. SAP is a major ILOG ISV in the context of the SAP APO system, the SNP optimizer for instance is based on ILOG CPLEX. 9.2.1.1 The Optimization Development Framework and Cartridges When ILOG detected the opportunity to develop external optimizers integrated with SAP APO, it developed ODF to facilitate the development of cartridges to plug in to SAP APO. ODF is a workbench for building cartridges; it is based on code generation, libraries and template cartridges implementing a predefined architecture. ODF plugs in to the APX (SAP APO Optimization Extension Workbench) which is a standard component of SAP APO. ODF embeds ILOG experience with an architecture validated by projects. Cartridge development started in 1999. Cartridges have been developed by ILOG Professional Services, customers’ IT departments and software service companies. Typical areas where cartridges have been developed are vehicle routing, vehicle loading, planning of chemical reactors, supply network planning in the high tech industry, planning of plastic extruders, paper production planning and trimming, and food and beverage production planning. 9.2.2 The Bulk Distribution Case Our first cartridge example is in the area of vehicle routing, with additional constraints due to the nature of the product distributed: bulk liquid gas. 9.2.2.1 Business Context The United States-based company produces liquid gas from air (oxygen, nitrogen) and distributes it via different channels: pipeline, trucks, and cylinders. The customers who receive deliveries by truck store the liquid gas in tanks. These tanks are owned by the supplier, who monitors their content and decides when they should be replenished. This is a typical VMI (Vendor Managed Inventory) process: the suppliers must forecast consumption to decide on the best delivery time; too late will result in a stock out, too early will result in a bad ratio of transportation cost to quantity of product delivered. The product is delivered in bulk, which means the quantity can be adjusted. Typically, the truck will visit a customer site and fill the tank, unless there is not enough gas left in the truck in which case the quantity will depend on the current content of the tank.

9.2 The ILOG Cartridges Concept

209

The later a delivery happens the larger is the required replenishment quantity. Some customers have high demand and require one or more full truckloads but a significant percentage (around 50%) requires partial truckloads. Two to four tanks may be serviced by the same truck and it may be worth including a customer in a trip even if the tank level is not close to the reorder point to avoid an isolated trip later. 9.2.2.2 SAP APO Project The company launched a supply chain initiative and selected SAP APO release 2.0. The DP module was selected to forecast customer consumption, SNP plans the production at the plants (air separation units) and dynamically assigns customers to plants. Note that in this industry this assignment (called “sourcing”) is usually performed statically on a quarterly or monthly basis. It was an innovation to plan production and sourcing concurrently on a daily basis using the SNP optimizer (based on linear programming). A substantial economy was expected from this process, as the cost of production is the cost of electricity, which is subject to frequent variations with short notice. Note also that PP/DS was not deemed necessary as the production plan only requires to know the quantity of air to liquefy each day in each plant. The TP/VS module, new at that time, was selected to plan the daily dispatch of trucks. There were specific business requirements, however, and SAP made a joint offer with ILOG for a cartridge extending TP/VS with a routing optimizer. The company did not use the SAP R/3 ERP system, but kept the existing legacy system (developed internally) for business execution. An interface between this system and SAP APO was developed during the project uploading the consumption history and product inventories, and downloading the production plan and shipments (routes). 9.2.2.3 Cartridge Motivations The SAP APO database and liveCache can model the truck shipments efficiently but some customer requirements called for a specific development. Some are general requirements for a routing system, but others are specific to bulk distribution: Geographical display: The user expected a visual display of the routes on a map. Geographical data: The user expected real distances and driving durations to be used by the route optimizer. A previous optimizer based on crow-flight distances gave unsatisfactory results. Driver and tractor resources: The company has its own fleet of trailers and tractors and the drivers are company employees. TP/VS consider one vehicle resource per shipment (the trailer), but was not able to model tractors and drivers. Management of drivers includes the total monthly work time, the

210

9 Case Studies - Interfacing Tailored Models to SAP APO

legal limits on work and driving hours, and more specifically the use of team drivers for some long trips (this is specific to argon gas where there are far fewer plants). Source and product substitution: SNP does a tactical assignment of source to customers based on historical cost, but this assignment may be changed on a daily basis to fine-tune the current routes. The routing can consider an alternative source of product for a customer if that improves the dispatch time. It can also consider product substitution. Liquid oxygen and nitrogen have two grades: industrial and medical. The difference is an additional quality check, so that medical gas (the higher grade) can be delivered to industrial customers. It may make sense to include an industrial customer in a trip that visits hospitals to reach a full truckload. The source substitution feature requires the distribution optimizer to know the daily production cost in order to evaluate the opportunity for substitution and it has to know the SNP production plan. The original SNP sourcing is compatible with production, but when the distribution optimizer changes the source, it must include checks avoiding too much product being pulled from a plant. Outsourcing: The customer tanks can also be serviced from external sources (competitors); the trailer will then be filled at the competitor site instead of an own plant. The optimizer takes this decision based on the cost and availability of the product. Some outsourcing contracts are take or pay agreements, which means an agreed quantity must be taken during a given period. The optimizer keeps track of this “free” quantity to avoid losing it. Some contracts allow taking extra product at a certain price. Some contracts also require a minimum daily take. Bulk delivery: The ability to adjust the quantity delivered depending on the time of delivery based on the consumption forecast is required. In the project, this feature was called “variable demand”, to stress that the actual demand depends on the time of delivery. Duration of visits: The duration of a delivery is the pumping time dependent on the quantity of product delivered, the vehicle, and the tank. For one product (hydrogen) there are two options, either the gas is pumped (this is called “bumping”) or the trailer is just swapped with the tank; a swap takes a fixed time. The duration of the visit may be increased when a technician comes for tank maintenance which is typically the case for the first visit. The duration of the initial visits in plants to fill the truck also depends on the trailer size and the plant. If there is enough time it is possible to plan a refill of the trailer at the end of the day. Then the next day this trailer can skip the initial plant visit and go directly to the first tank. Dispatching constraints: There are many other constraints which can make a route invalid if they are not enforced and which have to be considered by the optimizer. For example: •

Product - vehicle compatibility: Not all trailers can carry all products.

9.2 The ILOG Cartridges Concept

211

•

Vehicle - customer compatibility: Some customers require dedicated trailers (for example with their names on), but also some trailers cannot reach some customer facilities for various reasons. • Position of customer in route: Some customers must have, or cannot have, a given position in a route (first, last). A typical example is a tank on a hill: the trailer must be full when filling the tank; otherwise there will not be pressure. • There is a minimal delay between visits to the same customer, to avoid bringing small quantities (even if it would make sense for cost reasons). • Some plants cannot source some customers for quality reasons. We did not list all specific constraints to keep this short. Some of them were not really showstoppers, but when the main obvious gaps were detected and the decision to build a specific optimizer was taken it made sense to list all business constraints and incorporate them. 9.2.2.4 Solution Outline Three cartridges were developed by ILOG for this project: the lane cartridge is used to update the distance and driving durations in the SAP APO database by a batch job; the GUI cartridge runs on the workstation to control the optimization process and display the routes on a map; the optimizer cartridge is running on a server computer to compute the routes. Geographical Information Software (GIS, in this case PCMiler from ALK) was embedded in the cartridges for distance and duration computations and for graphical display of the routes on a map. From the user perspective, the cartridges are viewed as extensions of SAP APO, they are started from SAP APO transactions. They do not have persistent data storage; instead they use the SAP APO database and LiveCache. The daily planning activities start every night. First, the inventories in plants and customer tanks are uploaded in SAP APO from the execution system. Then, DP runs and produces a forecast of tank consumptions. This is followed by an SNP optimizer run creating a global production and sourcing plan for the whole country. The production plan is then downloaded to the execution system and the distribution planners (called dispatchers) work during the day with SAP APO to produce the routing plan for their region; a dispatcher administrates a terminal and a set of plants. Note that the customers are dynamically attached to the region by SNP plant assignments. A special case is the argon gas dispatcher who plans for the whole country using team drivers. There are significantly less argon than other plants. The dispatcher will typically run the cartridge for a one-week horizon starting the next 12-hour shift and may perform more than one run during the day to try different optimization objectives or consider changes in the data. The routes are stored in the SAP APO system between cartridge runs. At the end of the 12-hour shift the routes for the next shift (or a few shifts

212

9 Case Studies - Interfacing Tailored Models to SAP APO

in the case of weekends or holidays) are downloaded to the execution system. The next cartridge run will consider this released period as firmed. During the day, in addition to planning with the cartridge for the upcoming shifts, the dispatcher will also spend a significant amount of time reacting to current unexpected events. He or she will modify the current day’s routes directly in the execution system. The Lane Cartridge The lane cartridge is not an optimizer but follows the same architecture as optimizer cartridges. Its purpose is to update the SAP APO database with up-to-date distances and driving durations computed with the PC Miler GIS software. SAP APO offers a database structure called transportation lanes, which is initialized based on a straight line between geographical coordinates and a speed depending on the transportation type. The lane cartridge shows a simple use of the ODF technology interfacing with SAP APO. It relies on a BAPI (Business API) to update transportation lanes. The lane cartridge is started from an SAP APO transaction (see the architecture in Sect. 9.2.4). This transaction is used by system administrators to update the SAP APO database when new customers are added or when the GIS database is updated with new geographical information. The optimizer cartridge itself does not access the GIS software but relies on the data stored in SAP APO. This is faster as PC Miler takes about one second to compute a route between two points. While this in itself is very good performance it cannot be used dynamically by the optimizer to solve the dispatching problem. The Graphical User Interface Cartridge The GUI cartridge is started from the SAP APO TP/VS transaction and runs on the planner workstation. The technology to start a GUI cartridge is explained in the architecture Sect. 9.2.4. The GUI cartridge reads the current set of SNP orders and routes in the TP/VS transaction, so there is no need to provide any selection; the cartridge is completely integrated with TP/VS and leverages its data management. Using the GUI the dispatcher can perform multiple functions. He can display the set of orders (customer tank, quantity and plant assigned by SNP), visualize the current routes in a table or a map (at the beginning of the day there are none), and compute KPIs: the global mileage and costs and the mileage and cost by shipment (costs are described in the next Sect. 9.2.2.4). It is possible to prepare the optimization run, exclude some orders, and firm some routes, change the weights and costs for the optimization objective, choose the first shift and the number of shifts defining the horizon, and finally relax some constraints (compatibilities, accessiblities, time windows) or forbid product or source substitution. The dispatcher can request optimization; the optimizer cartridge will then run on a specific computer (server) under the control of the GUI, and he can examine the new routes resulting from the

9.2 The ILOG Cartridges Concept

213

optimization and their KPIs. And, finally, there is the option to save the routes in SAP APO, or simply leave the cartridge without saving. The GUI cartridge was developed by ILOG using the C++ language and the tools: ILOG ODF, ILOG Views for graphics, and PC Miler for the map. Figure 9.1 shows how the cartridge is started from SAP APO TP/VS. The user requests optimization and is presented with a choice between the standard optimizer and the cartridge. Then the cartridge starts and the screen with optimizer parameters is shown. Figure 9.2 is a screenshot of the map with the shipments built by the cartridge.

c SAP AG Fig. 9.1. Starting a cartridge from within TP/VS, partly


The Optimizer Cartridge The optimizer cartridge is started on a specific server by a request from the GUI cartridge. The cartridge reads all data it needs from SAP APO, there is no separate database. The master data are trailers, drivers, tractors, including availability times and remaining work hours, plant information (pumping time, etc.), tank information (size, accessibility, etc.), opening hours for terminals, plants, customer facilities, distances and durations, and competitor contract data for outsourcing. The transaction data are the selected orders (tanks, quantity and source assigned by SNP, the current inventory in plants and tanks, the forecast consumption in tanks and production in plants and the existing routes). The optimizer computes an optimal solution by minimizing an objective function, which is a weighted sum of different KPIs: •

Mileage cost: Cost based on route mileage, depending on vehicles.

214

9 Case Studies - Interfacing Tailored Models to SAP APO

Fig. 9.2. Cartridge map with shipments

•

Penalty cost: Cost incurred for late or failed delivery, i.e. a stock out is anticipated for a customer tank. There is a cost for non-delivery within the optimization horizon (a week) and a cost for delivering late, both costs are dependent on a priority assigned to the order; the costs for each priority level (1 to 4) can be modified in the GUI. • Sourcing cost: This is the cost for taking the product in plants or outsourcing locations; this cost is relevant only if source substitution is allowed. • Stop cost: This is a cost incurred when time on a route is not spent on driving. It could involve waiting for a place to open, filling the trailer or a tank, or an overnight stay because the driver has exceeded a driving time or working time limit. This cost drives the optimizer to make efficient use of trailers, drivers and tractors. • Payload cost: This is a cost incurred if some product is left in the trailer after a route when it goes for refill. This cost drives the optimizer to group deliveries in full truck loads. The optimizer was developed by ILOG using the C++ language and the tools ILOG ODF, ILOG Dispatcher, a library for routing optimization (known as TSP: Traveling Salesman Problem), and ILOG Scheduler, a library for scheduling optimization; scheduling problems are in the driver-tractor constraints for example. ILOG Dispatcher and Scheduler are both based on ILOG Solver, a library for optimization using Constraint Programming. The strong

9.2 The ILOG Cartridges Concept

215

point of constraint programming is the ability to incorporate specific constraints, such as all the constraints found in this project. 9.2.2.5 Integration While general features of cartidge integration into the SAP system is given in the cartridge architecture Sect. 9.2.4 below, we here state specific features in this project. The APX in SAP APO was used for integration in the TP/VS interactive planning transaction. SAP APO standard BAPIs were used to read TP/VS data such as SNP orders and shipments, to write TP/VS data such as modifying the source and quantity in orders and creating and modifying shipments, to read SNP planning books for inventories, production and consumption (forecast), and to read master data: locations (including tank capacity, reorder point), transportation lanes, resources (vehicles, time windows). Custom tables were developed in the SAP APO database with the ABAP workbench for additional master data to model terminal data, drivers, trailers, trailer data, compatibilities (trailers, products, tanks), outsourcing contracts, and product substitutions. Note that some “custom” data was stored in SAP APO custom fields and read using standard BAPIs. For example, the plant and tanks pumping rates were stored in a location master custom field. For this project, SAP APO release 2.0 was used. 9.2.2.6 Project Information This information is for the cartridge project (ILOG) part, not for the overall SCM project which additionally included SAP APO DP, SNP customization, the interface with the legacy execution system, training of users (including in cartridge use), and cutover and go-live (including the cartridge). The project was supported by SAP who specifically enhanced SAP APO with the APX to insert additional optimizers (in TP/VS) and the BAPIs to exchange data with TP/VS. Note that this project received an APICS Technology award in 2003. See: http://www.sdcexec.com/article arch.asp?article id=4660. More information about this project can be found also at: http://www.sap.com/solutions/ businesssuite/scm/pdf/MG Industries Case Study 300 DPI.pdf

Sizing The optimization cartridge is used 1 to 10 times a day by 10 dispatchers. A typical run covers 200 orders, 180 customers/tanks, 25 trailers, 4 factories/sources, 5 products, and 19500 lanes. This problems was solved within 15 minutes on a high-end PC in 2002. The data exchange with SAP APO takes around 5 minutes.

216

9 Case Studies - Interfacing Tailored Models to SAP APO

Timeline September to December 2000 : Specifications of the optimizer, and pilot optimizer with legacy data (no integration and GUI). January to May 2001 : Specification of the user interface and IT integration (one month), development of enhancements by SAP, and the development of the cartridges. June to September 2001 : Testing and intermediate deliveries; DP, SNP go-live in July; and cartridge go-live in September. Staffing ILOG Professional Services’ involvement in the project was in the areas of optimization (two consultants part-time for a total of 12 man-months), the development of the GUI (one consultant for a total of 2 months), and architecture and integration (one consultant part-time for a total of 6 months). Additionally, other parties contributed specifically to the cartridge: customization of SAP APO and ABAP development for custom tables (1 month) and user involvement in specifications and validation (approximately 3 months). 9.2.3 The Load Builder Case This second project was more complex in scope and was embedded in a larger SCM project. The purpose was the loading of vehicles with pallets of beverage. 9.2.3.1 Business Context This company, also located in the United States, is a major producer of beverage. The supply chain is composed of the following elements: 3 plants, one very large and two smaller, 11 distribution centers (DCs), 550 distributors who serve the retailers (stores, bars, and restaurants), and 150 SKUs (products with different packaging). There are two kinds of distribution channels: via the indirect channel, the distributor receives deliveries from a distribution center, via the direct channel, the distributor receives deliveries directly from a plant. This distinction depends on the volume, so a distributor may be direct for some products and indirect for others. Distribution centers receive deliveries from plants. There are also export customers who receive deliveries from plants. Four modes are used for distributing the goods: rail is used between plants and most distribution centers and also to some large distributors, truck is used with most distributors , intermodal shipments – a truck loaded on a train – is considered like the truck for loading as the process uses the same docks, and sea is used only for export (containers). For a given distributor-product pair the choice of the source (plant or DC) and the mode of transportation is determined statically; this assignment is reconsidered on a regular basis (once

9.2 The ILOG Cartridges Concept

3 Plants

10% T, 90% R

11 Distribution Centers 100% Truck

% 75 % 25 k, uc Tr

“Indirect Channel” Plant – DC -Distributor

Ra il

“Direct Channel” Plant – Distributor

217

550 Distributors

Retail

•“Bulk Beer” is also shipped between plants (out of scope) •Top 50 distributors are 40% of volume •Mode = T or R, Inter Modal (Truck on Rail) is accounted as trucks •Shipments are tendered to Carriers

Fig. 9.3. Beverage supply chain

a year). The company does not own the transportation fleet, all shipments are tendered to carriers. Figure 9.3 summarizes the supply chain. The company plans on a weekly basis. Distributors place their orders a few weeks in advance. At the beginning of the week, a replenishment plan for plants and DCs is established for the following weeks, based on the planned inventories and the demands. Then the bulk production of beverage for the next week is planned and shortly after that the detailed plan for packaging in the plant is elaborated. In the middle of the week transportation is planned first from the plants to the DCs and direct customers, then from the DCs to customers. The transports are tendered. During the rest of the week, the production and transportation plan is modified. At the end of the week the plan is released for next week. During the week, the plan established the previous week is executed and modified to react to unexpected events. Exportation is planned a few weeks in advance, but this does not change the principles. The major activity in transportation planning is not routing (all vehicles serve a single destination) but defining the content of the vehicles (trucks, railcars) and their departure times. Many distributors will receive more than one vehicle during the week. This activity (called load building) was the scope of the project. Interestingly it seems to be in the same area as the previous project described in Sect. 9.2.2 (transportation) at first sight, but is in fact very different. In the bulk distribution case the content of the vehicle is clearly defined (an oxygen trailer is full of oxygen) and the issue is the destination. in the load builder case the destination is clearly defined (each load goes to one distributor) the issue is the content of the load.

218

9 Case Studies - Interfacing Tailored Models to SAP APO

9.2.3.2 SAP APO Project The company launched a major supply chain project with SAP R/3 and SAP APO with the objective to reduce the lead-time between order and delivery to two weeks and at the same time significantly improve delivery accuracy (distributors order on the internet). Note that a first anticipated consequence of this project was a diminution of distributor’s safety stock leading to an initial drop of sales. All SAP APO modules were involved: DP for forecast, SNP optimizer to plan the network (replenishment) and for deployment, PP/DS for detailed scheduling of packaging, and TLB (Transport Load Builder) and TP/VS for load building. As load luilding was out of the scope of SAP APO for reasons described in Sect. 9.2.3.3 (note that the project was started mid-2002 as stated in Sect. 9.2.3.6) and the company expected an integrated solution SAP recommended ILOG. The company had previously developed a load builder for their legacy system. Based on this experience and with ILOG expertise, a load builder cartridge was successfully integrated in the project. 9.2.3.3 Cartridge Motivations The TLB (Transport Load Builder) module of SAP APO takes gross transportation orders created by deployment and turns them into orders suitable for transportation planning. It splits bigger orders into loadable quantities or gathers single-product orders into composite multi-item orders. Then TP/VS can bundle multiple orders in shipments and assign a shipping date and time. However, at the time the project was started (mid-2002 using SAP APO release 3.0, seeSect. 9.2.3.6) there was no load-building algorithm or heuristics in SAP APO enforcing the specific business requirements described below. Supply availability: loads can leave a plant or a DC if there is enough supply for all products in the load. The supply is either stock, production (packaging lines) or inbound shipments from plants (for DCs). Controlling floor in plants: In the plants, the pallets coming from the packaging lines are staged in an area called the “floor” before loading. The floor has a limited capacity and when it is saturated, production must be slowed down. Good synchronization between loading and production can lower the floor. Improving line loading: In the plants, the packaging lines deliver pallets directly to the warehouse in front of the docks. When a pallet is picked, it can be moved to the floor (floored) or directly to a vehicle if there is a load for this product scheduled at this time. This is called “line loading” and maximizing line loading is a valuable objective: it decreases the floor and increases the productivity because two pallet moves are saved (to and from the floor). Controlling load complexity: the complexity of a load is the number of different products. Complex loads are more difficult to handle, but more importantly they are more exposed to late supply. If any of the products in the

9.2 The ILOG Cartridges Concept

219

load is delayed (late production orders, late shipment arrival) the whole load will be delayed. Minimizing complexity is especially important for plants. Note that from the distributor viewpoint complex loads are better because they prefer to receive a product mix lowering stock-out risk. Vehicle utilization: At the time of the project TP/VS used simple dimensions for vehicle utilization such as weight and volume and did not consider the additional weight of dunnage. This did not capture the loading of pallets in enough detail as it should be checked independently for length and width; in height, pallets can be stacked and some products allow partial pallets by layers. Splitting sales orders: A limitation of TP/VS was that it could not assign a part of a sales order schedule line to a shipment. So if a distributor orders more than a truckload of a product (a common situation), TP/VS would not build a load unless the sales order item is previously split into schedule lines. This split cannot be made before optimization because splitting in truckload quantities is not enough. For example, suppose trucks have a capacity of 15 pallets and a customer orders 10 pallets of each product A, B, and C. The best solution is two loads, for example 10 A + 5 C and 10 B + 5 C. So the item for C should be split into two lines of 5 pallets each. Optimization after tendering: Once the initial loads have been tendered and accepted by a carrier the load builder may need to be run again. Then it must work in a more constrained way. It should try to reuse already tendered loads, changing the content of the load but not the dimensions of the vehicle and the shipping day. The time in the day can be changed because carriers will send the trailers to a yard at the beginning of the day and pick them with tractors. Figure 9.4 shows the warehouse with the main business terms. As with the previous project, many other requirements were not showstoppers, but were enforced for a better business solution after the choice for a custom optimizer had been made. We give two examples: Portal time computation: the portal time is the duration spent by the vehicle at the dock waiting to be loaded. Portal time is the time between the spot time when the vehicle arrives at the dock and the shipping time when it departs. A good evaluation of this time needs to capture the duration between lines and docks and floor and docks, the time to load a pallet and fixed times to set up the truck, close the doors, etc. Multiple handling resources: TP/VS used one handling resource for a location. Assigning multiple resources manages the availability of groups of docks separately, for example the rail docks and the truck docks and uses them with the appropriate shipments. 9.2.3.4 Solution Outline The planning activities occur during the week. First, orders from the Web are downloaded into SAP R/3 SD (Sales and Distribution) as sales orders. As SAP R/3 and SAP APO are always synchronized by the Core Interface

220

9 Case Studies - Interfacing Tailored Models to SAP APO

Lines Flooring

Cooler Line Load ing

Docks

= loadable units of product (pallets)

df Loa

rom

or flo

Vehicles

Fig. 9.4. The warehouse with packaging lines and loading docks

(CIF), the SNP optimizer is then run immediately in SAP APO followed by PP/DS which is used to build the production plan based on SNP planned transportation (indirect channels) and sales orders (direct channel). Now SNP Deployment builds the exact transportation based on PP/DS production, sales orders and inventories. This brings us to the middle of the week; the load builder is used first in the plants and then in the DCs. The loads built from the plant for the DCs are used as supplies by the load builder run in DCs. After a load builder cartridge run, the loads are first saved in SAP APO as split proposals and a custom development is used to create schedule lines in the SAP R/3 sales orders; then the loads are transformed to SAP APO shipments. The shipments are tendered using a transportation management system (Manugistics) interfaced with SAP APO (the SAP APO database can assign a carrier to a shipment but the SAP APO tendering module was not used). The PP/DS production plan and the load builder plan can be reworked during the week. At the end of the week the shipments for the next week are released, deliveries and shipments are created in SAP R/3, and these are communicated to the warehouse management system. Two cartridges were developed for this project, a GUI cartridge to display the data and pilot the optimizer and an optimizer cartridge to compute the loads. The Graphical User Interface Cartridge The GUI cartridge is started from the TP/VS interactive planning transaction, it leverages the data selection of orders for the planned plant or DC. The

9.2 The ILOG Cartridges Concept

221

GUI cartridge reads the data from SAP APO using BAPIs: sales orders and deployment orders, existing shipments (loads), supplies (inventories, production orders, inbound shipments), and the current load-supplies assignments. Using the GUI cartridge the planner can perform several tasks: • • • • • •

Display the demands (sales orders, deployments orders), the parts of a demand already assigned to loads, and the status of demands (fulfilled, late, unfulfilled), Display the supplies (inventory, production, inbounds) and the parts of a supply already assigned to loads, Display the loads, the demand parts composing the loads, the supply parts attached to the loads, and the status of the load (full vehicle, etc), Evaluate the load builder plan, displaying KPIs (number of loads, complexity, costs), a chart of inventory (floor), a chart of resource utilization (docks), and a chart of line loading, Prepare the optimization run by excluding some demands or supplies, firming selected loads, changing the objective function weights, and relaxing some constraints, and Run the optimizer and review the results and save the load proposals to SAP APO.

After loading, the GUI performs a supply check, during which it checks if the current supplies still fit the loads in time and quantity. The inventories, the production orders and the inbound shipments may have been changed since the last load builder run. Loads with an incorrect supply situation are highlighted and the planner can restart the optimizer. Also at any time during a session, the planner can force the cartridge to refresh the supplies from SAP APO and perform a supply check. The GUI cartridge was developed by ILOG using ILOG ODF and ILOG Views. Optimizer Cartridge The optimizer cartridge is started on request by the GUI cartridge. Upon start it receives data from the GUI cartridge: demands, supplies, firmed and tendered loads, and master data. It computes a new set of loads optimizing an objective function. The components of the objective function are complexity of the loads, portal time, line loading, vehicle utilization, late deliveries, unfulfilled demand, and floored quantity. The optimizer was developed by ILOG in C++ using ILOG ODF, ILOG CPLEX, an LP and MIP library used to build loads and assign demands and supplies, ILOG Scheduler, a constraint programming library specialized in scheduling, used to place the loads in time enforcing synchronization with supply handling resources and business hours. The size of the MILP problems solved varied from 58 rows and 37 columns to 3803 rows and 2678 columns. The constraints are typically balance equations and bounds, e.g., id33 : −2441D00 − 2301.8D01 + w0 = 0

222

9 Case Studies - Interfacing Tailored Models to SAP APO

is used to compute the weight, w0 , of a load based on the quantity of each of two demands, D00 and D01 , that are satisfied on this load. The inequality id8559 : u00 + u10 + u20 + u30 + u40 + u50 + u60 ≤ 77 ensures that no more than the available supply is used; the variables u denotes the supply used. Several decomposition techniques are used, decomposition by priority, for example. 9.2.3.5 Integration The integration of the load builder cartridge with SAP APO was more complex than the bulk distribution case described in Sect. 9.2.2 for two main reasons: 1. The SAP APO database (and the liveCache) could model the loads as shipments with the demands assignments but not the supplies assignment. Custom tables and ABAP code were required. 2. The connection of SAP APO with SAP R/3 added the need for the additional procedure to split the schedule lines in the sales orders based on proposals sent by the load builder. These two points required additional ABAP developments for the integration. Otherwise, as in all cartridges, the integration was based on standard BAPIs for transaction and master data: sales and deployment orders, shipments, stocks and production orders, products, locations, and resources. Standard SAP APO (release 3.0) resources were used to model the vehicles and group of docks. Specific custom tables were also developed with the ABAP workbench for master data not in SAP R/3 (e.g., duration between lines and docks, vehicle dimensions). 9.2.3.6 Project Information The project was developed by ILOG in close cooperation with SAP and the customer. The pace was mainly set by the large supply chain project, which was delayed to avoid going live during the summer peak season. Since the go-live, the customer reported the lowest historical level of the floor and the people in the warehouse reported a noticeable improvement in load execution. The main factor of this success was the involvement of key users during development. Sizing The Load Builder is used every week by planners for 3 plants and 11 distribution centers, at least twice in each location (before and after tendering). A typical cartridge run contains 200 destinations, 200 products, 500 demands,

9.2 The ILOG Cartridges Concept

223

and 500 supplies and produces 2000 loads for the week. Note that the demand table has the dimension product × destination) and is rather sparse. The computations are done in 5 to 15 minutes, actually the bottlenecks of the process are reading the supply data from the liveCache and splitting the orders in SAP R/3 after load building. Timeline The project was structured in three phases: • •

June to July 2002: assessment study (15 days) and detailed specifications. August 2002 to August 2003 : development of cartridges, development of ABAP processes by SAP (splitting, interface to the transportation management system), development of ABAP custom tables by the customer, and intermediate deliveries and testing. Because of the delayed supply chain project, the team was not 100% allocated to this project during this period. • September to November 2003: Go-Live and go-live support The go-live was part of the general SCM project go-live (including SAP R/3 and SAP APO). Staffing ILOG Professional Services involvement in the project was in the areas of optimization (one consultant full time for a total of 12 man-months), GUI (one consultant for a total of 3 months), and architecture and integration (one consultant part-time for a total of 10 months). Also, other parties contributed efforts specifically for the cartridge: customization of SAP APO and ABAP development for custom tables (6 months) and ABAP process for splitting orders in SAP R/3 (12 months). The estimated user involvement in specifications and validation was about 24 months. 9.2.4 The Cartridge Architecture To reduce risk and speed up project development ODF predefines the architecture and provides template cartridges. There are two basic cartridge architectures depending on the need for a specific graphical user interface. • The server architecture in which there is only one cartridge which embeds the optimizer. It runs on a separate computer under the control of SAP APO. • The client-server architecture in which there are two cartridges: – A GUI (client) cartridge running on the user workstation and started by the SAP GUI on request from an SAP APO transaction. – An optimizer (server) cartridge running on a separate computer andstarted and controlled by the GUI cartridge.

224

9 Case Studies - Interfacing Tailored Models to SAP APO

SAP GUI

Client

Front-end Workstation •Direct optimizer control •Result/Parameter exchange •Progress messages •Stopping

APO

Server

Optimization Server

SAP Gateway

APO Server •BAPI/RFC

Fig. 9.5. Cartridge external architecture

Note that the client-server architecture is actually an extension of the server architecture: the optimizer cartridge is similar. In the client-server architecture, it is also possible to start the server from an SAP APO transaction, typically for batch jobs. 9.2.4.1 External Architecture Figure 9.5 describes the external architecture of a client-server cartridge; a server cartridge is identical without the workstation part. Cartridges are separate processes running on Windows computers. This section describes the SAP APO Optimization Extension Workbench (APX) used to integrate the cartridges with SAP APO and the control flow of a cartridge session. The SAP APO Optimization Extension Workbench The APX is a standard SAP APO component facilitating the integration of external optimizers. APX supports the integration of a server (optimizer) and/or a client (GUI) as external processes. The integration relies on Remote Function Call (RFC) communication in both cases. RFC is a SAP protocol to call ABAP function modules remotely. The calling procedure can also involve non-SAP systems using the RFC SDK (a C library; there is a similar Java library JCo). Using the library an external process can be an RFC server (receive calls from SAP) or client (place calls to an SAP system).

9.2 The ILOG Cartridges Concept

225

To place RFC calls from ABAP to an external server it is first necessary to define RFC destinations (transaction SM59). The destinations using the TCP/IP protocol can be either: •

A Registered server : the external system is running and registered in a SAP gateway under a name. The SAP gateway is a broker program, there is always a SAP gateway on an SAP instance, and it can also be installed standalone on a computer. The used gateway and the name of the server are configured in the RFC destination. • An Invoked server : the external program is started by the RFC call, the path of the program to start is configured in the RFC destination. There are three kinds of invocation depending on the computer where the server is started. In Front-end workstation invocation, the server is started by the SAP GUI. In SAP server invocation the server is started on the host running the SAP instance. In Explicit host invocation the server is started on an explicit computer (IP name or address) through a gateway installed on this computer. An optimizer cartridge (server) uses explicit host invocation, this is also the technique used for the SAP APO standard optimizers and algorithms in SNP, PP/DS, and TP/VS. A GUI cartridge uses front-end workstation invocation. Note that it can be useful to define an alternate destination starting the optimizer on the front-end workstation; this allows testing the optimizer before deployment to the server computer. Once the cartridge process starts, it must use the RFC SDK to establish itself as a server and answer the RFC calls from SAP. The ODF template cartridge performs this task automatically. The RFC protocol described above is strictly sufficient to integrate an external program with ABAP development on the SAP side. It can be used in any SAP system (SAP R/3, SAP BW, etc). In SAP APO, the APX module elaborates to minimize the ABAP coding and allows integration in the standard modules (PP/DS and TP/VS). APX is based on a customizing activity (Maintain Optimization Extension Workbench) where the extensions can be named; the following information is attached to an extension: the RFC destination to start the client (if any) and the server, the SAP APO module to extend (none, PP/DS, TP/VS). When PP/DS or TP/VS are selected then the optimize buttons in the interactive planning session of PP/DS or TP/VS will give the choice of starting the external optimizer instead of the standard optimizer. It is also possible to maintain a restriction of users and custom configuration parameters that will be sent to the external optimizer. APX also provides some predefined reports and RFC modules: The /SAPAPO/APX OPTSTART report can be used to start an external optimizer outside the interactive planning transactions. This report offers selection of PP/DS and TP/VS data and is useful to define variants and schedule optimization jobs. The /SAPAPO/APX OPTSTART function module is used to start an external optimizer from an ABAP program. It is useful when a specific transaction is developed to start the cartridge.

226

9 Case Studies - Interfacing Tailored Models to SAP APO

The /SAPAPO/APX REQSRVSTART function module is an RFC-enabled function module used by the client cartridge to request SAP APO to start the server cartridge. APX also predefines the RFC function module used to start the external optimizer and pass some useful information with the activation call: the name of the extension, the SAP module, the mode (interactive, batch), the user name, the Logical System, and the custom parameters registered with the extension Control Flow A typical client-server cartridge session will follow these steps: 1. The user is logged in to the SAP APO system in a planning transaction; he or she starts the cartridge. 2. The SAP GUI launches the cartridge on the user workstation; the SAP session is blocked, but another session can be opened. 3. The cartridge GUI downloads data from SAP using BAPIs (see the next Sect. 9.2.4.2 on data integration). 4. The user examines the data in the GUI. 5. The user prepares an optimization run (firming, excluding data, setting parameters). 6. The user requests optimization. a) The GUI requests SAP APO to start the optimizer cartridge. b) The optimizer cartridge starts on the server computer. c) The optimizer cartridge registers itself in the gateway of the SAP APO server. d) The GUI opens an RFC connection to the optimizer through the gateway of the SAP APO server. e) The GUI sends the data to the optimizer and requests optimization. f) The GUI fetches the messages from the optimizer (progress, feedback, errors) and displays them to the user. g) When the optimization is completed, the GUI gets back the results and stops the optimizer. 7. The user checks the result and can go back to step 4. 8. The user requests to save in SAP APO. The GUI sends the result using BAPIs. 9. The user closes the cartridge and control returns to SAP APO. The ODF template cartridge and library support all these steps without additional developments. An important feature is also the creation of logs and snapshot files of the data. These snapshot files can be used to repeat the optimization offline with a standalone version of the cartridge. This is useful for debugging, tuning, and regression testing.

9.2 The ILOG Cartridges Concept

Scripts to Load/Save

APO Protocols (BAPI/RFC)

APO Data Model

Control

Control Flow User Interface

Engine

227

Data Access

APO

Connection to ILOG Product Suite

Fig. 9.6. Cartridge internal architecture

9.2.4.2 Data Integration Data exchange between the cartridges is mainly based on BAPIs. A BAPI (Business API) is a standard RFC to exchange data with an SAP system. SAP APO offers a complete set of BAPIs to access master and transaction data. The main reason is that SAP APO was designed to work with any execution system, not only SAP R/3, and the BAPIs have been provided for this integration. The BAPIs are documented in the BAPI browser (bapi transaction) and on the web in the SAP interface repository at http://ifr.sap.com/ (which is no longer updated as of August 2005). The most useful business objects for the optimizers are the master data location, transportation lane, product, resource, and PPM (production process model) and the transactional data stock, sales order, manufacturing order, purchase order, TPVS (Shipment), and planning book (SNP time series). Some data required by a cartridge project may not exist in standard SAP APO (as it is often the case with master data). In this case, some additional tables must be developed with additional RFC-enabled module functions to exchange them with the cartridge. ODF provides tools to extract the RFC definition and easily build the data model and the code to exchange the data with SAP APO. 9.2.4.3 Internal Architecture ODF also provides a predefined division of the cartridge into internal modules as shown in Fig. 9.6. The cartridge modules are: The control module which contains the scripts to control the execution of cartridge functions. These scripts are called commands. In a GUI cartridge, the commands are activated from

228

9 Case Studies - Interfacing Tailored Models to SAP APO

the graphical user interface, in a server cartridge they are activated remotely. For the standalone cartridge ODF automatically builds a graphical user interface to run the commands. The data access module contains the functions to exchange data in relational format with SAP APO (through RFC), with databases (for access to legacy data or other data sources), and with flat files (for snapshot files). The data in relational format are translated in memory to an object-oriented model. ODF provides code generation tools that automatically build the relational object data mapping. An object-oriented model is easier and faster to access for data processing. The object-oriented model inside the data access module is called the apo model because it is close to the data model of SAP APO. The engine module is used for either the optimizer or the GUI. It also contains an object-oriented data model called the application model. This architectural model implements the business concepts of the cartridge and is used by the GUI and optimization developers. One of the main tasks in integration is to implement the transformation between the two models, apo and application. This may range from simple computations as date conversions, unit transformations, filtering, or aggregation, to more elaborate preprocessing. A common example is to compute the projected inventories at the beginning of the planning horizon, starting from the current stock and adding or removing all goods movements. 9.2.5 About Cartridge Projects This section presents the ODF methodology that ILOG has built up from cartridge projects. We first present the typical team involved in a cartridge development along with the required skills. Then we describe the main phases of a project; ILOG bases the projects on the RUP (Rational Unified Process) methodology defining 4 phases inception ( the opportunity and feasibility of the project is assessed), elaboration ( detailed specification and an optional prototype are developed), construction ( the cartridges are developed and delivered), and transition ( the cartridge goes live). We will end by presenting the specific risks encountered in cartridge projects. 9.2.5.1 The Team A typical team involved in a cartridge project gathers the following skills. Optimization Consultant He or she is a specialist in operations research and the use of optimization libraries (ILOG tools). There are two main tasks, which can be separated in case more than one consultant is involved or the first task can be also covered by the project manager. This first task is to elaborate the functional specifications of the optimizer with the customer (planners). This requires good

9.2 The ILOG Cartridges Concept

229

analytical and communication skills, a good understanding of the business objectives presented by the planners and modeling skills to translate the business objectives into an optimization model. The ability to explain to the planner what can and can not be done with the optimization model is a key asset. The second task is to actually develop the optimizer. It requires good software engineering skills and knowledge of the optimization libraries. Graphics Consultant If there is a GUI cartridge a consultant will develop the graphical user interface, the main work being in charts (Gantt, etc.) and other specific graphics. There are similar roles as in optimization: elaborating specifications and developing. Specific graphical knowledge is usually less critical than optimization knowledge: the specification task can be covered by the project manager or the integration consultant, and the development can be performed by the integration consultant. Integration Consultant This consultant will be in charge of the architecture of the cartridge and the IT integration with SAP APO. He or she must have a good understanding of ODF and the SAP APO system from an IT perspective. A good understanding of the business problem, the SAP APO data model and modules, and the data required by the optimizer is essential. One task is to elaborate specifications for the data modeling in SAP APO and the method to access the data from the cartridge and for the transformation of the data to the application model used by the optimizer and the GUI. Another task is to construct the cartridges, develop the data access and control modules, integrate the engine developed by the other consultants, deliver the final cartridges, and integrate them with SAP APO. ABAP Development Depending on the project, some ABAP developments will be required to develop transactions to manage and run the cartridge and to add custom tables and function modules supporting the cartridge. These tasks are not performed and managed by ILOG consultants; the customer or a partner manages them. Project Management Usually the project management for the cartridge is strongly tied to a larger SAP project managed by the customer or an integrator.

230

9 Case Studies - Interfacing Tailored Models to SAP APO

Stakeholders Last but not least, the customer stakeholders are a key factor for the success of the project. Business users, usually planners, are involved to develop the specifications, validate the deliveries, and gain ownership of the cartridge. They will champion the use of the cartridge and act as “super users” after golive. IT specialists are involved in the design and validation of the integration and architecture of the cartridge. They will monitor the future administration of the cartridge and SAP APO. The part-time, but continual, involvement of a business user and an IT specialist in all phases of the project is a critical factor. 9.2.5.2 The Inception Phase The project will start with an inception (also called assessment) phase. The purpose of this phase is to assess the opportunity for a cartridge: the business case for the optimizer and the reasons to build an extension to SAP APO (see below for some typical reasons). This phase also assesses the feasibility of the cartridge: detect if there are showstoppers in the optimization and the integration. The outcome is a statement of work: high-level specifications of the project with an estimation of the timeline and workloads. The statement of work defines the different project phases, especially the successive iterations in the construction phase. For each phase, the functional content and the deliverables are listed. The statement of work lists the skills required for the project and the amount of days in each phase. The statement of work states the additional dependencies to support the cartridge project like ABAP developments, data developments, access to legacy data. This phase usually lasts 1 to 3 weeks and involves an optimization consultant and an integration consultant from the cartridge supplier side and a business user and an IT specialist from the customer side. The activities for gathering information during this phase may include meetings and interviews, plant visits, and prototyping an optimizer with ILOG products (such as OPL, an Optimization Programming Language for mathematical programming). Note that it is important to clearly describe the business objectives, the overall business process upstream and downstram of the optimization problem, and the business problem requiring optimization. The reason to develop an optimizer should be clearly stated in business terms. Return on investment may be the first indicator to come to mind, but this is actually not easy to assess because the business process will change and the real costs are not known. Productivity of planning is often not seen as the real driver for the tool. In some cases (as for the load builder) the planning process is too complex to be performed manually, more usually however it is performed by very skilled people who are difficult to train. Automatically building a “decent” plan that gives a fair result and enforces all constraints

9.2 The ILOG Cartridges Concept

231

is often a very acceptable result. In no case should the tool be presented as a replacement for planners – this is not only a psychological, but also a business mistake as planning is fundamentally a human decision. A key point is reached when planners see the tool as an enabler to plan better and liberate them from bookkeeping tasks. It should be understood that an optimizer only optimizes a weighted trade-off between competing business objectives. We were very happy in our projects when the planners developed their own recipes to use the tool. For example, a fundamental trade-off is between production costs (setups, resource utilization) and customer service (on-time delivery). The user can perform multiple runs of the optimizer, setting extreme weights to explore the sides of the trade-off. The user of the load builder for example first runs with priority on customer service, and then she firms the shipments for the priority customers and performs a second run with an emphasis on resource utilization. Exploring these trade-offs manually would have been impossible. Actually, in that case, the opportunity for an optimizer has already been considered when the SAP APO project was decided. The second step is to understand why an external optimizer is requested, i.e. what are specificities of the business requirements not covered with standard SAP APO. This evaluation is extremely important because there is cost in an external optimizer, which should be compared with the cost of using SAP APO with minor gaps and/or some ABAP or other developments. First, it should be understood that differences often come from the fact that SAP APO is generic software, not specific to an industry, and covers best the more generic functions where industries look most alike. Gaps are more often found in operational planning (detailed scheduling of production, vehicle routing) than in tactical planning (DP, SNP). Approximations in tactical planning can be acceptable, but in operational planning missing a constraint or approximating will lead to daily frustration because the plan is not executable. Even if there is a business requirement not explicitly covered with the SAP APO optimizer, SAP APO is an extraordinary integration platform for the external optimizer. It provides the modeling of data, and the integration with the execution system (SAP R/3) and with the upstream or downstream processes. SAP APO, as all SAP systems, is also very good for extensions using the ABAP workbench; this is widely used to support cartridges for integration. However, ABAP was not designed for advanced 2D graphics (charts) and complex optimization algorithms usually requiring object oriented programming in C++. The standard SAP APO optimizers, for example, use the same architecture as the cartridge: integration in ABAP and the algorithm in a separate C++ process. The cost of integrating a custom optimizer is drastically reduced with SAP APO. This is the reason to see cartridges as SAP APO extensions instead of standalone software. In both examples, we saw how the cartridges integrate nicely with the results of SAP APO upstream modules (SNP, PP/DS), leverage SAP APO for data storage and selection, and rely on SAP APO for exchanging the data with the execution system.

232

9 Case Studies - Interfacing Tailored Models to SAP APO

Typically, the reasons to develop a cartridge fall in the following categories: Missing constraints or objectives: we saw many examples. In most cases this boils down to missing master data or attributes in existing master data. In almost all projects, there will be a need to add master data. The good news is that it is easy to add tables with the ABAP workbench, or simply to add custom fields. Scope of data: very often, the optimizer will need to look at data not in the usual scope. Both cartridges we presented plan transportation but need production data. The standard TP/VS optimizer does not look at production data, it assumes product is available. Here we can also appreciate that SAP APO provides access to all planning information (forecast, stocks, production, and transportation) in one unified database through standard BAPIs. Otherwise, the integration would have been much more difficult involving many systems. A great achievement in all our cartridge projects was to use SAP APO as the only integration point. It is important in the inception phase to clearly detect clearly these data requirements. For this purpose, it is important to write down the data model required by the business problem and to map it to SAP APO. If the data are exactly the data used by a standard SAP APO optimizer, the opportunity for the cartridge should be re-examined. There is no real reason to build an external optimizer based on the same data as the standard one; SAP will continue to improve the standard optimizers. Two important decisions examined in the inception phase are the need for a GUI cartridge and the need to access legacy data. GUI Cartridge The main driver for a GUI cartridge is the need for advanced graphics, geographical maps, 2D layouts (symbols), charts (Gantt, histograms, bar charts, etc.), or specific representations (e.g., develop a cartridge for paper trimming where the cutting patterns are displayed). It should be decided if the GUI is only for displaying, evaluating the plan, and preparing the run (excluding, firming, relaxing) or if the user wants also to modify the plan manually. The costs are very different. The first reflex of the planners is to think they will need manual planning. Actually in many cartridges we proposed to delay this function to a later iteration and it was not developed because the optimizer gave a good solution and changing the result in SAP APO or SAP R/3 was sufficient. If the interface contains only tables, an ABAP development should be considered. Legacy Data Early access to real data is extremely important in an optimization project (see the risk Sect. 9.2.5.6 below). During inception it is important to decide if data will be available in the SAP APO project on time, if an interface with existing legacy data should be developed or if datasets should be built manually.

9.2 The ILOG Cartridges Concept

233

9.2.5.3 Elaboration The purpose of this phase is to develop the detailed specifications. Optimization specifications contain the business model, the objective function, the constraints and the high-level description of the optimization techniques (mathematical model, algorithms). They also state the expected performance. GUI specifications contain the description of screens that should be developed and the control flow. Many tools (like ILOG Views Studio) can be used to produce screens. IT specifications describe the integration of the cartridge in term of data mapping reviewing the optimization business model and explaining how it is mapped within SAP APO and which method will be used to access it. The data mapping lists additional data required in SAP APO (custom fields, custom tables). The cartridge architecture describes how the template cartridge architecture will be instantiated in the projects and how the cartridge will be integrated in SAP APO. If legacy data will be used, the specifications describe the format and access to these data. Note that the ODF template architecture provides a placeholder for a legacy data model. But of course additional development is required to map legacy data. Validation describes how the cartridge will be validated: optimization is usually validated with simple data sets showing specific features and global datasets showing real optimization problems; GUI and integration are validated by developing business scenarios and comparing the data in SAP APO and in the cartridge. This phase usually lasts 1 to 2 months and involves an optimization consultant, an integration consultant, a business user to validate the optimization and GUI specifications, and an IT specialist to validate the integration specifications 9.2.5.4 Construction During the construction phase, the cartridges are developed and the deliverables are no longer documents but software components. ILOG believes in iterative development with intermediate delivery of working cartridges. Iterations are defined during inception and elaboration. Iteration covers a well-defined subset of functionalities. A working version of the cartridges is delivered, usually before the end of the iteration to get user feedback. ODF allows the building of standalone versions of the cartridges using flat files. They can be used before completion of the integration and construction of the SAP APO systems. This is also very important for using well-defined datasets. It is actually difficult to always work directly with the SAP APO system for the following reasons: the system may not be ready or accessible, it may contain bad data (especially in development systems) and data created for other purposes than optimization, and finally the content of the system may change over time and it is not easy to keep a stable set of data. The standalone cartridge also contains an automatic data browser to explore the data. This is a very valuable development tool. The standalone cartridge is used for testing and validation

234

9 Case Studies - Interfacing Tailored Models to SAP APO

of the optimizer. ODF embeds the JavaScript language to generate datasets and write test scripts. Using data files and the standalone cartridge decouples the integration and optimization developments. The integration consultant can access the SAP APO system to download data and create files for the optimization consultants who works only with the standalone cartridge. This decoupling dramatically increases the productivity of the developers. 9.2.5.5 Transition The transition is the last phase. The project documentation is finalized and contains updated specifications, the IT installation manual and user guide, and user documentation for the GUI and the optimizer. This phase is synchronized with the last SAP project phases, integration tests, go-live, and post go-live support. In this phase, the key point is fast analysis of issues and quick support. Experience taught us that even with careful specifications, training, and planning, some issues can emerge: errors in data (especially in master data construction) and incorrect behavior of the cartridge (bugs, bad interpretation of the specification, missing specification). The most useful ODF tools in this phase are the logs generated by the cartridge and the automatically generated snapshot data files that can be used in the standalone cartridge with the data browser. 9.2.5.6 Risks We do not try to list all potential risks in a software projects but concentrate on the factors we perceived as specific issues in our projects. Business Scope Once a company has decided to develop a custom solution for planning it will of course wish to get value for the money and match its business needs exactly as opposed to an off-the-shelf solution where some trade-offs are accepted. This is actually difficult for the following reasons: Planners “know” their business very well and know what a “good” plan is. However, it is very difficult to write this down as specifications. Planners are not optimization specialists, and optimization consultants are not business specialists, they must reach a mutual understanding. Planners keep on asking for change and improvements as they begin to use the cartridge (this is often called “feature creep”). Planners would like a “magic wand” to incorporate requirements that are extremely expensive or impossible to put in the scope. A typical magic wand is online planning. When the plan has been released for execution it is usually not executed as planned for many reasons (machine breaks, supplies are delivered late, demand is changed, etc). Planning is the easy part of a planner’s life, reacting to problems and replanning may be the bulk of his day. From

9.2 The ILOG Cartridges Concept

235

their point of view, it is very attractive to be able to replan with the tool. Unfortunately, this is usually a very different and harder optimization problem in term of constraints. For example, many component supplies are derived from the original plan (by MRP for example) and in replanning supply availability becomes a very strong constraint. In our load building example tendering the shipments creates an additional constraint for subsequent runs, we did not even consider replanning during the execution week. The first approach to this problem is to try to improve the process to shorten the release horizon and increase the planning frequency if possible. If you plan for the next week and release one week for execution and something goes wrong on Monday the plan will be warped and manual adjustment will be necessary in the plant during the whole week. If you release two days you will manually adjust two days in advance and have the opportunity to run the planning again starting the horizon on the third day. The optimizer will consider the new situation at the beginning of the third day and build a new plan. It is extremely important in the project to manage the planners’ expectations, ignoring them will create frustration, incorporating too much will create delay and excessive costs. The preventive actions against this risk are simple. Good communication is required between the consultants and the planners when writing specifications and during the whole project. Buy-in of a planner in the project is very important. He or she must be an integral part of the project and one of its owners. Requirements should be sorted by priority (critical, useful, nice-to-have) and importance and assigned to successive iterations. Pushing a requirement to a later iteration is a nice way to have an opportunity to reexamine it when more understanding of the project is built. Iterations and intermediate deliveries are key to get early feedback. Put a change request mechanism in place at a well-chosen time during the construction phase. The main idea is to put some “sand” forcing users to question the value of the changes. Allow some budget for tuning and changes at the end of the project, or expect some overrun in costs. It makes more sense to develop a limited core set of features first and add to it later than to develop features that are never used. Some business features are never used because the cost of maintaining accurate data offsets the benefit. In the bulk routing cartridge we added a feature to incorporate weather conditions on driving time, but it is seldom used as the durations are not that precise anyway (due to traffic or other factors) and weather conditions must be maintained manually in the master data. Note that from the customer perspective it is less expensive to incorporate a useless requirement in the original specification than to pay a change request for a forgotten important requirement. This leads to an “if in doubt, let’s do it” mentality. A better approach is “if in doubt lets’leave it to a later iteration”. Data Availability Optimization is very sensitive to data. Integration is simpler to test (small and not too business-sensitive datasets can be used). Scaling is not very complex.

236

9 Case Studies - Interfacing Tailored Models to SAP APO

Again, optimization is another story and sensitive. The algorithm needs to be tuned on the real data and trying to cover all the possible configurations makes absolutely no sense if they do not correspond to a real business scenario. The purpose of an industrial optimization project is not academic, and usually the “general” problem is not tractable in a mathematical sense. However, the customer does not care as long as the optimizer gives good results with his data. The specifications may be imprecise and may not capture the business well. Real datasets will raise the correct questions. Lastly, planners, like most people, will give much better feedback on a real example, they will immediately see problems they did not even communicate during specifications because they were “obvious”. There are not many ways to address this risk. The project manager should insist on the need for real data during the inception; incorporate it in the planning and the dependencies. The project should consider access to legacy R R data in existing systems or define an easy data format (Microsoft
Excel
, Access database) to be used by the planner to create datasets manually. Note that ODF can very easily access Excel files or Access databases. When the datasets are created manually usually they will exercise a specific feature, this is of course very useful, but some datasets should be “real” too. This means he number of objects must be comparable with reality. A common mistake is to build datasets with no released plan, as if the plant was just freshly built and the first customer orders are received. In reality, the plan from yesterday will be currently under execution so the resource will be busy with firmed orders and inventories must be projected. A way to reach this state is to create a first solution, firm it and shift the demands to the next horizon. Scaling Scaling is a recurrent risk in a project as the performance of the optimizer and the integration may be impacted seriously when the size of the data increases. This risk should be addressed with common sense; during inception, gather information on the expected sizes of problems. Find formulae to extrapolate the performance measured on the first tests. Build large-scale datasets (could be by simple repetition). Get real data as early as possible! Project Dependencies Dependencies create the risk of delay in any project. When dependencies are late, the developers are not 100% efficient and the duration of the tasks will be longer than the planned effort. A typical issue is the availability of customer employees like planners and IT specialists. These people are usually extremely busy and not required 100% on the project, but they are needed punctually to answer a clarification question, review a document or give feedback on a delivery. Other potential issues are the availability of data (once again!) and the coordination of cartridge development and ABAP development in the SAP APO system.

9.3 Production and Sales Planning in the Chemical Industry

237

9.3 Production and Sales Planning in the Chemical Industry2 9.3.1 Situation The BASELL group of companies is the world’s largest supplier of polypropylene and a leading supplier of polyethylene. Both are plastic materials with a large variety of applications in many industries: car, film, furniture, building, and others. BASELL Europe has about 20 production plants in central and southern Europe producing about 1200 different finished products. Most products can technically be produced at more than one plant. Product produced at these plants serves the European market and, in some cases, markets worldwide. Fig. 9.7 shows the structure of BASELL’s supply chain, spanning procuring raw material, the chemical production processes, and outbound logistics and sales processes. Apart from the material flows, it lists the business constraints and gives an idea of the supply chain complexity in terms of number of locations, products, and deliveries. BASELL uses a centralized SAP R/3 system to represent its business worldwide (including BASELL Asia Pacific and BASELL USA). Demand planning is done in SAP APO based on historical data and then updated with current market information. Every month, a rolling forecast is generated that serves as basis for all further short-term planning activities. 9.3.2 Task and Objectives Based on the rolling forecast that is composed in SAP APO, a sales and supply plan should be generated that provides information on: • •

From which plants should products be delivered to customers? How much product should be produced on each production line at each plant in each month?

The sales and supply plan must observe all constraints that are defined on the supply chain: • • • • • 2

Production volumes must not exceed given capacities on production lines at plants. Current stock volumes have to be taken into account, as well as stock requirements at the end of each month. Bottlenecks in raw material supply might have to be taken into account. Production on production lines is restricted by minimum run lengths per product produced and fixed lot sizes. Spare time on production lines might have to be reserved for planned shutdowns or experimental products. Axel Hecker, Mathesis GmbH, Friedrichsplatz 11, D-68165 Mannheim, Germany, e-mail: [email protected], http://www.mathesis.de

238

9 Case Studies - Interfacing Tailored Models to SAP APO

BASELL Supply Chain Procurement

Purchase Prices Restrictions on Availability

Production & Supply ~ 20 Production Plants in Europe

~ 10 external Inventories in Europe

~ 1200 different products produced

~ 5000 Deliveries to Customers in Europe & Overseas each month

Production Line Capacities Minimal Runs, Fixed Lot Sizes Energy Costs

Production Powder (“Polymerization”) Monomer Purchase (Propylene, Ethylene)

Other Raw Material Purchase

Logistics & Sale

Production Finished Products (“Granulation”)

Inventory Requirements, Costs & Capacities Transport Costs Customer Demands & Prices

Packaging & Logistics (internal/external Inventory, Transport)

Sale to Customers in Europe & Overseas

Fig. 9.7. The supply chain structure in the BASELL case

9.3.3 Solution A system has been set up that uses mathematical optimization with MILP (mixed integer linear programming) technology to solve the tasks described above. Characteristics and functionality of the system are: • • • • •

Tight integration with SAP R/3 and SAP APO on input and on output Checkers on data completeness and consistency User interfaces for additional user input Mathematical model3 representing structures and constraints of the problem that can be fed with current data and executed with solver software Xpress-MP by Dash Optimization, the model is written in Xpress-Mosel) Throughout reporting

For the reasons discussed below, the Supply Network Planning (SNP) functionality built into SAP APO is not used. Besides interfacing, all functionality is implemented outside of SAP. This is why the solution provided can be conceived as a “plug-in” optimizer for SAP APO. The first implementation goes back to the year 1997; the system has been enlarged and reworked considerably in 1999/2000. From the month of introduction in 1997, the system has been live and running to date, with minor 3

The mathematical model has been developed and implemented by BASF’s mathematical support group Scientific Computing lead by Dr.Anna Schreieck, BASF Aktiengesellschaft, GVC/S-B9, D-67056 Ludwigshafen, Germany. e-Mail: [email protected]

9.3 Production and Sales Planning in the Chemical Industry

239

BASELL Planning Process “What Sales Department would like to sell”

“What is actually available for sale to whom”

Historical Data Sales Forecast (SAP APO)

Sales Plan (SAP APO)

Current Market Info

inside outside

Optimization by means of MILP technology

Result OK?

SAP

yes

Additional Input Set additional constraints in order to avoid problems identified

no

Fig. 9.8. A schematic view of the BASELL planning process

adjustments that are continuously made. Currently (2005), SAP/R3 is used in release 4.5B and SAP APO is used in release 3.0A. The following subsections describe the items listed above in detail. As a reference, Fig. 9.8 sketches the planning process inside and outside of SAP APO.4 9.3.3.1 Data Download from SAP R/3 and SAP APO Before an optimization run can be executed, the necessary input data is downloaded from SAP APO and SAP R/3: • • • •

Rolling sales forecast, composed in SAP APO from historical data and then updated with current market information Current information on production: costs, capacities, restrictions, available production lines, bill of materials, etc. Current stock quantities Transport costs

Due to tight time constraints, users of the systems always wanted to be able to determine themselves the exact point in time when these downloads should be executed; consequently, no fully automated procedure has been implemented for this purpose. 4

The authors would like to thank Marie-Louise Naccarato, PP Planning Europe & Tool Optimization (MILP/SAP Coordinator) and Nicco Casa, SAP CCC, Supply Chain Tools Team Lead, at Basell, for critical reading of this case study.

240

9 Case Studies - Interfacing Tailored Models to SAP APO

Depending on system load, the download routines take about 30 to 60 minutes to complete; currently the overall data volume is about 60 megabytes. 9.3.3.2 Checks on Completeness and Consistency Checks on completeness and consistency have always been regarded as an essential part of the system. In case of problems, data may be corrected or eliminated at once. The importance of this “cleansing” process can hardly be overestimated, because experience shows that data provided by many different people in many different parts of the company will never be exactly clean in the sense of some “dumb” optimization system that does not have a concept of reality. These are the most important checks that are made before each optimization run: • • • •

Are all products that appear in the demand available? Are transport routes defined for all market regions delivery has to go to? Does demand in sum match the available capacities? Are all raw materials available that are needed according to what appears in the BOMs (bills of material)?

Depending on the number and size of problems identified during checking, the execution of these routines might take very little (like 10 minutes) or a considerable amount of time (like several hours). It should be noted, however, that time invested at this point at the same time provides very good hints on how data quality might generally be improved. Several years ago, when SAP R/3 and the optimization system happened to be introduced roughly in the same period of time, the checklists generated by the procedures described above turned out to become one of the most useful sources for data quality control. 9.3.3.3 User Input Sometimes, last minute information has to be introduced at a point in time when the process cannot restart from the beginning. More important, not all data needed for optimization is available in the existing SAP environment. Consequently, a user interface has been created that allows modifying all current data at will and supplementing data that is not available elsewhere. Due to business process and system considerations, the implementation team at BASELL decided to administer the following data manually in the optimization application: • • •

Planned shutdown times on production lines and reservation of quantity for experimental products Certain costs that can only roughly be estimated, like stock holding costs (including capital costs) Complicated constraints

9.3 Production and Sales Planning in the Chemical Industry

241

The time needed for this data administration is typically low, because most of the time data from previous optimization runs can be used with modifications. The system provides the possibility to generate new versions of the current data that can then be modified where needed. 9.3.3.4 Optimization Optimization is set up to look for a solution that maximizes profit under observation of all restrictions defined. Optimization has proven to provide an excellent mechanism to decide on concurrency situations, because it is able to take all side effects into account simultaneously. When complications accumulate, they could hardly be pursued by human planners. Running optimization is an automated process the user has to follow: • • •

Transfer the current data into a format the underlying solver can read Call the solver and let it process until one or more feasible solutions are found Reload the result back into the user’s environment for reporting

From the steps listed, the first and the last one are very limited in terms of time needed (about 1 or 2 minutes), while the middle step might exhibit quite different computing times, depending on the level of complication present in the current problem. Typical computing times for the middle step are 10 to 20 minutes; as soon as a feasible integer solution is found, it is up to the user to decide if he or she wants to stop the process or look for another, better solution. Users have been told to watch the gap between the linear solution (relaxation) that does not take integer constraints into account and the best integer solution achieved. Under ordinary conditions, this gap should not exceed a few percent. 9.3.3.5 Iterations and Adjustments If, during the current planning session, some input data is optimized for the first time then the created results will typically not be 100% feasible with reality as a result of facts unknown to the optimizer. For example, the optimizer might decide on a certain product mix on a certain production line in a certain month that, out of reasons too complicated for implementation in the model itself, is difficult to achieve in reality. Consequently, experienced users look through the results, and in case such an infeasibility occurs, correct them by setting additional constraints. In a “trial and error” manner, additional optimization runs are executed and checked again until a result is achieved that everybody involved is happy with. This procedure might be conceived as being “primitive”, but technical and scientific people often underestimate the human aspects of complex

242

9 Case Studies - Interfacing Tailored Models to SAP APO

planning activities. In an abstract world, optimization provides “the optimum solution”. But in reality, this is not true because reality is always much more complex than its representation in the model. Users compensate this bias by using optimization as a tool that generates proposals they can approve or reject. And this is exactly what the seemingly primitive procedure described above provides. Finally, results go through a checking process that takes the sequencing aspects of production into account. While the optimizer only focuses on quantities per month, according to predefined sequencing aspects, a product might be produced “early” or “late” in some month, which is not visible to the optimizer (at least for now; further refinements of the optimization process, especially refinements that take into account product sequencing, are projected). Consequently, users have to shift some production quantities between plants or production lines manually in order to provide for feasible sequencing. This correction process is supported by powerful and user friendly mechanisms. 9.3.3.6 Reporting Reporting is provided on many different aspects of the result, on different aggregation levels, for example: • • •

Sales plan per product, sourcing plant, market region, and month Production plan per product, sourcing plant, production line, and month Capacity report per production line, sourcing plant, and month; this report specifically checks for spare capacity

Such reporting is mostly implemented in MS Excel and, combined with the built-in pivot functionality, allows fast access to all aspects of the result for people directly involved in the process. Finally, the sales plan is uploaded back to SAP APO and represents the current planning state – until it is replaced by the outcome of the next planning round one month later. 9.3.4 Discussion Some questions might come to mind, concerning the procedures described above: 1. These procedures combine the application of computing power with steps executed by human beings in a more manual way – with well-known negative side effects: sometimes arbitrary decisions, “trial and error” methods, sometimes complicated communication, etc. Wouldn’t it be possible to proceed in a more elegant, more rational, more automated and integrated way? 2. Why not use the Supply Network Planning (SNP) functionality built into SAP APO instead of an external system plugged into SAP APO?

9.3 Production and Sales Planning in the Chemical Industry

243

9.3.4.1 The “Human Factor” Some people think that “more mechanical”, “more automated”, “less involvement of human beings” is always better. Experience shows that this might be true sometimes, but not in complex planning situations like the one described. One reason is that automated processes can hardly be communicated as such. An automated process is typically conceived as a black-box that cannot be understood (and thus communicated) but only trusted in. And optimizers should never be used without a certain portion of mistrust. Why mistrust an optimizer, although it should deliver “the optimum” – and what could be better than that? Because in real life, there is no such thing as the optimum (or in very rare cases only). Optimizers deal with a model of reality, not with reality itself. Although the model might be a very good representation of reality insofar as it takes into account everything (or most of the things) that can be expressed in numbers, in many cases, these numbers only represent abbreviations that stand for something that is more complex – maybe too complex to be expressed solely in numbers at all. At this point, specific strengths of human beings come into place. Human beings might be weak when they have to deal with numbers only, at least with more than a handful of numbers at the same time – this is what they use computers and optimizers for. But they can be very strong in dealing with complex situations. There is nothing that can replace human intuition and its critical ability to discriminate the relevant from the irrelevant, reality from conception, and right from wrong. The procedures described above are all designed such that, ideally, everybody concerned with the planning process has the chance to say “yes” or “no” to the decisions taken during planning. Certainly, this ideal is far from being achieved regularly; under the pressures of everyday life, people tend to simplify the process and act as if optimization would deliver solutions that do not have to be critically reflected any more. Nevertheless it should be noted that mistakes made during planning are more often due to too much automation than too little. The ideal is not a fully automated, but a fully communicated planning procedure. 9.3.4.2 “Plug-in” Solution Versus SNP General Considerations The purpose of an ERP system like SAP R/3 is to reflect the current state of a given enterprise with all objects and numbers that are potentially relevant – on the level of precision needed. Advanced planning systems like SAP APO provide additional functionality to determine specific business targets that drive current actions and decisions. Mathematical optimization provides powerful mechanisms to support this process. Much of the power of SAP R/3 is based on the assumption (proved to be successful) that most companies, whatever be the nature of their business,

244

9 Case Studies - Interfacing Tailored Models to SAP APO

can be represented in structures that are identical or very similar. SAP APO was supposed to repeat this success in the planning dimension. However, this can only be achieved to a certain extent. While ERP systems represent “facts” in terms of bookings, the planning dimension deals with objects and numbers that are not yet facts; consequently, driving factors for future developments have to be taken into account. And these driving factors may be very different, depending on the nature of the specific business in question. For example, factors that drive the production and logistics processes in a chemical company are very different from those that drive similar processes in the automobile industry, and so forth in most other businesses. Models set up for mathematical optimization try to take into account such driving factors in order to be able to predict the outcome of future developments more precisely. For example, future business actions must always observe constraints on capacities because such limitations cannot be changed overnight. Typically, some of these driving factors are critical for the supply chain as a whole. Due to their tight connection with the specific business, such driving factors are very hard to impossible to model in standardized systems like SAP APO. Consequently, although such systems seem to be a logical extension to ERP, the scope of possible actions, relations and constraints they support tends to be limited due to the simple fact that, in the planning dimension, the particular drives the general and not vice versa as in booking systems, where the general layer provides the adequate summary of all details. This is where “plug-in” optimizers come into place. They try as precisely as possible to take into account the specific factors that drive a certain business. For example, the next development step of the optimizer described above will try to take into account rules and constraints on smooth production sequencing – a feature that is regarded as essential in BASELL and similar process industries. It is difficult to do this in a standardized system like SAP APO. Functionality Some of the functionality needed is not supported by SNP (or was not supported at the time of introduction): •

•

Profit maximization: SNP supports cost minimization. In case the optimization objective profit maximization is set in the optimization profile, it is possible to express differentiations in sales prices in terms of penalties that can be defined in SNP in case some sale cannot be done, because such penalties also provide a measure on profitability of each sale (cf. Sect. 4.2.1). At the time of implementation this was seen as difficult to conceive in day-to-day business and not covering the whole phenomenon, because it would mix two aspects that should be kept separated: profitability and the business decision on making a sale or not. Definition of stock in sales days: The model implemented supports the definition of stock in terms of sales days, meaning: product sold in a certain

9.3 Production and Sales Planning in the Chemical Industry

245

month must, to a certain extent, already be available on stock at the end of the previous month, in order to cope with situations of “late” production in that very month. Due to the high relevance of production sequencing at BASELL, this is an essential feature of the model implemented. Similar features available in SNP at the time of implementation did not meet BASELL’s requirements. • Some high quality products can only be produced when certain other products are produced, as well. The model implemented allows to define such constraints in terms of precise volume relations that have to be observed. No such feature was visible in SNP at the time of implementation, today it might make sense to revisit that requirement and evaluate it against the co-production functionality in SNP. Besides the first point mentioned (profit maximization), these items may be regarded as details that do not exist outside BASELL. There is a general point to make here, though: experience shows that most real life situations have at least one or two specifics whose observation is critical for the whole process, and thus, hard to deal with in a standard system like SNP. 9.3.5 Future Enhancements At BASELL, a second optimization initiative is under work. Its target is to provide a tool that can create a detailed production schedule for 30 days on some production lines; it not only takes into account demand on a day-to-day basis, but rules and constraints on optimal production sequencing as well. 9.3.5.1 Situation Every month, the procedures described above generate a supply plan that determines how much of each product should be produced on each production line at each plant in each month. Although this procedure makes sure that the supply plan corresponds to the current demand situation, currently there is no way to guarantee in an automated way that the series of products to be produced on a certain production line is technically feasible and what the optimal sequence of products would be. Instead, technical feasibility and the determination of the actual sequence production should pursue are controlled manually by production planners who are involved in the planning process. Furthermore, during the time between the monthly planning sessions, events might occur that have strong impact on the current production schedule. Such events may be a changed demand situation that is no more compatible with the current state of planning or breakdowns of production lines due to technical problems.

246

9 Case Studies - Interfacing Tailored Models to SAP APO

9.3.5.2 Task and Objectives Provide a tool that can automatically create a proposal on product sequencing, taking into account: • • • •

The current supply plan to be fulfilled Rules and restrictions to be observed by the sequence of products to be produced More detailed information on the demand of products at a certain calendar date Current inventory levels and restrictions

In order to be able to address all kinds of events that might have impact on the current production schedule, this tool should not only run once per month, but potentially once or several times per day. Response times of the tool should be short, because under the pressures of everyday life and, especially, events like the ones mentioned, answers are useless when they are not available at once. 9.3.5.3 Solution The solution currently (2005) under construction follows a development path different from the system described above. Its characteristics are: •

Provide a general framework for real life problems to be optimized. This R5 general framework is called TriMatrix
; based on a generic data concept and equipped as a full-blown stand-alone optimization system, its developers claim that any real life problem which may be optimized by using MILP technology can be represented and solved by using this framework – be it supply chain problems, sequencing problems, timetable problems or whatever else one might think of. Even the famous “Rubic’s Cube” could be represented and solved by using the patterns provided, without any change that would have to be made to the underlying framework itself. • In order to provide the necessary calculation speed, a preprocessing is implemented that focuses the optimizer such that only relevant alternatives are evaluated against each other. Normally, optimizers tend to search through the space of possible solutions without much guidance, possibly wasting time with testing solutions that would not be feasible anyway. In order to avoid this, before optimization starts, the timetable of daily demands is checked against alternatives that conform to the rules and restrictions of proper product sequencing; only those alternatives are made visible to the optimizer that pass the feasibility test. Consequently, the optimizer only has to look through a relatively limited number of possible solutions, and therefore processes very fast. 5

TriMatrix has been developed by the company MATHESIS GmbH. See www.mathesis.de or write to [email protected] for further information.

9.3 Production and Sales Planning in the Chemical Industry

247

The following subsections describe details of both characteristics. TriMatrix: General Optimization Framework for Individual Solutions Standardization typically follows an abstraction path like this: A car producing and selling company can represent cars as “products” and the parts cars are made of as a “BOM” (bill of materials); in order to produce cars, workers and machinery are needed, which can be represented as “resources”, and so on. This kind of abstraction makes sure that companies producing and selling different things can mostly be represented by the same general patterns. Although this kind of abstraction is the basis for any kind of standardization, it has its limitations: abstraction is always made from the real aspects of objects in question only, not from their functional aspects. A product remains a product, that is: something a company sells in order to make money, and so on. As a consequence, optimization systems that follow these patterns can only represent what their designers expected to be part of the underlying functional schema. Take SNP in SAP APO, for instance. This system very well describes the supply chain down to a tremendous level of detail; logistics, for example, provide machinery to put product in and out of inventory, in and out of transport vehicles, etc. All such details can be represented in optimization with specific costs, capacities and other constraints. But the underlying functional schema remains unchangeable. This is where TriMatrix takes off. There is no underlying functional schema presupposed. The only presupposition is this: Any action to be executed can be described as “generate and/or consume resources of any kind at a certain location in a certain period of time”. For example, production may be described as: consume raw materials and capacity and generate finished product(s); a transport could be described as: consume product at location A, generate the same product at location B, and consume money (transport cost); a sale could be described as: consume finished product and generate money (income); and so on. There is no intrinsic restriction to what may appear in the list describing the possible actions to be executed. In case additional items are needed (for example, if a sale also has to take duties into account) they are just added to the list. Resources may be: product, raw material, money, time, capacity, or whatever else can be expressed in terms of quantities. Locations may be geographical points or any kind of abstract spots where resources can be balanced; for example, a bank account might also be treated like a location in that sense. Time periods represent the flow of time with its characteristic unidirectional sense (time cannot go backwards), discriminated into slices of any length (hours, days, weeks, months, years, seconds, milliseconds or whatever); the length of time periods may even be variable, set by the optimizer itself. In cause of this generality, TriMatrix is able to represent and solve almost any real world problem without compromise. Certainly, TriMatrix somehow

248

9 Case Studies - Interfacing Tailored Models to SAP APO

must know the structures that describe some real world problem. These structures are not defined in the model, but by data definitions only. Consequently, the underlying system is always identical, whatever be the real world problem to be represented and solved. No involvement of developers is needed. That is why the people who created TriMatrix claim it is a “general optimization framework for individual solutions”. Achieve Calculation Speed by Specific Data Preprocessing The real-world problem to be solved at BASELL has the following characteristics: • •

•

•

•

•

Different products may have to be produced on a certain production line and are subject to the procedure. 30 days, starting today, are represented as individual time periods. These time periods describe what optimization focuses on: the search for a feasible production schedule that fulfills all demands and restrictions defined for the next 30 days. Furthermore, two additional time periods represent the following two months, where “month” is not a calendar month, but a time period comprising 30 days each. These two additional months are looked at by the optimizer in order to prepare for future demand that might have impact on the first 30 days as well. Demand for products is defined at the same level of precision: the first 30 days have daily demands, composed from actual customer orders and remaining forecast broken down to individual days, while demand for the two additional months are aggregated accordingly. Production is represented with starting conditions and rules a good production sequence has to pursue: some changeovers from one product to another are not feasible at all, while others are evaluated against each other by the amount of damage created. Stock is represented with starting conditions, as well, and minimum requirements to be observed on each day.

The optimization problem can thus be described like this: Look for a production schedule that serves the demand on time, takes into account stock conditions and requirements, and provides optimal production sequencing. The size of the problem to be solved can be expressed by the number of variables needed. For sequencing problems, the number of different orders that a given number of products can be arranged in is calculated by the faculty function (expressed by “!”). The number of possible orders for 10 different products, for example, is 10! = 3,628,800; 20 different products already constitute 20! = some trillions of different orders – and so on. Although more variables are needed in order to represent stock, packaging, and sale, this calculation already shows the immense size achieved. In terms of computing time

9.3 Production and Sales Planning in the Chemical Industry

249

needed to solve a problem of this size, there would normally be no chance to do this in a couple of minutes, as users would expect. This is where data preprocessing comes into place. It reduces the number of variables by identifying the relevant alternatives optimization may choose from, and thus achieves computing times that are in sync with user expectations. How is this done? These are the general strategies: • • • •

Arrange products to be produced in their order of urgency. This can be done for each product by fulfilling its demand from stock until the day it is exhausted; the earlier a product is exhausted, the more urgent it is. If no rules and restrictions on product sequencing were defined, the order achieved would represent the natural order in which products should be produced. Now sequencing comes into place: If two products follow each other in a way that would somehow violate proper sequencing, all other products that would recreate a proper sequence will be placed between them. After this procedure, a product sequence is achieved that still allows to produce in the order that is constrained by the demand, but provides additional intermediate campaigns that allow for proper sequencing. By using these intermediate campaigns, products that would originally come later in the sequence might be advanced in time. Thus, several alternative production paths are created that may be pursued. The optimizer rearranges the product sequence by using these intermediate campaigns as slots in order to fulfill sequencing rules and minimize the damage created by product changeover.

The size of this problem is only a small fraction of the size of the original problem outlined above, and thus can be computed in a fraction of the time. TriMatrix provides a data processing engine where such preprocessing can be implemented. Certainly, this preprocessing cannot be done in an abstract way, but has to follow the specific constraints imposed by the current problem to be solved. For this purpose, the general optimization framework provided by TriMatrix is supplemented with individual algorithms that do the preprocessing described above. By this, the creators of TriMatrix claim that it can overcome the limitations of standardization: provide a kernel that does all the general optimization work and that can be fed with almost any type of optimization problem that comes up in real world situations; and, at the same time, provide additional data processing capabilities that help to support solutions that can be streamlined to specifics and peculiarities that real world imposes.

Part III

Concluding Considerations - The Future

10 Summary, Visions and Perspective

In this chapter we summarize what can be learned from this book. We provide a summary of experience in optimization projects. We consider the consequences of how the SAP APO optimizer can change habits in companies and we give some views on how real world optimization might develop in the future. We also express which features might further increase – from the mathematician’s point of view – the strength of SAP APO in optimization.

10.1 What Can Be Learned from this Book? We have illustrated how SAP APO can be used to solve real-world optimization problems in various industries – this is “real optimization with SAP APO”. Challenging problems are solved by exact optimization techniques implemented in SAP APO. The case studies presented should motivate readers to think more about the opportunities mathematical optimization in SAP APO offers. The reader and project teams implementing SAP APO are encouraged to do “real optimization with SAP APO”. Currently, many implementations of advanced planning and scheduling systems do not yet fully utilize the mathematical optimization potential. There might be several reasons for this: •

• •

The clients are still busy with the first implementation steps of SAP SCM targeting at goals like supply chain data visibility and forecasting and thus the focus is not yet on planning and scheduling using mathematical optimization. The scope of most SAP APO implementations is still DP being the least complicated component, both technically and organizationally (see Dickersbach, 2004, [17]). The clients may have a professional background which is not close to modeling and optimization. Thus, they do not consider this in the first place and hesitate to use optimization at all. Clients in companies which have a strong history in mathematical optimization (refineries, metal industry, chemical industry, etc.) do not easily

254

10 Summary, Visions and Perspective

trust a black box optimization model. They expect a high approximation quality to their “real world”. • SAP as a company does not primarily position SAP APO as a tool for mathematical optimization and does not provide extensive in-depth training regarding modeling and optimization. Conceptually, optimization in SAP APO has been designed in such a way that the users1 build the model via the master data and can choose from preset solution techniques, but do not see the mathematical model equations. For many users this is what they probably prefer. Some real world planning problems, however, require a more in-depth treatment of the mathematics and/or modeling tricks with the available objects in SAP APO. SAP’s inhouse consultants will help to explain the underlying mathematical assumptions, but consultants with deep optimization and business software knowledge are often scarce. This is especially important to users who will not just accept a black box solution but really would like to understand what the underlying model looks like and what they are computing. In most cases it is not easy to replace an existing optimization application based on a tailored mathematical model by an APS based on predefined models. Of course this depends on the complexity of the planning problem, the planning philosophies, and the solution techniques. For the case study in Chap. 8, for example, it turned out that the planning philosophy of the custom solution (integrated planning) and SAP APO (hierarchical planning) are different and replacing the existing solution would result in splitting the planning features and functionality in a medium-term and a short-term planning component.2 Thus the change would result in considerable effort, probably comparable to a new implementation. SAP APO was developed claiming to be a standard to serve various industries in planning and scheduling. If it matches the needs, then this is the best that can happen. SAP APO meets the requirements of the industries on the whole (keeping in mind that MILP optimization is just one aspect of SAP APO). It would be interesting to know how many successful SNP optimizer live implementations are used but without access to the SAP customer directory it is impossible to quantify the ratio of companies using the SAP APO optimizer over those using optimization add-ons to it or tailored models. If after a careful analysis of the planning requirements it turns out that added functionality is needed there are two principal ways on how to proceed. The first way follows what we describe in the case studies in Chapters 7 and 9 and results in creating a mathematical optimization model that is interfaced 1

2

Of course, “user” is not to be understood as the end user of the planning application, but in the sense of the person who uses the software to implement the optimization model. It depends on the size and the structure of the decision problems whether it is possible to treat aggregated and detailed planning in one model rather than in a separate, hierarchical way.

10.2 A Summary of Experience in Optimization Projects

255

to SAP APO taking advantage of its business content, established processes, and functionality (including the SAP APO optimizer in two cases in Chap. 9). SAP and partner companies such as ILOG Inc. provide interfacing technologies to connect own models and solution approaches to SAP APO. The second possibility is to discuss and conduct a development project with SAP optimization development resulting in a solution all within SAP APO. In that case it is a good idea to bring the mathematicians inside the SAP company and those of the client together.

10.2 A Summary of Experience in Optimization Projects In this section we discuss when optimization is useful at all, and the implications of having bounds or not having bounds. We focus on data, the consequences of data inaccuracy and implementation issues, and illuminate the role rules play in planning and scheduling and their importance for model building. This section is based on the experience the authors obtained in a total of over 20 person years in optimization and SAP APO SNP-related projects. 10.2.1 When Is Optimization Useful at All? This book is on optimization – and in most cases we discussed mathematical optimization used in various supply chain problems. We have not yet focused much on when mathematical optimization is most useful. Thus let us do this now by assuming a company wants to use it for production planning. A first aspect to consider is the number of products involved. If the company produces only one product 24 hours per day and 365 days per year there is not much to plan. It is safe to advise the company that mathematical optimization will not help much. The key element missing in this case is complexity. Mathematical optimization is extremely useful if the underlying decision problem can be quantified and involves many degrees of freedom and constraints leading to a complexity which is not easy for human beings to grasp. Ideally, the kind of optimization we have in mind is best for reasonably complex production networks with utilization rates close to 100%. The argument here is similar to the first one used above. If the production network is only utilized, say up to 40%, then the decision of where to produce how much of a certain product is not too difficult. Mathematical optimization can do it but probably the human planner can do it as well. If the amount of products is significantly above the capacity of the production network the problem is more one of feasibility than of optimality. The decision which customers can be served and which not can be triggered by priority lists, customer classifications, etc., but usually these aspects are difficult to specify in advance. Nevertheless, optimization can help even in this feasibility problem case provided the problem owner is willing to make all aspects transparent in advance.

256

10 Summary, Visions and Perspective

Next we discuss scheduling. The border between scheduling and planning is often somewhat artificial. While scheduling includes many more details related to the production process it usually covers only a significantly smaller time horizon, say a few days or weeks. As it is the case in planning: at a low utilization rate the problem is relatively simple and mathematical optimization is easy. Optimization works best with respect to capacity gains when the utilization is close to 100%. Another benefit is to react faster and better on spontaneous customer requests. Although continuous-time MILP formulations are a good choice for the chemical process industry including batch and continuous production, most MILP or MILP&CP hybrid approaches experience difficulties if the utilization exceeds 100% significantly. The reason is that the optimization problem becomes more and more a feasibility problem. The user has to provide reasonable data specifying which kind of weakly infeasible solutions are tolerable, e.g., accepting late delivery, not serving some customers at all, violating the companies safety stock policies, stopping some reactors for a while, or driving the plant units slightly above their technical limits. Mapping a scheduling problem to a mathematical model creates again transparency. Human planners usually follow a set of rules which they are used to; see also Sect. 10.2.3. During the modeling process the reasons for such rules are made transparent. That touches a very relevant aspect of mathematical optimization. The declarative approach of optimization requires that all restrictions have to be specified in advance – they are transparent. Of course, iterative modifications are possible if a model differs too much from reality. As a consequence of this transparency mathematical optimization can help in the power battle one often experiences between sales departments, marketing units, and production departments. It can help to put arguments on rational grounds – and it can lead to a shift of power. In this book we often stressed the difference between the mathematical and the business language usage of the term optimization. Somewhat connected to this difference is the preference for exact optimization algorithms defined in Sect. 2.2 versus improvement methods. Here we want to give some orientation on the consequences and requirements of both approaches. A valid question is under which circumstances is it reasonable and worthwhile to strive for the exact optimum. The answer is clearly: it depends! It depends on the • purpose and on the approximation level of the model • accuracy of the data • permissible CPU time to solve the problem • the benefits achieved by applying exact optimization versus improvement methods which might fail to find a feasible point or the global optimum • the cost to develop or buy an exact optimization approach versus the cost of less advanced methods. Thus, the first advise to the reader and people initiating a project is to make sure that you have the technical competence on board to answer these ques-

10.2 A Summary of Experience in Optimization Projects

257

tions properly. Next we comment on the approximation level of the model. There is no such thing like an exact model. Each model is an abstraction and/or a simplification of the real world. Although the client might ask some mathematicians for support, the only person who can decide on whether a model is sufficiently accurate is the client who defines the purpose of the model. It is of paramount importance that the client clearly defines this purpose and expresses what he or she wants to do with it. Never start a project without being clear about the purpose, or start the project by working out the purpose if that is what the client pays you for. To give an example, we consider the process and design of building an elevator. The purpose is: transporting people or goods safely. An engineer or mathematician will probably ask: how many people, alive people or dead people, how much weight, which transportation speed and acceleration? He might also ask where the elevator is to be used: on Earth, the Moon, or on planet Mars – in 20 years this will be relevant. Restricting speed and acceleration to moderate Earth type values, it is possible to prove that applying only Newton’s law of physics is sufficient. We do not need to consider general relativity. When trying the optimization models we need to apply a similar level of care. Considering certain features or neglecting them may systematically change the results or the usefulness of results. Let us consider a planning problem targeting for good schedules which can be used in real life. Modeling batch reactors without considering filling stations may produce results not usable if the filling stations turn out to be a bottle neck. If there are plenty of filling stations available it is safe to neglect them. Thus we learn that the features to be included in a model do not depend on the purpose but also on the values of the data. Even worse, if they depend on the values of the data they also depend on the accuracy of these values. Therefore the warning above to clients to make sure that the decision process is accompanied by sufficiently competent personnel. Sales people when trying to sell software should always be accompanied by technical people because otherwise there is a great chance that relevant points are missed leading to IT projects which in the end take much longer than expected, leading to time stress, or costing much more than expected. In Sect. 10.2.2 we elaborate more on how to establish the accuracy and the consequences of inaccurate data. To discuss the value of optimization versus improvement methods let us assume that the model is approximating the real world sufficiently accurate not leading to any systematic problems and that the data are exact (we relax this assumption later on). To illustrate the problem when using improvement methods instead of exact optimization algorithms let us work out the consequences of not having or having tight and save bounds by considering the following example. Assume that a large industrial user wants to compare the economic impact measured as the net present value (NPV) of two different investment decisions. Each decision would involve a combination of building new production facilities and discontinuing the use of old, less competitive assets. The investment decision to be taken is significant as it involves the potential of

258

10 Summary, Visions and Perspective

spending several million US$ and impacts many people at the manufacturing locations. After modeling and solving the problem using an exact optimization algorithm, the results presented for each alternative are: units of million US$ alternatives A B scenario 110 120 NPV integrality gap, max. deviation from optimal solution 2.1% 1.8% 112.31 122.16 Maximum possible NPV If we want to maximize the net present value of the two alternatives then clearly, scenario B is better and preferable. Note that scenario A is bounded by 112.31, while in B we have already a feasible point with objective function value 120. A nonbound generating method might produce the following results: units of million US$ alternatives A B scenario 112 110 NPV integrality gap, max. deviation from optimal solution n/a n/a ? ? Maximum possible NPV Since such methods do not provide the maximum possible deviation from the true optimal solution, a user might conclude that alternative A is more profitable. Note that in Scenario A we found even a better feasible point than the exact method. This demonstrates even more that computing feasible points is only half the story. The other half are bounds or the proof of optimality. How can we explain this result? The improvement method returned a value that is 99.7% optimal for alternative A and a value that is 90% optimal for alternative B. This can happen in real life; there is no control or guarantee for the solution quality of improvement methods. In this example case we could only quantify the deviation from the optimal solution because we computed the comparison basis with an exact optimization algorithm. Therefore, we believe it is in the clients’ best interest to either prove optimality or at least provide reasonable tight bounds on the value of the objective function. In addition, the use of exact optimization methods can be coupled with sensitivity analyses, analyses of robustness, and stochastic optimization described in Sect 2.4.3. If the data we used in the example scenarios A and B are so uncertain that the objective function may vary by more than 5% or 6%, we cannot really distinguish between scenario A and B. This is a fair statement saving us the trouble to have lengthy meetings and discussions. If the input data are more accurate the scenarios can be distinguished giving a quantitative basis for further discussion. But note that the dependence of the uncertainty of the objective function on the uncertainty of the data can quantitatively only be established by mathematical techniques and a model.

10.2 A Summary of Experience in Optimization Projects

259

Thus we conclude that improvement methods can lead to believing to have the best solution possible when in fact there is no way to prove this claim. One might be attempted to conclude that safe bounds or exact optimization is relevant only for strategic decision problems. However, as we argue in Sect. 10.3.1 it is not always wise to distinguish between strategic and operative (tactical) planning. Each operative planning problem can easily be modified to be of more strategic spirit by adding appropriate design degrees of freedom. But even in pure operative planning problems, it might pay off to implement exact methods depending on the quality of the solution generated by exact optimization or improvement methods. There is another important difference between optimization algorithms and improvement methods: exact fulfillment of hard constraints and the prove of infeasibility of a problem. Optimization algorithms guarantee constraints to be satisfied. In improvement methods they are sometimes implemented by penalty methods (this is actually a method to treat soft constraints). An alternative approach is to reject infeasible points completely. If an improvement method fails to determine a feasible point we cannot safely conclude that the problem is infeasible. Of course, the exact fulfillment of hard constraints is part of the discussion leading to a model which is sufficiently accurate and accepted. The permissible CPU time to solve the problem may be seen as something connected to the purpose of the model. For planning problems MILP algorithms are usually sufficiently fast and CPU time is not a problem. However, if the purpose is to model and solve a scheduling problem to be used only operatively, it is usually expected to get a short response time, i.e., the solver is expected to return a result in a few minutes. Scheduling problems as mentioned above are usually difficult to solve and only highly specialised algorithms and techniques can produce optimal solutions at all. Overall, short response times are difficult to obtain for scheduling problems. Thus, improvement methods are often seen as a last resort to produce (near) feasible schedules (although the feasibility is a problem for improvement methods) in short time. If the client wants to use the same scheduling problem also to investigate investment questions then the use of improvement methods is doubtful as the example above illustrates. Ideally one would expect that a combination of exact optimization and improvement methods could solve the problem. Such a hybrid method would use an exact algorithm for a small or mid-size problem and an improvement methods if the problem becomes larger or the solver does not return a feasible point quickly enough. However, technically this is not easy at all because the exact optimization algorithm expects a declarative model, say an MILP model. The improvement method in contrast cannot easily digest this model but requires a model formulation or problem structure which uses different objects, requires a neighborhood concept (if metaheuristics are used) or a representation suitable for a evolutionary algorithm. The overall conclusion is as follows. The purpose of the model, permissible CPU time to solve the problem, and the accuracy of the data may well lead

260

10 Summary, Visions and Perspective

to the decision that it is sufficient to implement improvement methods generating feasible points. This decision itself, as far as the functionality aspect is concerned, could be put on a quantitative basis by exploiting appropriate mathematical methods. The aspects benefits and cost associated with both approaches (optimization versus improvement methods) are important and difficult to quantify at the same time. Improvement methods, although technically simpler than exact optimization approaches, are not necessarily cheaper. Costs may include cost to buy or built a model and a solution technique, train people, integrate the approach into an existing structure or replace an existing structure, follow up costs, etc. Experience shows that the costs are often underestimated. In Japan there is the tendency not to hide this but just to add more money – and everybody is happy and the project is presented as a success as long as the tool works in the end and produces more benefit than costs. In Germany there is temptation to declare this as an error, to try to hide the error if possible – and it is very difficult to add more money. This may also be triggered by the fact that many decisions for doing something would not be taken if the costs appear too high in the beginning. Comparing the costs to benefits is an art in itself. There are hard benefits which sometimes can be well estimated to only some order, but are easily wrong by a factor 2 or 3. In addition there are weak factors which often cannot be converted into money but are important nevertheless: transparency, more consistent data, a well-established quality level of a whole supply chain, more independence from the individual planner or decision taking person (a very delicate issue), changing culture and power (a human planner designing cutting stock pattern in the paper industry can easily be busy for many days working out good cutting patterns manually, and is a well respected person being able to solve such a complicated problem – optimization can solve this in minutes). Transparency is a very important issue: if a company wants to introduce a reasonable piece of software, then this may be triggered by the wish to reach a higher degree of automation. Absurd situations can occur in case this is not communicated in this way. If the weak benefits are the main driver then this will need to be communicated and the management should justify this as a political or cultural decision not pretending commercial reasons working out monetary benefits estimated too high versus costs estimated too low. Let us discuss the weak benefits associated with improving the quality of company-wide databases. The software SAP provides significantly helps in cleaning the data a company holds; so do optimization projects for the reasons discussed in Sect 10.2.2. But do companies quantify the cost of having not cleaned the data over the last fifty years? If these cost are not quantified, of course, the benefits of cleaning data do not properly show up in the benefits. If these costs are not quantified, could we draw the logical conclusion that inconsistent data do not cause any problems to companies, and it does not matter whether data are consistent or not? A same line of arguments could be drawn for other weak benefits. Let us conclude as follows. Benefits and costs are important issues for granting a project

10.2 A Summary of Experience in Optimization Projects

261

or an investment or not. They are obviously important. If they really trigger decisions (we do not consider the case that somebody has already decided and just looks for appropriate numbers supporting the decision), technical means, project time, and personnel costs should be provided to work out the decisions as well as possible. Thus, a safe advise in the context of SAP APO and optimization projects, is not to leave the field to sales persons (underestimating costs believing this helps to get the deal) or high ranking managers (overestimating benefits because, believing in the idea of the project, they think it is really great for their company) alone. SAP APO and optimization touch real world problems. Reality always strikes back (cf. De Beuckelaer, 2001, [16]) – therefore, add technical personnel to working out decisions although this may be expensive. SAP has competent personnel available, i.e., people with mathematical optimization background, so do many companies in the metal, chemical or other industries. Bring them together and have teams working out relevant decisions involving simultaneously the board members, production leaders, human planners at the production floor, and mathematicians sitting at one table. Decomposition is a nice and successful technique in mathematics. But observing that estimated costs are usually underestimated, it seems not to work too well for decision taking whether to initiate a large scale optimization project or to introduce a software such as SAP APO affecting many levels and aspects of a company or not. 10.2.2 Data and Optimization Model As any model, the data model depends on the purpose for which it is designed. Especially when data enter a mathematical optimization model one has to keep in mind that they are interpreted differently from the way a human interpreter looks at them. If you tell somebody a certain activity will last 24 hours, the human interpreter will probably accept if it takes only 23h59m. A mathematical model would probably return something like infeasible. Thus, one should keep in mind that a mathematical optimization model expects very well defined and consistent data. In the optimization model concept, there is an important difference between the human planner and scheduler and the optimizer’s world. Human planners usually know how to cope with certain situations – they can usually survive with a small and fuzzy set of information. Once a model is available the consequences of non-exact data on the objective function values can be mathematically analyzed and quantified using the sensitivity analysis described on page 37. Note that this is only possible if a model is available and if the problem can be solved quickly to optimality; this is an additional value of a model. If the uncertainty of data can be quantified by probability distributions, stochastic programming or chance constrained programming described in Sect. 2.4.3 can be applied. Optimization models (for planning or scheduling) usually require a huge amount of data. This is caused by the declarative nature of such models.

262

10 Summary, Visions and Perspective

The whole parameter space is well covered implicitly. All possible plans and schedules have to be described implicitly. Let us illustrate this by a human pathfinder who knows a good way to cross a forest. He is very familiar with the path he has chosen to follow; he also knows the vicinity of that path. The optimization model has all data and implicit knowledge about all possible paths of the whole forest. Therefore, it can find the optimal path and prove that this is the optimal path. The human pathfinder cannot prove the optimality of his path without knowing the rest of the forest. The great challenge in model building is to identify the business rules which underlie existing planning or scheduling processes. Besides issues of political nature – such as managers afraid to give up or modify the way they work because they fear becoming vulnerable in their organizations – many planners are not really able to describe explicitly or define precisely the process they follow. Often there is no well-defined and documented planning process, the human planners know implicitly how to construct plans. The real planning rules and constraints can then be extracted from them only by constructing more or less pathological cases and asking them how they would decide. Corporations resulting from a merger of several companies may have a multitude of planning procedures in place, often differing only in their strategies for handling exceptional situations. Thus, developing a reasonable and accepted optimization model is a lengthy and iterative process interwoven with a series of meetings with the planner. 10.2.3 Rules in Planning and Scheduling Problems In Sect. 2.2 we pointed out that mathematical optimization models are declarative. All constraints hold simultaneously. They are implicit restrictions to be satisfied. In real life one often faces situations that human planners follow certain rules to obtain reasonable plans or schedules. Rules can be recipes how to handle certain situations, heuristics trying various steps, or just experience accumulated in the human planner’s brain only. These rules sometimes enable us to derive and formulate constraints. In other cases, they represent more a heuristics to obtain feasible plans, or they follow certain goals possibly not yet made explicitly known. From the optimization point of view rules are usually simplifications of the real world problem eliminating degrees of freedom leading to suboptimal solutions. A planner following the rule that the production is adjusted in such a way that the tank level is always between a lower limit and an upper limit may lead us to ask about the meaning of these bounds. If the lower limit represents a safety stock or a limit justified technically and the upper bound the capacity of the tank, his rules are fully compatible with the declarative nature of an optimization model; we would apply lower and upper bounds on the tank variables. All tank levels between these lower and upper bounds are treated equally. As optimization problems tend to have the solution on the

10.2 A Summary of Experience in Optimization Projects

263

boundary of the feasible region, we will very likely observe that the tank level often reaches the lower or upper bound. If he follows the rule that he strictly observes the rules but also targets at staying away from the extreme bounds to gain more flexibility at any time, we have more than just the declarative nature. Partly he follows a goal (keeping a level of flexibility which comforts him), partly he influences the solution process itself. If he convinces us or insists on keeping the tank level close to the average value, we could penalize deviations from that average value. A rule which contradicts somewhat the concept of mathematical optimization might be to fix individual production machines to a 100% utilization level. If this rule only results from the production department being evaluated according to the overall utilization of the plant we should be careful with implementing this rule. From the overall commercial view it maybe better to sometimes stay well below a 100% level. A constructive approach the developer of a mathematical optimization model may take is to offer a flag or switch which realizes this rule as a bound in the optimization model. This keeps the person in favor of the rules happy when the flag is switched on, and allows for transparency when the flag is switched off. There is another aspect which becomes obvious when dealing with several rules, especially, when they are modeled as targets involving penalizations. We are facing the problem to scale all the penalizations relative to each other. Nevertheless, rules offer a wealth of information if they are well understood and interpreted. It is, however, very important that the client understands the difference between rules and mathematical optimization. Rules eliminate degrees of freedom. Ideally, one should allow the user to use flags enabling or disabling the familiar rules and thus allowing to make the effect of rules transparent. However, one should keep in mind that the mathematical modeling process targets to model the planning problem not the set of rules. Making all rules explicitly known creates transparency. Not knowing all rules is not ideal in terms of transparency. Providing a button mimicking the rules likely creates acceptance but will most likely not lead to the global optimum. In this context it is interesting to note that the SNP optimizer in SAP APO offers a functionality (via the optimization bound profile) which enables the user to influence the solution in such a way that the returned solution will be similar to the one obtained before. This is an example for a rule creating more stability in the resulting plans over multiple planning runs. It can be used merely to increase the planner’s acceptance or – and this is the really relevant application – to level resource loads over time in the supply chain which is a perfectly valid business objective. 10.2.4 Implementation Implementing an SAP APO solution very often occurs along with a mySAP ERP implementation or follows introducing mySAP ERP for transactional

264

10 Summary, Visions and Perspective

production and logistics processing. Such a closely interwoven implementation of ERP and advanced planning is typically most effective because of the relatively easy fine-tuning of the business processes between the two systems – once one of the systems is in place operational setup changes often involve considerable effort. One of the biggest and most difficult tasks in implementing a new ERP or advanced planning solution is putting together a consistent set of master data. Especially in companies with many subsidiaries – and this is one of the business landscapes where optimization is most useful – it proves to be a lengthy and effort-intensive process that is always underestimated. If the company has grown by mergers and acquisitions these data are often in a terrible condition regarding such trivial-looking aspects as naming conventions, multiple occurrence of the same products in different contexts, etc. Directly derived from that, one of the biggest benefits of a supply chain project stated by the user is usually the improved data quality on a corporation-wide level, together with benefits typical for supply chain optimization projects such as reduction in inventory, better customer service levels, and automated business processes. A challenge often encountered in implementing advanced planning is an adequate needs assessment before the actual implementation starts. Frequently, the prospective users are familiar with ERP-like software systems, but no experts in mapping their business process in a level of detail and completeness necessary for building an optimization application, be it a custom-built model or an APS such as SAP APO. Resulting from that, supply chain software is bought as a package without going into details such as planning algorithms. During implementation, all sorts of issues regarding the detailed business rules may come up and often it will be too late to reconsider the chosen planning algorithm or solution approach. It is the responsibility of the software vendor or mathematical consultant to adequately assess the real needs of the customer and – ideally – educate the client in the suggested methods and algorithms. This needs to include revealing side-effects that may influence the planning result. A current favorable development in this area is that there are increasingly more people familiar with optimization at SAP and that they have the opportunity to participate early in supply chain projects to set expectations realistically and work towards a solution that really fits the needs of the customers. As mentioned numerous times in our cases, much care must be taken explaining the optimization results to the user. This, again, requires people skilled and experienced in optimization and SAP APO and able to transfer confidence in the algorithm to planners and schedulers not familiar with advanced OR methods. As an easy example, think of the concept of penalty costs that are used to implement soft constraints and implications that will arise if their relation to real costs and their interdependency among each other are not understood.

10.3 Further Developments in Real World Optimization

265

10.2.5 Interfacing Tailored Models Interfacing tailored optimization models to SAP APO requires much attention to the data and the data model customized in mySAP ERP or SAP APO. Mathematical optimization often has different requirements to the data and their usage from what is needed when these data are used exclusively inside mySAP ERP or SAP APO. When using the SAP APO optimizer data integration of the application database with the built-in optimization model is taken care of automatically. In projects in which a customized optimization model is interfaced to mySAP ERP or SAP APO, the data might be stored in its own local database or user interface and the data might be enhanced even from systems outside of SAP. It is very important to check the consistency of the data. This is partly related to the data themselves, but even more to the usage of the data in the optimization model. If a state-task-network approach is chosen to model a scheduling problem in the process industry there are additional topological information needed. Once the data are in an optimization model, they gain a new dimension: this is exactness. Data used in hard constraints such as topology or mass balances can easily lead to infeasibilities. This is of extreme importance if the data have only been used by a human planner. If the same data now should be used by an automatic system, disaster can happen. Ideally, the interface connecting SAP APO and the tailored model should include an automatic consistency checker identifying hard infeasibilities caused by data errors (e.g., the lower bound on tank level is larger than the capacity of the tank), or pointing out conflicts caused by incompatible data (e.g., in a scheduling problem the demand for a non-storable product is smaller than the minimal batch size of a chemical reactor).

10.3 Further Developments in Real World Optimization Further developments of mathematical optimization in SAP APO depend strongly on SAP’s own claims and business concepts related to SAP APO as an APS, requests formulated by clients, joint development projects with clients, activities of SAP’s competitors, and last but not least, algorithmic developments in mathematical optimization. Thus, this section is less on predicting the future but rather on various positions one might take. SAP is constantly enhancing its products to better fit the clients’ needs, which results in a “functionality race” of plug-in optimization and related SAP APO core functionality. Some of the case studies we present in this book are based on prior releases of SAP APO and the functionality these external optimization models provide might now be part of standard SAP APO. In this section we want to state some recent planning philosophies outlining how they might be implemented using SAP APO and briefly discuss SAP APO as a modeling tool.

266

10 Summary, Visions and Perspective

APS providers, and SAP is no exception, still hesitate to include topics such as customer or product portfolio optimization, planning under uncertainty, multi-criteria optimization, or even MINLP in their predefined APS models. These topics are considered reserved for specifically tailored mathematical optimization models – in the context of APS they are still part of a mathematicians dream; see Sect. 10.3.4. In this context we want to stress that among the most important topics for standard software providers are profitability and the aspect of maintenance. Standard software vendors need high sales volumes in order to be successful in the market. Transferred to optimization this means that economically it might not make sense to implement the latest state-of-the-art algorithms available realizing that they (a) need time to mature until suitable for standard tools and (b) need to raise enough awareness and need in the market for actually convincing clients to implement them. Therefore, rolling out highly specialized state-of-the-art algorithms will consume excessive resources for maintaining the software for just few, probably unhappy customers. In short: The customer can expect to get a reliable Audi, but not a Formula 1 Ferrari. The customer draws advantage from this principle software vendors such as SAP follow: He or she can rely on product support once a specific functionality or feature has found its way into the APS – as long as the maintenance contract is active the software vendor will support a specific optimization application; this might not be the case for specifically tailored optimization models done by external consultants or even in-house if the respective mathematician has left the company. 10.3.1 Simultaneous Operative and Strategic Optimization Planning is part of company-wide logistics and supply chain management. However, to distinguish between planning and design, or even to distinguish between operative planning and strategic planning is often a rather artificial approach leading to unnecessary bottlenecks in operative planning. Ideally, the diffuse border lines between those areas should be overcome and the strong overlaps between planning in production, distribution or supply chain management and strategic planning should be exploited. Kallrath (2002, [50]) describes a successful case study in which operative and strategic planning aspects are combined in one MILP model. The client reports cost savings of several millions of US$ achieved via a reduction in transportation cost compared to the previous year when the model was not in use. The solution for a one year planning horizon allowed the company to better understand and forecast the flow of products between its sites. This knowledge was then used to reduce the need and cost of urgent shipments. Moreover, it was beneficial to the client to see that the design solutions (which reactors to be opened or to be closed) were stable against up to 20% changes in the demand forecast. The basic idea in this simultaneous approach is to include optional units and products to be opened or closed by the optimization model. In a tailored

10.3 Further Developments in Real World Optimization

267

optimization model linked to the appropriate data this is possible. In the SAP concept of master data that defines the model this is also possible. Perhaps the nature of the task would then suggest a scenario in a planning version without full master data integration with the transaction system (e.g., mySAP ERP), depending on the objectives of strategic or design planning in the company. If this involves a rather static set of design units (locations and products) that are activated and deactivated frequently it might be beneficial to include those in the ERP system as well. Similar to simultaneous operative and design or strategic planning, in some real-world problems it is appropriate to drop the barrier between mid term planning and short term scheduling. If the problem is sufficiently small such a simultaneous optimization planning approach will lead to better results than a layered, hierarchical approach. As described in Chap. 8, SAP APO – although designed for hierarchical planning – can be used for simultaneous planning like this if care is taken regarding specific model features (e.g., implementing sequence-dependent mode changes in the SNP optimizer). 10.3.2 Rigorous Approaches to Scheduling Scheduling is known to be very difficult. Just to model a real world problem involves so many subtle details that we might wonder whether a standard model will ever exist. Especially in the process industry one has to face complex problems involving divergent, convergent and cyclic mass flows; cf. Kallrath (2002, [52]). The number of products can easily reach the order of a few hundred, the number of articles even a few thousand. The number of units including extruders, batch reactors, tanks and silos, switch-tanks, and filling stations reaches a hundred leading to huge state-task-networks introduced by Kondili et al. (1993, [60]). Nevertheless, such problems have been addressed successfully using continuous-time formulations using decomposition techniques. We refer the reader to Ierapetriou and Floudas (1998a,b; [40], [39]), Ierapetriou et al. (1999, [41]), Lin and Floudas (2001, [66]), Lin et al. (2002, [67]), Floudas and Lin (2004, [24]), Jia and Ierapetritou (2004, [46]), Janak et al. (2004, [45]), and Floudas and Lin (2005, [25]) for up-to-date reviews on scheduling in the process industry using mixed integer linear programming and, in particular, continuous-time formulations, and to Janak et al. (2006a,b; [43], [44]) for a large-scale industrial case study. As there currently are no standard models for mathematical optimization for scheduling we will not find them in standard business software. SAP APO addresses this and meets clients’ need for a standard solution by treating scheduling problems by evolutionary algorithms and constraint programming. While to a mathematician neither of these techniques is exact optimization unless they are coupled with bound-generating techniques, they are widely used for scheduling – and often also for planning – across many industries. If

268

10 Summary, Visions and Perspective

required for a specific client problem, the MILP model in SAP APO3 could be enhanced by continuous-time aspects via a custom development by SAP or, alternatively, interfacing an external optimizer via the standard SAP APO Optimization Extension Workbench might be an option (cf. Chapters 7 and 9). 10.3.3 Planning and Scheduling Under Uncertainty SAP APO as all other APS, treats planning problems using exact optimization techniques while scheduling problems are treated by evolutionary algorithms or constraint programming. While the former is not an exact optimization technique in the sense of this book (cf. the definitions in Chap. 2), the latter can produce feasible solutions but is very limited regarding optimization (for sums of linear terms the constraint propagation is not efficient). More significant is the restriction that the SAP APO MILP optimizer assumes deterministic input data to planning and scheduling. Many planning and scheduling problems are, however, subject to a variety of uncertainties. Demand forecast is one source of uncertainty in planning; processing time subject to stochastic fluctuations are an example for uncertainties in scheduling. Modeling and solution approaches for both planning and scheduling under uncertainty are well developed in the scientific literature but they still need to be integrated into the optimizers in many APS such as SAP APO (cf. in this context the adaptive supply chain network support in mySAP SCM, aiming at the unexpected in supply chain management). 10.3.4 A Mathematician’s Dream There is a continuous trend in mathematics that new developments become standard technologies after some time. In the 1950’s special solution techniques were developed to solve differential equations numerically. Nowadays, these are standard. Until 1980, solving MILP problems was a challenge. Today, many difficult MILP problems are solved in short time with standard commercial solvers such as CPLEX or Xpress-MP. Let us dream a little bit and be optimistic and extrapolate into the future. Advanced planning systems such as SAP APO might include techniques to support: • planning problems leading to MINLP problems, • rigid multi-criteria optimization, e.g., goal programming, • optimization based planning under uncertainty. The predefined SNP model will support • any type of objective functions, and 3

Note that the MILP optimizer in SAP APO makes use of several decomposition techniques as well (cf. Chap. 4).

10.4 The Future of Optimization with SAP APO

•

269

sequence-dependent mode-changes in the sense of Chap. 8 and keeping track of origins.

Finally, customer and product portfolio optimization will be possible. And hopefully, many features, we are not yet thinking of. 10.3.5 SAP APO as a Modeling Tool Some competitors of SAP provide an APS and leave it up to the users to feed it with data constituting the supply chain model, for instance by filling in flat files containing products and BOMs in a predefined way. SAP APO follows a different philosophy: the supply chain model is built from the SAP APO database that can be integrated with the connected ERP system. In this way, a large part of the model is built automatically; during implementation the APS- and planning method-specific settings are taken care of. If needed and as we outlined in Chap. 8.3, the resulting model and the objective function can be modified in various ways by appropriately modifying the master data and the cost coefficients. Once this way of modeling is accepted, even “nonmonetary” objective functions can be built based upon the predefined one. A modeling tool in optimization will share some properties with modeling systems in mathematical optimization; cf. Kallrath (2004, [53]). The way described above turns the solver tool SAP APO into a modeling tool that addresses – within the limits of the underlying predefined mathematical model – a wide variety of supply chain optimization problems. For clients with traditionally strong mathematical optimization groups and mathematicians, including a declarative modeling language that would result in complete flexibility regarding implementing specific business rules would complement the presently available modeling alternative in a perfect way (for mathematicians). On the other hand, including such a modeling language would significantly complicate product support which now can rely on one mathematical model formulation and may limit user problems to the master data structure and the optimizer customizing.

10.4 The Future of Optimization with SAP APO The market position SAP has as the world’s leading business application software provider, its leading position also in the overall supply chain management application software market, and the highly integrated approach of the SAP software puts SAP APO in a favorable position to fulfill its promise “Advanced Planning and Optimization”. For several years SAP APO has been in the position in which clients see it as a candidate for their planning and scheduling activities. Nevertheless, companies in the chemical industry such as Bayer AG, BASF Aktiengesellschaft or BASELL GmbH have developed their own in-house

270

10 Summary, Visions and Perspective

approaches which are technically, i.e., from a mathematical point of view, superior (cf. Berning et al., 2002, [6]). As these companies Bayer, BASF, and Basell are at the same time SAP customers listed on SAP’s website http://www.sap.com/, this might lead SAP AG to roll in the technical requests from clients efficiently and be even closer in contact with the mathematical optimization community. At the same time one has to keep in mind that compared to tailored optimization models and applications, standard solutions have to achieve much higher standards of scalability and maintainability. This is an area SAP has a proven record of with its suite of business solutions including SAP APO. Meeting this objective is mutually exclusive with supporting the latest developments in mathematical modeling, the latter just needing time for maturing until they can be built in “industrial strength” standard solutions. The proven success SAP has in the market along with SAP representatives participating in the supply chain management and operations research community give confidence that SAP will continue to strive for including state-of-the art optimization technology in their product. The race is never over!4

4

In December 2005, SAP made the new version mySAP SCM 5.0 available for selected customers, see [74]. Enhancements relevant to optimization include the Explanation Tool and the Result Indicators.

Part IV

Appendix

A The Hitchhiker’s Guide to SAP APO

This appendix outlines the functionality and planning philosophy of SAP APO beyond the SNP optimizer, the latter being the focus of the rest of this book. In this brief overview of what is in SAP APO we want to give a flavor of the rich functionality this tool has to offer without claiming to go into detail which most probably would fill a number of additional books. We also omit system basis, architecture, and database considerations focusing on the business application components. The purpose of this appendix is to give the reader a self-contained and quick reference to the SAP APO functionality. Within the mySAP Business Suite, there is the supply chain management offering mySAP SCM providing solutions for supply chain collaboration, planning, coordination, and execution processes. SAP APO is one component of mySAP SCM providing functionality for planning and executing supply chain processes (cf. the official SAP documentation at http://help.sap.com/).

A.1 SAP APO Components SAP APO itself consists of multiple components that are tightly integrated. In the literature the components are sometimes also called modules (cf. Dickersbach, 2004, [17]). The components differ in their level of planning detail and the respective time horizons. They can be arranged in the supply chain planning matrix as demonstrated in Sect. 1.2 or be interpreted as constituents of a hierarchical planning strategy. The components are • • • • •

Demand Planning (DP) Supply Network Planning (SNP) and Deployment Production Planning and Detailed Scheduling (PP/DS) Transportation Management (Transportation Planning and Vehicle Scheduling, TP/VS) Global Available-to-Promise (Global ATP)

274

A The Hitchhiker’s Guide to SAP APO

Next to these there are the cross-functional components Supply Chain Collaboration enabling data exchange with business partners using other systems or via the internet and Supply Chain Monitoring providing supply chain performance KPIs, alerting in exception situations, and monitoring and comparing plan quality. There are also several industry-specific scenarios and functionality available, including a standard interface for connecting external optimizers to PP/DS for trim loss problems (cf. http://help.sap.com/).

A.2 Hierarchical Planning SAP APO follows a hierarchical planning philosophy differentiating strategic, tactical, and operational planning. The different hierarchy levels are distinguished by their planning horizon and the typical level of planning detail. The components listed above can nicely be associated with these three levels: • • •

Strategic planning: DP Tactical planning: DP, SNP Operational planning: DP, PP/DS, TP/VS, Global ATP

Demand Planning is listed in all three levels as it can hold long-term data such as sales forecasts as well as short-term data such as customer orders. It is also a powerful tool to aggregate and manage data sourced from systems external to SAP APO. Below the domains of the individual components are outlined and some examples for scenarios in which they work together are mentioned. Note that this description is not considered complete and depending on the specific business processes of the SAP client there are numerous possibilities how to orchestrate the components of SAP APO and the ERP system. DP is SAP APO’s demand management and operates on a data grid based on time buckets and key figures. The time bucket lengths can be freely defined, e.g., the first weeks can be planned in daily buckets followed by weekly, monthly, and quarterly ones. Key figures hold different “types” of demand data such as statistical forecast, customer demand, strategic sales targets, etc. In DP several sophisticated statistical methods are available to compute forecast data. Simulation scenarios allow what-if analyses, promotion planning and lifecycle planning are also part of DP. The data can be refined via collaborative scenarios involving different departments within the company as well as input from business partners with connected systems or via the internet (“collaborative demand planning”). An example for a DP scenario is combining the different forecast figures in the DP planning book (e.g., strategic and sales forecasts, customer data) to form a “consensus forecast” by freely definable macros. Forecast consumption allows defining requirement strategies that determine how to process customer orders and forecast values in the same time bucket. An example is to consume sales forecast quantities by actual customer order volumes. DP can consider BOMs (DP PPMs/PDSs)

A.2 Hierarchical Planning

275

for determining component demand. Database-wise, DP uses InfoCubes, the SAP APO database, and liveCache. Tactical planning is the domain of SNP performing mid-term supply chain planning on discrete time buckets across all relevant locations and BOM-levels. Typically based on demand data that is released from DP, SNP uses an integrated supply chain model to calculate a sourcing, production, transportation, and distribution plan. Next to MILP-based optimization, which is the topic of this book, heuristics and constraint propagation algorithms are available to be chosen to best meet the needs of the client. The algorithms are outlined in Sects. 1.4.1–1.4.3. If it turns out the SNP plan cannot satisfy the requirements forecasted by DP it might make sense to release the SNP plan to DP, adjust the forecast and re-iterate the SNP process with the new demand data. After production (i.e., after PP/DS, if all planning hierarchies are executed), deployment in SNP creates stock transfers and transport loads covering customer demand. Heuristics (applying fair-share rules if demand exceeds supply or push rules if supply exceeds demand) and optimization are available as deployment algorithms. Database-wise, SNP uses the SAP APO database and liveCache. New functionalities available in SAP APO release 5.0 relevant to optimization-based planning are the Explanation Tool and the Result Indicators (cf. http://help.sap.com/). Both are based on the optimization log data and digest the data in the logs for easier interpretation by the user. The Explanation Tool focuses on two typical supply chain exceptions: non-delivery of a demand and shortfall of safety stock. In order to provide a possible explanation it analyzes the optimizer log analyzing the factors capacity constraints, timebased constraints and maximum lot sizes, product availability, lead time, and costs. From the nature of an optimization model it can only come up with one possible reason for each exception. Via configuration settings determining the sequence of the analysis several explanation targets can be met (e.g., check for maximum lot sizes before checking the cost structure, or vice versa). The Result Indicators take data from the optimization logs, too, and present the user with the quality of the solution expressed in terms of demand fulfillment, stock level, and resource utilization data. PP/DS is targeted at short-term production planning and scheduling. Based on an SNP plan or directly on demand data from DP, PP/DS creates a detailed production plan. Differing from the SNP concept the plan is calculated in a time continuous way rather than being based on time buckets and reflects the actual order sequence on the resource-level accurate to the second. The available planning algorithms are based on heuristics, constraint propagation, and evolutionary algorithms. Integrating PP/DS with mediumterm planning is highly customizable and works via different order types for SNP and PP/DS and planning horizons determining whether a specific demand or order is planned by SNP or PP/DS. If releasing demand data from DP, for instance, those requirements inside the PP/DS horizon will be in PP/DS responsibility. Planned orders created by SNP and released to PP/DS

276

A The Hitchhiker’s Guide to SAP APO

are converted into PP/DS planned orders and scheduled in the next PP/DS run. In a classical integration scenario with the execution system (in most cases this will be SAP R/3) the planned orders created by PP/DS are immediately visible and executed in the ERP system. Next to heuristics there is the “PP/DS optimizer” that uses constraint propagation and evolutionary algorithms. Database-wise, PP/DS uses the SAP APO database and liveCache. Global ATP and Capable-to-Promise (CTP) provide functionality for operational order promising. In order to match the specific business environment, configurable rules are applied to finding supply for an order (including, for example, location and product substitution). If desired checks can be made against available production capacity and orders can be scheduled to satisfy the demand by using CTP calling PP/DS for order scheduling or multi-level ATP (including BOM explosion). Global ATP can be configured such that upon order entry in an connected SAP R/3 system SAP APO is called in the background and the confirmation dates show directly on the SAP R/3 order entry screen. As sales order confirmation is a sequential process (first come, first served), it might be necessary to redistribute the confirmed quantities based on priority rules. This is done by backorder processing, a functionality that can be seen as part of Global ATP in SAP APO. Database-wise, Global ATP and CTP use the SAP APO database and liveCache. Finally, there is TP/VS planning transportation. This is not to be confused with SNP that also considers transportation relationships between locations and results in according planned stock transfers. In a two-step process, TP/VS consolidates freight units characterized by start and destination location, quantity, and date into shipments (defining mode of transportation and route) and then assigns transportation service providers to those shipments. This can be done manually or by applying evolutionary algorithms in the first step and – starting with SAP APO release 5.0 – mixed integer optimization in the second step. Database-wise, TP/VS uses the SAP APO database and liveCache.

B Mathematical Foundations of Optimization

This appendix provides some of the mathematical foundations of optimization and provides the platform enabling the reader to understand the optimization algorithms embedded in SAP APO. This knowledge is valuable to judge whether a standard approach is technically sufficient to tackle a challenging problem or whether individual solution approaches are necessary and promising. Linear programming (LP) is a well established approach. Problems with millions of variables can be solved by standard solvers. Larger problems can be solved by special approaches such as column generations techniques. Mixed integer linear programming (MILP) problems involving thousands of binary and integer variables can be solved using commercial branch-andbound solvers. Presolving techniques are very elaborated. Advanced branchand-cut and branch-and-price methods coupled to column generation methods are available to solve even larger problems.

B.1 Linear Programming Consider the linear optimization problem (often called: linear program) in standard form1  T  LP : max c x | Ax = b, x ≥ 0, x ∈ IRn , b ∈ IRm (B.1) where IRn denotes the vector space of real vectors with n components and A is a m × n matrix. Commercial software for solving linear programing problems usually provides two alternative solution approaches: vertex-based methods such as Simplex-algorithms, and interior point methods. One of the best known algorithms for solving LPs is the simplex algorithm developed by George B. Dantzig in 1947 and described in Dantzig (1963, [15]) 1

LP problems with upper bounds are discussed in Appendix B.1.3.

278

B Mathematical Foundations of Optimization

or, e.g., Padberg (1996, [76]). The first step is to compute an initial feasible solution [see Section B.1.2] as a starting point, possibly by using another LP model which is a variant of the original model but allows us easily to determine an initial feasible solution. The simplex or the revised simplex (a more practical and efficient form for computer implementation) algorithm finds an optimal solution of an LP problem after a finite number of iterations, but in the worst case the running time may grow exponentially, i.e., for large problems we should be prepared that running time is an exponential function of the number of variables and constraints. Nevertheless on many real-world problems it performs better than so-called polynomial time algorithms developed in the 1980s, e.g., by Karmarkar (1984, [56]). In most commercially available software systems the simplex algorithm provides the foundation of a method which will comfortably produce rapid solutions to problems involving 1,000,000s of variables and 100,000s of constraints. When a problem is formulated as an LP, the formulation will not be unique, e.g., some modelers may prefer to introduce certain variables to represent intermediate stages in operations while others will avoid these concepts. However, provided the models are valid representations of the problem then the resulting LP problems will all be essentially equally easy to solve and will provide equivalent solutions. In contrast to the idea of a vertex-following method to solve an LP problem, more recently developed methods have concentrated on moving through the interior of the feasible region, a polyhedron in linear programming problems. Such methods are called interior-point methods and first received widespread attention after work by Karmarkar (1984, [56]). Since then, about 2000 papers have been written on the subject and research in optimization experienced the largest boom since the development of the simplex method (Freund and Mizuno, 1996, [27]). The idea of interior-point methods is intuitively simple if we take a naive geometric view of the problem. However, first, it should be noted that in fact the optimal solution to an LP problem will always lie on a vertex, i.e., on an extreme point of the boundary of the feasible region. Secondly the shape of the feasible region is not like, say, a multi-faceted precious stone stretched out equally into many dimensions but more likely to resemble a very thin pencil stretched out into many dimensions. Hence, an algorithm which moves through the interior of a region must pay attention to the fact that it does not leave the feasible region. Approaching the boundary of the feasible region is penalized. The penalty is dynamically decreased in order to find a solution on the boundary. Interior-point methods will in general return an approximately optimal solution which is strictly in the interior of the feasible region. Unlike the simplex algorithm no optimal basic solution is produced. Thus, “purification” pivoting procedures from an interior point to a vertex having an objective value no worse have been proposed and cross-over schemes to switch from interior-point algorithm to the simplex method have been developed [2].

B.1 Linear Programming

279

B.1.1 A Primal Simplex Algorithm For an elementary treatment and examples for the primal simplex algorithm see Kallrath & Wilson (1997, [55, Chap. 3 and Appendix]) and Kallrath (2002, [51]). Here, we just summarize the abstract ideas and consider the linear program (B.1). Vertex-based methods, the Simplex-algorithm is a special case, exploit the concept of basic variables collected into the basic vector xB . The algebraic platform is the concept of the basis B of A, i.e., a linearly independent collection B = {Aj1 , ..., Ajm } of columns of A. Sometimes, just the set of indices J = {j1 , ..., jm } referring to the basic variables or linearly independent columns of A is referred to as the basis. The inverse B −1 gives a basic solution x ¯ ∈ IRn which is given by   T x ¯T = xT B , xN where xB is a vector containing the basic variables computed according to xB = B −1 b and xN is an (n − m)-dimensional vector containing the non-basic variables: xN = 0 ,

xN ∈ IRn−m

If x ¯ is in the set of feasible points S = {x : Ax = b, x ≥ 0} , then x ¯ is called a basic feasible solution or basic feasible point. If 1. the matrix A has m linearly independent columns Aj , 2. the set S is not empty and 3. the set {cT x : x ∈ S} is bounded from above, then the set S defines a convex polyhedron P and each basic feasible solution corresponds to a vertex of P . Assumptions (2) and (3) ensure that the LP is neither infeasible nor unbounded, i.e., it has a finite optimum. It can be shown that in order to find the optimal solution it is sufficient to consider all basic solutions (sets of m linearly independent columns of A), check whether they are feasible, compute the associated objective function, and pick out the best one. In this sense finding an optimal solution for an LP is a combinatorial problem. An LP problem can have at most m positive variables in the solution. At least n − m variables, these are the non-basic variables, must take the value zero. McMullen (1970, [68]) has shown that there can exist at most2       n − m+2 n − m+1 2 2 + (B.2) f (n, m) := n−m n−m basic feasible solutions. Therefore, this purely combinatorial approach is not attractive in practice. 2

This result is only true if no upper bounds [see Section B.1.3] are present.

280

B Mathematical Foundations of Optimization

Geometrically the (primal) simplex algorithm can be understood as an edge-following algorithm that moves on the boundary of a polyhedron representing the feasible set, i.e., from vertex to vertex of the polyhedron. In each move corresponding to a linear algebra step (technically, a Pivot step) the objective function value is either improved or does not change. Algebraically, in each iteration, one column of the current basis is modified, according to this exchange of basic variables, matrix A, and vectors b and c are transformed to matrix A , and vectors b and c . Technically, this procedure is called a pivot or pivot operation or pivot step. Now we can also understand degenerate cases in LP. A purely algebraic concept is to call an LP problem degenerate if the optimal solution contains basic variables with value zero. If we combine the algebraic and geometric aspects we can interpret a degenerate problem as one in which a certain vertex (usually we are considering the one leading to optimal objective function) has different algebraic representations, i.e., two vertices are co-incident with an edge of zero length between them. Instead of keeping and computing the complete matrix A based on the previous iteration, the revised simplex algorithm is based on the initial data A, b and cT , and on the current basis inverse B −1 . The first step is to find a feasible basis B as described in Section B.1.2. Note that this problem is, in theory, as difficult as solving the optimization problem itself. Once the basis is known we can compute3 the inverse, B −1 , of the basis, the values of the basic variables

and the dual values, π T ,

xB = B −1 b

(B.3)

−1 π T := cT BB

(B.4)

Note that π T is a row vector. Now we are in the position to compute the reduced costs, dj , dj = cj − π T Aj (B.5) for the non-basic variables [the reduced cost of the basic variables are all equal to zero d(xB ) = 0]. Note that formula (B.5) computes the reduced costs by using only the original4 data cj and Aj , and the current basis B. If any of the dj are positive, we can improve the objective function by increasing the corresponding xj . So, the problem is not optimal. The choice of which positive dj to select is partly heuristic: conventionally, one chooses the largest dj but commercial solvers are different from textbook implementations. They use so-called partial pricing and also devex pricing [36]. The term partial pricing 3 4

As further pointed out on page 282 the basis inverse is only rarely inverted explicitly. From now on Aj denotes the columns of the original matrix A corresponding to the variable xj .

B.1 Linear Programming

281

indicates that the reduced costs are not computed for all non-basic variables. Sometimes, the first reduced cost with positive5 sign gives the variable to become the new basic variable. Other heuristics choose one of the non-basic variables with positive sign randomly. And there must be a heuristic device which tells the algorithm when to switch from partial to full pricing. Only full pricing can do the optimality test. A sufficient optimality criterion for an optimal solution of a maximization problem is dj = cj − π T Aj ≤ 0 ,

∀j

(B.6)

In a minimization problem the criterion is dj = cj − π T Aj ≥ 0 ,

∀j

Note that we said a sufficient but not necessary condition. The reason is that in the case of degeneracy several bases define the same basic feasible solution and some can violate the criterion. If nondegenerate, alternative optimal solutions exist (this case is called dual degeneracy) then necessarily the reduced cost for some of the non-basic variables are equal to zero. If dj < 0 for all non-basic variables in a maximization problem then the optimal solution is unique. If we have not yet reached optimality we check whether the problem is unbounded. If the problem is bounded we use the minimum ratio rule to eliminate a basic variable. Both steps are actually performed simultaneously: the minimum ratio rule fails precisely when the incoming vector gives infinite improvement. The data needed for applying the minimum ratio rule are also derived directly from B −1 Aj = B −1 Aj After the minimum ratio rule has been applied we have the new basis, i.e., a set of indices or linearly independent columns. What needs to be done is to get the current basis inverse B−1 . There are several formulae to do this, but all of them are equivalent to computing the new basis inverse although the inverse is never computed explicitly. To be correct, the basis is only rarely inverted explicitly. Elementary row operations carry over the existing basis inverse to the next iteration.6 However, every, say 100 iterations, the basis inverse is refreshed by inverting the basis matrix 5 6

In this case we are solving a maximization problem. If we inspect the system of linear equations in each iteration we see that columns associated with the original basic variables give the basis inverse associated with the current basis. The reason is that elementary row operations are equivalent to a multiplication of the matrix representing the equations by another matrix, say M. If we inspect the first iteration we can understand how the method works. The initial matrix, and in particular the columns corresponding to the new basic variables are multiplied by M and obviously give B·M = 1l, where 1l is the unit matrix. Thus we have M = B−1 . Since we have multiplied all columns of A by M, and in particular also the unit matrix associated with the original basic variables, these columns just give the columns of the basis inverse B−1 . In each iteration k

282

B Mathematical Foundations of Optimization

taken from the original matrix A. Through this procedure, rounding errors do not accumulate. In addition, in most practical applications A is very sparse whereas after several iterations the transformed matrix A becomes denser so that, especially for large problems, the revised simplex algorithm usually needs far less operations. The algorithm continues by computing the values of the basic variables, dual values, and so on until optimality is detected. Let us come back to the basis inverse. Modern software implementations of the revised simplex algorithms do not calculate B −1 explicitly. Instead commercial software uses the product form Bk = B0 η1 η2 . . . ηk of the basis to express the basis after k iteration as a function of the initial basis B0 (usually a unit matrix) and the so-called rather the eta-matrices or eta-factors ηi . The ηi -matrices are m × m matrices η = 1l + uvT derived from the dyadic product of two vectors u and v leading to a very simple structure (“1” on the diagonal, and just non-zeros in one column). To store the η-matrices it is sufficient to store the η-vectors u and v. Computing equations such as BxB = b yielding xB = B −1 b are then solved by −1 . . . η1−1 b xB = ηk−1 ηk−1

The inverse of the η-matrices (under appropriate assumptions) can be computed very easily according to the formula η −1 = 1l −

1 uvT 1 + vT u

Note that we need to store all ηi -vectors. As the iterations proceed, the amount of storage for the factors increases. So a re-inversion of the basis occurs not only for reasons of numerical accuracy but also due to a “storage versus computation” trade off. Readers more interested in the details of the linear algebra computations, LU factorizations, η-vectors and conserving sparsity may benefit from reading Gill et al. (1981, [29], p.192), Padberg (1996, [76, Sect. 5.4]) and Vanderbei (1996, [97]). An important idea in LP is the dual problem and its corresponding primal problem (the original problem). When the dual problem is solved, the optimal values of its variables (and slacks) correspond to the values of the reduced costs and shadow prices of the primal problem. Thus the operation of the simplex algorithm on the primal problem is governed by the updating of the solution we multiply our original matrix by such a matrix Mk , so the orginal basic columns represent the product of all matrices Mk which then is the basis inverse of the current matrix.

B.1 Linear Programming

283

values of the dual problem which provides current values of the reduced costs on variables. Thus the simplex algorithm is an algorithm which is implicitly moving between the primal and dual problems, updating solution and reduced cost values respectively. Understanding the concept of dual values and shadow prices we can also give another interpretation of the reduced costs in terms of shadow prices. While the dual values, or Lagrangian multipliers, give the cost for active constraints, the reduced cost of a non-basic variable is the shadow price for moving it away from zero, or, in the presence of bounds on the variable, to move the non-basic variable fixed to one of its bounds away from that bound. That also explains why basic variables have zero reduced costs: in non-degenerate cases, basic variables are not at their bounds. B.1.2 Computing Initial Feasible LP Solutions The simplex algorithm explained so far always starts with an initial feasible basis and iterates it to optimality. We have not yet said how we could provide an initial solution. There are several methods, but the best known are big M methods and phase I and phase II approaches. Less familiar are heuristic methods usually referred to as crash methods. To discuss the first two methods consider the LP problem with n variables and m constraints in standard form [here it is advantageous to consider a minimization problem] cT x

min subject to Ax = b ,

x≥0

By multiplying the equations Ax = b by −1 where necessary we can assume that b ≥ 0. That enables us to introduce non-negative violation variables v = (v1 , . . . , vm ) and to modify the original problem to min

cT x + M

m 

vj

j=1

subject to Ax + v = b ,

x≥0 ,

v≥0

5

M is a “big” number, say 10 , but it is very problem dependent as to what big means. The idea of the big-M method is as follows. It is easy to find an initial feasible solution. Can you see this? Check that v=b

,

x=0

is an initial feasible solution. Now we are able to start the simplex algorithm. If we choose M to be sufficiently large, we hope that we get a solution in which none of our violation variables is basic, i.e., v = 0. What if we find a

284

B Mathematical Foundations of Optimization

solution with some positive variables vj ? In that case either M was too small, or our original problem is infeasible. How do we know the right size of M ? One could start with small values, and check whether all violation variables are zero. If not, one increases M . Ultimately, M must become very large if the problem appears infeasible and one is essentially doing the two-phase method described in the next paragraph. There is an alternative approach which does not depend on a scaling parameter such as M : the two-phase method. The idea is the same but it uses a different objective function, namely min

m 

vj

j=1

i.e., just the sum of the violation variables. Non-zero objective function values prove that the original problem is infeasible. Why do we have two methods? Would not one be enough? If you inspect both methods carefully you will notice that they have different advantages or disadvantages. If one takes the limit M → ∞ the big M methods becomes the two-phase method. Using the big M method the software designer has to ensure and to worry that M is big enough. Often M is adapted dynamically when trying to find an initial solution. It is just good enough to find a solution with v = 0. Keeping the original variables in the objective function may provide an initial solution which is closer to the optimal solution. In practice the number of artificial variables is kept to a minimum. If a certain row already has a slack or surplus variable there is no need to introduce an additional one. Mixtures of big M and two-phase methods are also used. In addition, commercial LP software employs so-called crash methods. These are heuristic methods aiming at finding an extremely good initial solution very close to the optimal solution. Initial feasible LP solutions can also be computed by re-using a basis saved from a previous related run. This approach produces good initial feasible solutions quickly if the model data have only changed a bit, or if only a few variables or constraints have been added. New methods for computing initial solutions or good starting candidates are hybrid methods. Such methods, combining the simplex algorithm and interior-point method, are described in the Section B.1.5. B.1.3 LP Problems with Upper Bounds So far we have considered the LP problem with n variables and m constraints in standard form [it is not really important whether we consider a minimization or maximization problem] min subject to

cT x

B.1 Linear Programming

Ax = b ,

285

x≥0

In many large real-world problems it is advantageous to exploit another structure which occurs frequently, upper and lower bounds on the variables. This is formulated as min cT x subject to

Ax = b

,

l ≤ x ≤ u

Since we always can perform a variable substitution x = x −l and observing that the new variables have the bounds 0 ≤ x ≤ u −l = u, it is sufficient to consider the problem min cT x subject to Ax = b ,

0≤x≤u

Of course we could reformulate this problem by introducing some slack variables s ≥ 0 in the standard way min

cT x

subject to Ax = b x+s=u

,

x≥0 ,

s≥0

Since in many large real-world problems we have n  m (there are often between three and ten times as many variables as rows) a straightforward application of the simplex algorithm would lead to a very large basis of size (m + n) × (m + n). Exploiting the presence of the upper bounds will lead to a modified simplex algorithm which still is based on a basis of size m × m only. The idea is to distinguish between nonbasic variables, xj , j ∈ J0 , that are at their lower bound of zero (the concept we are familiar with) and those xj , j ∈ Ju , that are at their upper bound (the new concept). With the new concept no explicit slack variables are necessary. Let us now try to see how the simplex algorithm works when performing a basis exchange. Pricing now tells us that a current basis is not optimal if one of these two situations occurs: 1) there exist indices j ∈ J0 with dj < 0 2) there exist indices j ∈ Ju with dj > 0 In case 1) we could increase a nonbasic variable, in case 2) we could decrease it. Both cases would lead to a decreased value of the objective function. A new consideration, when increasing or decreasing a nonbasic variable, is that we need to calculate whether it could reach its upper (respectively lower) bound. The minimum ratio rule controls how we could change a nonbasic variable. We have to stop increasing a nonbasic variable when one of the basic variables becomes zero. The minimum ratio rule in the presence of upper bounds on

286

B Mathematical Foundations of Optimization

variables gets a little bit more complicated since variables might hit their upper bounds. Case 1) leads to two sub-cases: 1a) the nonbasic variable xj can be increased to its upper bound while no basic variables reaches zero or its upper bound, or 1b) while increasing the nonbasic variable xj a basic variable reaches zero, or a basic variable reaches its upper bound. Case 1a), called a flip for obvious reasons, is easy to handle: one just moves the index j into the new set Ju . Reaching zero in 1b) is handled as in the standard simplex algorithm: variable xj enters the basis and the index of the variable leaving the basis is added to the new set J0 . When an upper bound is hit in 1b) the variable xj enters the basis and the index of the variable leaving the basis is added to the new set Ju . Case 2) can be analyzed by considering the slack sj = uj − xj . If the nonbasic variable xj is at its upper bound then sj is at its lower bound (zero). sj plays the same role (note that its upper bound is uj ) as the nonbasic variable xj considered in 1a) and 1b) and thus the argument is the same. The linear algebra involved in the iteration is similar to the standard simplex, and essentially no extra computations are required. Readers more interested in the subject are referred to Padberg (1996, [76, pp.75-80]). We have now seen why exploiting bounds on variables explicitly leads to better, i.e., faster numerical, performance: there is a little more testing and logic required in the algorithm but no additional computations. This has significant consequences for the B&B algorithm which adds only new bounds to the existing problem. Note that since the bounds are treated explicitly and not as constraints no shadow prices are available on these “constraints”. Instead, the shadow prices can be derived from the reduced costs of the nonbasic variables fixed at their upper bounds. B.1.4 Dual Simplex Algorithm The (primal) simplex algorithm concentrates on improving the objective function value of an existing basic feasible solution. In contrast, there is also the dual simplex algorithm which solves an LP problem by taking a dual optimal basic solution which is optimal in the sense that the reduced costs computed according to (B.5) have the correct sign, but are not basic feasible. The dual simplex algorithm tries to achieve feasibility of the solution while retaining its optimal properties. The two approaches can be seen as “dual” to each other: while the primal algorithm makes the choice of the new basic variable first, and then decides on which existing basic variable should be eliminated, the dual algorithm eliminates first an existing basic variable, and then selects a new basic variable.

B.1 Linear Programming

287

The dual simplex algorithm is often used within the B&B algorithm. When a branch is made the subproblem just differs from the original problem in having a different bound on the branching variable; remember from Section B.1.3 that bounds can be treated very efficiently in the simplex algorithm. So the LP solution obtained at the parent node could now be considered optimal but not feasible. In most cases, the dual simplex algorithm restores feasibility quickly to the solution, say, within a few iterations. By using the dual simplex algorithm we are able to take advantage of the earlier work done by the simplex algorithm and then move to a new optimal solution quickly. However, there is no guarantee that this will always happen. If the (primal) simplex algorithm was used after each branch the problem would need to be solved from the start again and this would be burdensome. B.1.5 Interior-point Methods In linear programming, interior-point methods (IPMs) are well suited especially for large, sparse problems or those, which are highly degenerate. Here considerable computing-time gains can be achieved. Such methods have already been integrated into some LP-solvers, such as CPLEX or Xpress-MP. The idea of IPMs is to proceed from an initial interior point x ∈ S satisfying x > 0, towards an optimal solution without touching the boundary of the feasible set S. The condition x > 0 is (in the second and third method) guaranteed by adding a penalty term to the objective function. To explain the essential characteristics of interior-point methods, let us consider the logarithmic barrier method in detail when applied to the primaldual pair primal problem ←→ dual problem min cT x s.t. Ax = b x≥0

max bT y s.t. A y + w = c w≥0 T

(B.7)

with free, dual variable y, the dual slack variable w and the solution vectors x∗ , y∗ and w∗ . A feasible point x of the primal problem is called strictly feasible if x > 0, a feasible point w of the dual problem is called strictly feasible if w > 0. The primal problem is mapped to a sequence of nonlinear programming problems ⎧ ⎫  n ⎨ ⎬   Ax = b , µ = µ(k) P (k) : min cT x − µ ln xj  x>0 ⎩ ⎭ j=1

with homotopy parameter µ where we replaced the non-negativity constraint on the variables with the logarithmic penalty term; instead of using xj in the penalty term we could have considered the inequality Ai x ≤ bi through terms of the form ln(bi − Ai x).

288

B Mathematical Foundations of Optimization

At every iteration step k, µ is newly chosen as described, for instance, in [55, Chap. 3 and Appendix]. The penalty term, and therefore the objective function, increases to infinity. By suitable reduction of the parameter µ > 0, the weight of the penalty term, which gives the name logarithmic barrier problem to this methods, is successively reduced and the sequence of points obtained by solving the perturbed problems, converges to the optimal solution of the original problem. So, through the choice of µ(k) a sequence P (k) of minimization problems is constructed, where the relation lim µ(k)

k→∞

n 

ln xj = 0

j=1

has to be valid, viz. lim argmin(P (k) ) = argmin(LP ) = x∗

k→∞

where the function argmin returns an optimal solution vector of the problem. We have replaced one optimization problem, namely (B.7), by several more complex NLP problems. So, it is not a surprise to learn that interior-point methods are special homotopy algorithms for the solution of general nonlinear constrained optimization problems. Applying the Karush-Kuhn-Tucker (KKT) conditions [Karush (1939, [57]) and Kuhn and Tucker (1951, [62])], these are the necessary or the sufficient conditions for the existence of local optima in NLP problems, we get a system of nonlinear equations which can be solved with the Newton-Raphson algorithm as shown below. The good news is that the problems P (k) or systems of nonlinear equations they produce need not to be solved exactly in practice, but one is satisfied with the solution achieved after one single iteration in the Newton-Raphson algorithm. So far we have considered the primal problem. To get to the dual and finally the primal-dual7 version of interior-point solvers used in commercial solvers, the Karush-Kuhn-Tucker (KKT) conditions are derived from the Lagrangian function (a common concept in NLP) L = L(x, y) = cT x − µ

n 

ln xj − yT (Ax − b)

(B.8)

j=1

Note that the constraints are multiplied by the dual value (Lagrange multipliers), yT , and then are added to the original primal objective function. Details are provided, for instance, in [55, Chap. 3 and Appendix]. By definition interior-point methods operate within the interior of the feasible region and thus need strictly positive initial guesses for the vectors x and w. How can such feasible points be obtained? This is a very difficult 7

The reason for using this expression is that the method will include both the primal and dual variables.

B.1 Linear Programming

289

task. The method described in Section B.1.2 does not help this time since we do not want to use the simplex algorithm. Since interior-point methods are path-following methods one would like to have an initial point as close as possible to the central path and to be as close to primal and dual feasibility as possible. So called “primal-dual infeasible-interior-point methods” proved to be successful. These methods start with initial points x(0) and w(0) but do not require that primal and dual feasibility is satisfied. This is quite typical for nonlinear problems which use Newton type algorithms. Feasibility is attained during the process as optimality is approached8 . Therefore, a primal and dual feasibility test is part of the termination criterion; see, for instance, [55, Chap. 3 and Appendix] for details. Interior-point methods produce an approximation to the optimal solution of an LP but no optimal basic and non-basic partition of the variables. Since the optimal solution produced by the interior-point method is strictly in the interior of the feasible solution there are many more variables not fixed at their bounds than we would expect in a simplex solution. The concept of basic solutions is, however, very important for sensitivity analyses and the use of LP problems as subproblems in B&B algorithms. The availability of a basis facilitates warm-starts. Commercial implementations of interior-point methods use cross-over techniques, i.e., at some time controlled by a termination criterion the algorithm switches from the interior-point method to the simplex algorithm. Crossing-over starts with the basis identification providing a good feasible initial guess for the simplex algorithm to proceed. The simplex algorithm improves this guess quickly and produces an optimal basic solution. At the moment the best simplex algorithms and the best interior-point methods are comparable. The simplex algorithm needs many iterations, but these are very fast. The number of the iterations grows approximately linearly with the number of constraints and logarithmically in the number of variables. Interior-point methods usually need about 20 to 50 iterations; this number grows weakly with the problem size. Every iteration requires the solution of an n × n system of nonlinear equations which is quite costly. This system is linearized. Thus the central computing consumption for a problem with n variables is the solution of a n × n linear equation system. That is why it is essential for the success of the IPM, that this system matrix is sparse. Although problem dependence plays an essential role for the valuation of the efficiency of simplex algorithms and IPMs, the IPMs seem to have advantages for large, sparse problems. Especially for big systems hybrid algorithms seem to be very efficient. In the first phase these determine a nearly optimal solution with the help of an IPM, viz. determine a solution near the polyhe8

The screen output of an interior-point solver may thus contain the number of the current iteration, quantities measuring the violation of primal and dual feasibility, the values of the primal and the dual objective function (or the duality gap) and possibly the barrier parameter as valuable information on each iteration.

290

B Mathematical Foundations of Optimization

dra edge. In the second phase, “purification” pivoting procedures are used to create a basis. Finally, the simplex algorithm uses this basis as an initial guess and finally iterates to the optimal basis. Further aspects of using the simplex algorithm or IPMs are discussed, for instance, in [55, Chap. 3 and Appendix].

B.2 Mixed Integer Linear Programming All commercial packages, in addition to more complicated methods, use variants of the Branch and Bound (B&B) algorithm originally developed by Land and Doig (1960, [64]) to solve mixed integer linear programming problems. The B&B idea or implicit enumeration characterizes a wide class of algorithms which can be applied to discrete optimization in general. For an elementary treatment see Kallrath & Wilson (1997, [55, Chap. 3 and Appendix]) and Kallrath (2002, [51]). Here, we provide an orientation about this method and its relevant computational steps. The branch in B&B hints at the partitioning process used to produce integer feasible solutions or to prove the optimality of a solution. Lower and upper bounds are used during this process to avoid an exhaustive search in the solution space. The algorithm terminates when the differences between upper and lower bounds becomes less or equal to a predefined value, ∆ ≥ 0 (∆ = 0 for proving optimality). The computational steps of the B&B algorithm are summarized as follows. After initialization the bounds and the nodes list, the LP-relaxation —that is that LP problem obtained when relaxing all integer variables to continuous ones— establishes the first node. The node selection is obvious in the first step (just take the LP-relaxation), but later on it is based on various heuristics. A B&B algorithm of Dakin (1965, [13]) with LP-relaxations uses three pruning criteria: infeasibility, optimality and value dominance relation. In a maximization problem the integer solutions found lead to an increasing sequence of lower bounds, z IP , while the LP problems in the tree decrease the upper bound, z LP . Note that α denotes an addcut which causes the algorithm to accept a new integer solution only if it is better by at least the value of α. If the pruning criteria fail branching starts: the branching in this algorithm is done by variable dichotomy: for a fractional yj∗ two child nodes are created with the additional constraint yj ≤ [yj∗ ] resp. yj ≥ [yj∗ ] + 1. Other possibilities for dividing the search space are, for instance, generalized upper bound dichotomy or enumeration of all possible values, if the domain of a variable is finite ([8], [73]). The advantage of variable dichotomy is that only simple lower and upper bounds are added to the problem. In Section B.1.3 we have shown why bounds can be treated much easier than general constraints. The selection of nodes plays an important role in implicit enumeration; widely used is the depth-first plus backtracking rule as presented above. If a node is not pruned, one of its two sons is considered. If a node is pruned, the

B.2 Mixed Integer Linear Programming

291

algorithm goes back to the last node with a son which has not yet been considered (backtracking). In linear programming only lower and upper bounds are added, and in most cases the dual simplex algorithm [see Section B.1.4] can reoptimize the problem directly without data transfer or basis re-inversion [73]. Experience has shown [8], that it is more likely that feasible solutions are found deep in the tree. Nevertheless, in some cases the use of the opposite strategy, breadth-first search, may be advantageous. Another important point is the selection of the branching variable. A common way of choosing a branching variable is by user-specified priorities, because no robust general strategy is known. Degradations or penalties may also be used to choose the branching variables, both methods estimate or calculate the increase of the objective function value if a variable is required to be integral, especially penalties are costly to compute in relation to the gained information so that they are used quite rarely [73]. The B&B algorithm terminates after a finite number of steps. Termination occurs when the lower and the upper bound cross or when the node list becomes empty. In that case the result is either the optimal integer feasible solution or the message that the problem does not have any integer feasible solution. In practice, it happens very often that the user does not want to wait until the node list becomes empty but wants to stop after one, or several integer solutions have been found. If an integer feasible solution has been found the upper and lower bounds mentioned above may be used to estimate the quality of the solution. Let us see how that works: during the B&B for a maximization problem we know that z LP ≥ z ∗ ≥ z IP where z ∗ is the (unknown) value of the best integer solution, z IP (possibly −∞) is the value of the best integer solution found so far in the search and z LP = maxi {ziLP } where ziLP is the optimal value of the LP-relaxation at active node i (nodes that have been fathomed are not considered). The quality of the solutions is quantified by the integrality gap which is a function of the upper and lower bounds derived by the B&B algorithm. In a maximization problem the upper bound, z U , is provided by the LP relaxations z LP while the lower bound, z L , corresponds to the best integer solution z IP found. So we have the bounds zL ≤ z∗ ≤ zU

(B.1)

∗

on the objective function value z of the (unknown) optimal solution. In a maximization problem the difference z U − z ∗ is called the integrality gap. If the search is terminated before z ∗ has been computed, the difference z U − z L is used as an upper bound on the integrality gap. Assuming that both z L and z U are positive the quality of our solution can also be expressed by the relative integrality gap p := 100

zU − zL z LP − z IP = 100 zL z IP

(B.2)

292

B Mathematical Foundations of Optimization

which expresses that the difference between the best solution found and the (unknown) optimal solution is less than or equal to p% of the upper bound. With the present data, p is of the order of 10%. While the lower bound z L increases if we allow the algorithm to seek for further integer feasible solutions the upper bound z U decreases very slowly during the computations. The upper bound can be decreased faster by using the Branch&Cut algorithm embedded by commercial MILP solvers. The Branch&Bound algorithm terminates if z LP − z IP ≤ ∆, where ∆ is some tolerance. If ∆ = 0, we haven proven optimality. If ∆ > 0, we have found a solution which at most deviates by ∆ from the maximum z ∗ . So it can be seen that a criterion for node selection in B&B is to reduce the integrality gap z LP − z IP . One way to do this is to select a node which has a good chance of yielding a new integer feasible solution better than the current z IP . Another way is to branch on the node having the largest ziLP on the grounds that a descendant of this node will certainly have no higher a value of ziLP , and probably will have a lower value, in which case z LP will be smaller. The interpretation of the percentage gap introduced above becomes difficult if a model includes penalty terms containing weighting coefficients without any economic interpretation. Sometimes such penalty terms are used to reduce infeasibilties. To illustrate the problem let us consider the following problem with an objective function containing two penalty terms min P1 r1 + P2 r2

(B.3)

where r1 and r2 are relaxation variables with the following meaning. The first one, r1 , measures the deviation from demand. The second one, r2 , quantifies the deviation from a due time. A valuable and expensive material is rarely demanded in fractional quantities, D, by important customers, but can be produced only in kilograms; the amount produced is denoted by the integer variable π. Deviations from demand are not avoidable. It is allowed to produce less or more than the demand but the deviations should be kept at a minimum. Thus, r1 measures the deviation from the next integer values 1, 2 or 3, and so on. The relaxation or deviation variable r1 is related to π by the disjunctive set9 of constraints π + r 1 = D ∨ π − r1 = D . (B.4) The demand is subject to a due time, T D . The time at which the production starts is denoted by the variable tS . t S + T P ≤ T D + r2

.

(B.5)

Let us assume in this example that the processing time, T P , is one hour, i.e., T P = 7. Further we assume that T D = 16 hours, i.e., the production should be finished at 4pm. The personnel at the production floor tells us that the 9

Kallrath & Wilson (1997, Sec. 6.2.3, [55]) outlines how to treat disjunctive sets of constraints.

B.2 Mixed Integer Linear Programming

293

machine is not available before 10am. Therefore, whatever we do, the minimal value for r2 is r2 = 1 as tS ≥ 10. If we use an example value of D = 1.4 kg we obviously get the optimal value π = 1 and r1 = 0.4, and r2 = 1 as above. The integrality gap for a minimization problem is defined as p := 100

z IP − z LP zU − zL = 100 U z z IP

.

(B.6)

The LP-relaxation gives π = 1.4, r1 = 0 and thus z LP = P2 . If in the B&B algorithm the node π ≥ 2 is evaluated first, the associated gap is pπ≥2 = 100

(0.6P1 + P2 ) − (0 + P2 ) 0.6P1 = 100 0.6P1 + P2 0.6P1 + P2

.

(B.7)

Note that we have 0 ≤ pπ≥2 ≤ 100. If we increase P2 the gap pπ≥2 approaches zero. Thus, the gap depends significantly on scaling. The situation we are facing here is, due to the appearance of r2 in (B.5), similar to adding a constant to the objective function. The lesson to be learned is that one needs to pay attention to such issues. The penalty approach can be avoided completely by exploiting the goal programming approach outlined in Section 2.4.2. The reader might have heard that MILP problems, and in particular, scheduling problems are hard problems and he might have learned that they are classified as N P hard and in many cases N P complete. In complexity theory these are measures of how difficult it is to solve a certain class of optimization problems. It is important to treat problems with such attributes respectfully. But it does not mean that they cannot be solved to optimality. It is just that they have bad scaling properties. If a standard method such as Branch&Bound works well for a given problem instance, one might experience difficulties if the problem size changes by even only 20%. It is this complexity why we find that all commercial packages use preprocessing and presolving techniques to tighten the model at the root node or within the B&B algorithm. This pushes the limit of which problems can be solved continuously towards larger and larger problems. Preprocessing methods introduce model changes to speed up the algorithms. The modifications are made, of course, in such a way that the feasible region of the MILP is not changed. They apply to both pure LP problems and MILP problems but they are much more important for MILP problems. A selection of several preprocessing algorithms is found in Johnson et al. (1985, [47]). A more recent overview of simple and advanced preprocessing techniques is given by Savelsbergh (1994, [83]). The reader is also referred to the comprehensive survey of presolve10 methods by Andersen and Andersen 10

The terms preprocessing and presolve are often used synonymously. Sometimes the term presolve is used for those procedures which try to reduce the problem size and to discover whether the problem is unbounded or infeasible. Preprocessing involves the presolving phase but includes all other techniques which try, for instance, to improve the MILP formulation.

294

B Mathematical Foundations of Optimization

(1995, [1]). Some common preprocessing methods are: presolve (arithmetic tests on constraints and variables, bound tightening), disaggregation of constraints, coefficient reduction, and clique and cover detection. Many of these methods are implemented in commercial software but vendors are usually not very specific about which techniques they have implemented or methods used. In particular, during preprocessing constraints and variables are eliminated, variables and rows are driven to their upper and lower bounds, or an obvious basis is identified. Being aware of these methods may greatly improve the user’s model building leading to more efficient models or reduce the user’s efforts if it is known that the software already does certain presolve operations. Commercial solvers, nowadays, also to apply heuristics to generate integer feasible points from nodes still containing fractional values. These issues (preprocessing, presolve, constructive heuristics inside the B&B scheme) become more and more important in commercial MILP solver. They are the great secrets of the companies developing MILP solvers.

B.3 Multicriteria Optimization and Goal Programming Here we provide examples illustrating two solution techniques for goal programming: the pre-emptive (lexicographic) and the Archimedian approach. In pre-emptive goal programming goals are ordered according to importance and priorities . The goals at a certain priority level are considered to be infinitely11 more important than the goals in the next lower level. Pre-emptive goal programming is recommended if there is a ranking between incommensurate objectives available. In the Archimedian approach weights or penalties are applied for not achieving targets. The following example illustrates this. Let 2x + 3y represent profit, and y + 8z represent return on capital in a simple LP model where there are a number of constraints involving the variables x, y, and z and other variables. In addition, let P be the desired level of profit and C the desired level of return on capital. P and C might be obtained from last figures of last year plus some percentage to give targets for this year. We now adjoin four non-negative variables d1 , d2 , d3 , d4 ≥ 0 as well as two new goal attainment constraints to our model 11

It would also be possible to define weights which express how much the ith objective is more important than the (i + 1)th objective.

B.3 Multicriteria Optimization and Goal Programming

2x +3y +d1 − d2 =P y +8z +d3 − d4 = C

295

goal 1 goal 2

The objective function is to minimize deviation from target min

d1 + d 2 + d 3 + d 4

Any objective function attempted previously in the formulation would have to be expressed as a goal constraint. The problem is now an ordinary LP problem. (IP problems may be modified similarly.) Note the use of two d’s in each constraint (with opposite signs) and the presence of all d’s in the objective function (with the same sign). Note also how the d’s perform a role to represent a free variable, namely the deviation from target. The technique for two goals can be extended to handle three or more goals. One feature of goal programming is that every goal is treated as being equally important, and consequently an excess of 100 units in one goal would be compensated by a shortfall of 100 in another, or would be equivalent to excesses of 10 units in each of 10 goals. Neither of these sets of circumstances might be desirable, so two strategies may be introduced: (a) place upper limits on the values of d variables, e.g., d1 ≤ 10 ,

d2 ≤ 10

,

d3 ≤ 5 ,

d4 ≤ 5

which will keep deviation from a goal within reasonable bounds; (b) in the objective function coefficients other than 1 may be used to indicate the relative importance of goals. For example the objective d1 + d2 + 10d3 + 10d4 may be considered appropriate if one can reason that a unit deviation in return is ten times as important as a unit deviation in “profit”. Goals can be constructed from either constraints or objective functions (unconstrained N type rows). If constraints are used, the goals are to minimize the violation of the constraints. These are met when the constraints are satisfied. In the pre-emptive case as many goals as possible are met in priority order. (It should be remembered that someone has to subjectively set weights to achieve this.) In the Archimedian case a weighted sum of penalties is minimized. If the goals are constructed from an objective function rows, then in the pre-emptive case a target for each objective function row is calculated from the optimal value for the objective function row (by percentage or absolute deviation). In the Archimedian case a multi-objective LP problem is obtained, in which a weighted sum of the objective functions is minimized. Let us illustrate how lexicographic goal programming works by considering the following example with two variables x and y subject to the constraint 42x + 13y ≤ 100 as well as the trivial bounds x ≥ 0 and y ≥ 0. We are given

296

B Mathematical Foundations of Optimization

name criterion type A/P goal 1 (OBJ1): 5x + 2y − 20 max P goal 2 (OBJ3): −3x + 15y − 48 min A goal 3 (OBJ2): 1.5x + 21y − 3.8 max P

∆ 10 4 20

.

The multi-criteria LP or MILP problem is converted to a sequence of LP or MILP problems. The basic idea is to work down the list of goals according to the priority list given. Thus we start by maximizing the LP w.r.t. the first goal. This gives us the objective function value z1∗ . Using this value z1∗ enables us to convert goal 1 into the constraint 5x + 2y − 20 ≥ Z1 = z1∗ −

10 ∗ z 100 1

.

(B.1)

Note how we have constructed the target Z1 for this goal (P indicates that we work percentage wise). In the example we have three goals with the optimization sense {max, min, max}. Two times we apply a percentage wise relaxation, one time absolute. Solving the new problem (B.1) we get: z1∗ = −4.615385

⇒

5x + 2y − 20 ≥ −4.615385 − 0.1 · (−4.615385) (B.2)

Now we minimize w.r.t. to goal 2 adding (B.2) as an additional constraint. We obtain: z2∗ = 51.133603

⇒

−3x + 15y − 48 ≥ 51.133603 + 4

(B.3)

Similar as the first goal, we now have to convert the second goal into a constraint (B.3) (here we allow a deviation of 4) and maximize according to goal 3. Finally, we get z3∗ = 141.943995 and the solution x = 0.238062 and y = 6.923186. To be complete, we could also convert the third goal into a constraint giving 1.5x + 21y − 3.8 ≥ 141.943995 − 0.2 · 141.943995 = 113.555196 Note that lexicographic goal programming based on objective functions provides a useful techniques to tackle multi-criteria optimization problems. However, we have to keep in mind that the sequence of the goals influences the solution strongly. Therefore, the absolute or percentage deviations have to be chosen with care. In addition to the lexicographic goal programming variant based on objective function we could also use lexicographic ordered constraints. The goals are to minimize the violation of constraints. The overall goal is to minimize the violation of constraints. In the ideals case all constraints are fulfilled. Otherwise, we try to fulfill the constraints ordered by priorities as good as possible. Unfortunately, this also leads to some sorts of weights. We thus summarize that the absolute or percentage-wise deviations used in lexicographic goal programming based on objectives are much easier to interpret.

C Glossary

The terms in this glossary are used in the text of the book and are defined here also for the purpose of subsequent reference. Within this glossary all terms written in boldface are explained in the glossary. Algorithm: Probably derived from the name of the Arabian mathematician al-Hwˆ arizmˆı, a systematic procedure for solving a certain problem. In mathematics and computer science it is required that this procedure can be described by a finite number of unique, deterministic steps. At each step of the algorithm it is uniquely determined by the previous steps how to proceed. ATP: Available to promise; the business process describing the confirmation of sales orders. In software systems usually a set of rules exist that allow the sales representative to respond to customer inquiries with a delivery date. Depending on the implementation and the software vendor, several variants exist: ATP looks at existing inventories and (planned) production orders, multi-level ATP considers rough-cut capacities and involves BOM explosion, and CTP (capable to promise) includes feasible scheduling of new production orders for fulfilling the new customer demand. Basic variables: Those variables in optimization problems whose values, in non-degenerate cases, are away from their bounds and are uniquely determined from a system of equations. Basis (Basic feasible solution): In an LP problem with constraints Ax = b and x ≥ 0 the set of m linearly independent columns of the m x n system matrix A of an LP problem with m constraints and n variables forming a regular matrix B. The vector xB = B −1 b is called a basic solution. xB is called a basic feasible solution if xB ≥ 0. Bill of Material (BOM): A list of components that are used in producing a material. In case the components are procured the BOM is called single-level, otherwise the BOM is multi-level.

298

C Glossary

Bound: Bounds on variables are special constraints. A bound involves only one variable and a constant which fixes the variable to that value, or serves as a lower or upper limit. Branch & Bound: An implicit enumeration algorithm for solving combinatorial problems. A general Branch & Bound algorithm for MILP problems operates by solving an LP relaxation of the original problem and then performing a systematic search for an optimal solution among sub-problems formed by branching on a variable which is not currently at an integer value to form a sub-problem, resolving the sub-problems in a similar manner. Branch & Cut: An algorithm for solving mixed integer linear programming problems which operates by solving a linear program which is a relaxation of the original problem and then performing a systematic search for an optimal solution by adjoining to the relaxation a series of valid constraints (cuts) which must be satisfied by the integer aspects of the problem to the relaxation, or to sub-problems generated from the relaxation, and resolving the problem or sub-problem in a similar manner. Constraint: A relationship that limits implicitly or explicitly the values of the variables in a model. Usually, constraints are formulated as inequalities or equations representing conditions imposed on a problem, but other types of relations exist, e.g., set membership relations. Continuous relaxation: An optimization problem where the requirements that certain variables take integer or discrete values have been removed. Convex region: A region in multi-dimensional space where a line segment joining any two points lying in the region remains completely in the space. CTM: Capable-to-match; a rules-based constraint propagation planning algorithm in SAP APO taking into account production capacity, transportation relations, quotas, and priorities for computing a feasible production plan. CTP: see ATP. Cutting-planes: Additional valid inequalities that are added to MILP problems to improve their LP relaxation when all variables are treated as continuous variables. Duality: A useful concept in optimization theory connecting the (primal) optimization problem and its dual. Duality gap: For feasible points of the primal and dual optimization problem the difference between the primal and dual objective function values. In LP the duality gap of the optimal solution is zero. Dual problem: An optimization problem closely related to the original problem which is called the primal problem. The dual of an LP problem is obtained by exchanging the objective function and the right-hand side constraint vector and transposing the constraint matrix. Dual values: A synonym for shadow prices. The dual values are the dual variables, i.e., the variables in the dual optimization problem. ERP: Enterprise Resource Planning systems are management information systems that integrate and automate many of the business practices associated with the operations or production aspects of a company.

C Glossary

299

Feasible point (feasible problem): A point (or vector) to an optimization problem that satisfies all constraints of the problem. (A problem for which at least one feasible point exists.) Global Optimum: A feasible point, x∗ , to an optimization problem that gives the optimal value of the objective function f (x). In a minimization problem, f (x) ≥ f (x∗ ) holds for all other points, x = x∗ , of the feasible region. Goal programming: A method of formulating a multi-objective optimization problem by expressing each objective as a goal or target with a hypothetical attainment level, modeled as a constraint, and using as the objective function an expression which will minimize deviation from goals. Heuristic solution: A feasible point of an optimization problem which is not necessarily optimal and has been found by a constructive technique which could not guarantee the optimality of the solution. Improvement method: A method able to generate and improve feasible points of an optimization problem with respect to some objective function. Improvement methods cannot prove optimality, do not provide safe bounds and are not able to prove that an optimization problem is infeasible. Infeasible problem: A problem for which no feasible point exists. Integrality gap: The difference between the objective function value of the continuous relaxation of an integer, mixed integer or discrete programming problem and its optimal objective function value. InfoCube: An InfoCube is an instance of a multi-dimensional data model within the SAP Business Information Warehouse (SAP BW, which is implicitly part of SAP APO). Technically, an InfoCube consists of a number of relational tables arranged according to the star scheme: a large fact table in the center is surrounded by several dimension tables. Kuhn-Tucker conditions: generalization of the necessary and sufficient conditions for steady points in nonlinear optimization problems involving equalities and inequalities. liveCache: a memory-resident relational database in SAP APO optimized for fast data-access. Linear combination: A linear combination of vectors v1 , ..., vn is the vector  i ai vi with real valued numbers ai . The trivial linear combination is generated by multiplying all vectors by zero and then adding them up, i.e., ai = 0 for all i. Linear function: A function f (x) of a vector x with constant gradient ∇f (x) = c. In that case f (x) is of the form f (x) = cT x + α for some fixed scalar α. Linear independence: A set of vectors is linearly independent if there exists no non-trivial linear combination representing the zero-vector. The trivial linear combination is the only linear combination which generates the zero vector. Linear Programming (LP): A technique to solve optimization problems containing only continuous variables appearing in linear constraints and in a linear objective function.

300

C Glossary

Local Optimum: A feasible point, x∗ , to an optimization problem that gives the optimal value of the objective function in the neighborhood of that point x∗ . In a minimization problem, we have for all other points of that neighborhood the relation f (x) ≥ f (x∗ ). Contrast with Global Optimum. Matrix: A rectangular array of elements such as symbols or numbers arranged in rows and columns. A matrix may have associated with it operations such as addition, subtraction or multiplication, if these are valid for the matrix elements. Mixed Integer Linear Programming (MILP): An extension to Linear Programming which allows the user to restrict variables to binary, integer, semi-continuous or partial-integer values. Mixed Integer Nonlinear Programming (MINLP): A technique to solve optimization problems which allow some of the variables to take on binary, integer, semi-continuous or partial-integer values, and allow nonlinear constraints and objective functions. Model (optimization model): A mathematical representation of a realworld problem using variables, constraints, objective functions and other mathematical objects. Modeling system: In the context of mathematical optimization a software system for formulating an optimization problem. The optimization problem can be formulated in an algebraic language, or can be represented by a visual model. The modeling system enables the user to bring together the structure of the problem and the data, to use various solvers, to trace the values of variables, constraints, shadow prices and infeasibilities, and to display Branchand-Bound trees. MRP: Material Requirements Planning; a software-based production planning and inventory control system used to manage manufacturing processes. MRP II: Manufacturing Resource Planning; a method for the effective planning of all resources of a manufacturing company. Ideally, it addresses operational planning in units, financial planning in dollars, and has a simulation capability to answer “what-if” questions. Defined by APICS,the Educational Society for Resource Management (http://www.apics.org/). Network: A representation of a problem as a series of points (nodes), some of which are then connected by lines or curves (arcs), which may or may not have a direction characteristic and a capacity characteristic. The network is usually represented by a graph. Non-basic variables: Those variables in optimization problems which are independently fixed to one of their bounds. Nonlinear function: Any function f (x) of a vector x which has a nonconstant gradient ∇f (x). Nonlinear Programming (NLP): Optimization problems containing only continuous variables and nonlinear constraints and objective functions. N P completeness: Characterization of how difficult it is to solve a certain class of optimization problems. The computational requirements increase exponentially with some measure of the problem size.

C Glossary

301

Objective (objective function): An expression in an optimization problem that has to be maximized or minimized. Optimization: The process of finding the best solution, according to some criterion, to an algebraic representation of a problem. Optimization algorithm: An algorithm which computes feasible points of optimization problems and proves that the best feasible point is globally optimal. For mixed integer problems, it is expected to compute feasible points and, for a minimization problem, a safe lower bound. The simplex algorithm and the Branch&Bound method are examples for optimization algorithms in MILP. Optimum (optimal solution): A feasible point of an optimization problem that cannot be improved on, in terms of the objective function, without violating the constraints of the problem. Pivot: An element in a matrix used to divide a set of other elements. In the context of solving systems of linear equations the pivot element is chosen with respect to numerical stability. In linear programming the pivot element is selected by pricing and the minimum ratio rule. In that context, the linear algebra step calculating, although not explicitly, the new basis inverse, is sometimes called the pivoting step. Planning (production planning): Determines which amount of a product should be produced on which facility in a certain time period or time bucket. Planning uses usually discrete-time formulations and covers a time horizon of several months or quarters. It contains less operational details than scheduling and is mostly based on material balance relations. Post-optimality (Post-optimal analysis): Investigation of the effect on the optimal solution of marginal changes in the problem’s coefficients. PPM: Production process model; along with the product data structure (PDS) this is the object that describes a production process including BOM information as well as the operations, activities and resources that are needed to make a certain product. Presolve: An algorithm for use on the specification of an optimization problem prior to its solution, whereby redundant features are removed and valid additional features may be added. Ranging: Investigation of the limits of changes in coefficients in an optimization problem which will not fundamentally affect the optimal solution. Reduced cost: The price (or the gain) for moving a non-basic variable away from the bound it is fixed to. Relaxation: An optimization problem created from another where some of the constraints have been removed or weakened, or where domain restrictions of some variables have been removed or weakened. Scaling: Reducing the variability in the size of the elements in a matrix (e.g., an LP matrix) by a series of row or column operations. Scheduling: Assigning, sequencing and timing of a set of tasks to a given set facilities. Scheduling requires much higher time resolution but is usually applied to only shorter time horizons than planning.

302

C Glossary

SCM: There are numerous definitions of supply chain management. In this book we use “coordinating material, information and financial flows in a company’s value chain including business partners such as suppliers, contract manufacturers, distributors, and customers”. Sensitivity analysis: The analysis of how an optimal solution of an optimization problem changes if some input data of the problem are slightly changed. Shadow price: The marginal change to the objective function value of an optimal solution of an optimization problem caused by making a marginal change to the right-hand side value of a constraint of the problem. Shadow prices are also termed dual values. Simplex algorithm: Algorithm for solving LP problems that investigates vertices of polyhedra. Slack variables: Variables with positive unit coefficients inserted into the left-hand side of ≤ inequalities to convert the inequalities into equalities. SNP: Supply network planning; the component of SAP APO focusing on mid-term planning on a somewhat aggregated level of detail regarding manufacturing processes. Planning takes place on time slices/buckets. Stochastic optimization: A technique to solve optimization problems in which some of the input data are random or subject to fluctuations. Successive Linear Programming (SLP): Algorithm for solving NLP problems containing a modest number of nonlinear terms in constraints and objective function. Surplus variables: Variables with negative unit coefficients inserted into the left-hand side of ≥ inequalities to convert the inequalities into equalities. Unbounded problem: A problem in which no optimal solution exists (the objective function tends to increase to plus infinity or to decrease to minus infinity) because the feasible region is not bounded. Variable: An algebraic object used to represent a decision or other varying quantity. Variables are also called “unknowns” or just “columns”. Vector: A single-row or single-column matrix.

List of Figures

1.1 1.2 1.3 1.4 1.5

The five management processes in the SCOR model . . . . . . . . . . 4 The supply chain planning matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 6 SAP covering the supply chain planning matrix . . . . . . . . . . . . . . 10 Schematic SAP APO optimizer architecture . . . . . . . . . . . . . . . . . 12 A sketch of the CTM Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27

The structure of the simple supply chain example . . . . . . . . . . . . Example supply chain structure displayed in SAP APO . . . . . . . Model creation in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning version creation in SAP APO . . . . . . . . . . . . . . . . . . . . . . SAP APO location maintenance screen . . . . . . . . . . . . . . . . . . . . . . SAP APO location product maintenance entry screen . . . . . . . . . SAP APO location product master, procurement view . . . . . . . . Maintaining version-dependent costs for a location product . . . . Maintaining version-dependent delivery penalties . . . . . . . . . . . . . Resource maintenance entry screen in SAP APO . . . . . . . . . . . . . Resource master data in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . Quantity/rate definitions for a bucket resource . . . . . . . . . . . . . . . Capacity variants of a bucket resource . . . . . . . . . . . . . . . . . . . . . . Schematic structure of a PPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The entry screen for maintaining PPMs . . . . . . . . . . . . . . . . . . . . . The PPM maintenance screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operations and activities view in the PPM . . . . . . . . . . . . . . . . . . The components view of a PPM activity . . . . . . . . . . . . . . . . . . . . The mode view of a PPM activity . . . . . . . . . . . . . . . . . . . . . . . . . . The resource view of a PPM mode . . . . . . . . . . . . . . . . . . . . . . . . . The product plan assignment table in PPM maintenance . . . . . . Activating the SNP PPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Supply Chain Engineer entry screen . . . . . . . . . . . . . . . . . . . . An empty work area in the Supply Chain Engineer . . . . . . . . . . . Adding objects to the model in the Supply Chain Engineer . . . . Master data objects in the supply chain model . . . . . . . . . . . . . . . Adding objects to a Supply Chain Engineer work area . . . . . . . .

43 44 52 53 54 56 56 57 58 59 60 61 62 62 63 64 64 65 65 66 67 68 70 71 71 71 72

304

List of Figures

3.28 3.29 3.30 3.31 3.32

The transportation lane entry screen in SAP APO . . . . . . . . . . . . Defining product-specific transportation lanes in SAP APO . . . . Defining means of transport in SAP APO . . . . . . . . . . . . . . . . . . . Defining product specific means of transport in SAP APO . . . . . The product independent transportation lane . . . . . . . . . . . . . . . .

73 73 74 76 77

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19

The structure of the simple supply chain example . . . . . . . . . . . . 80 Adding a new optimization profile . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Optimization profile maintenance in SAP APO . . . . . . . . . . . . . . . 82 Weighting the SNP cost types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Central optimizer cost maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 88 An example priority profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 An example time bucket profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 The SNP planning book setup for the example case . . . . . . . . . . . 92 Selecting all location products of planning version SIMPLE . . . . 93 The example demand pattern in the SNP planning book (1) . . . 94 The example demand pattern in the SNP planning book (2) . . . 94 The optimization entry screen in interactive SNP . . . . . . . . . . . . . 95 Cost overview after a successful optimization run . . . . . . . . . . . . . 96 The optimizer input log: transportation resource availability . . . 97 The optimizer result log: created planned orders by PPM . . . . . . 97 The optimizer result in the SNP planning book . . . . . . . . . . . . . . 98 The optimization profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Cost overview after the MILP run . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Planned orders in the discrete case . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.1 5.2 5.3

A schematic view of the semiconductor production process . . . . . 106 The different kinds of products in the supply chain (simplified) . 116 Internal and external processes in the semiconductor case . . . . . 117

6.1 6.2

The Carlsberg supply chain structure . . . . . . . . . . . . . . . . . . . . . . . 122 The production process at Carlsberg (simplified) . . . . . . . . . . . . . 123

7.1 7.2 7.3 7.4

Forecast-driven planning in the German automotive industry . . 127 Order-driven planning in the German automotive industry . . . . . 127 Planning levels in the chemical case . . . . . . . . . . . . . . . . . . . . . . . . . 135 Production layout in the chemical case . . . . . . . . . . . . . . . . . . . . . . 137

9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8

Starting a cartridge from within TP/VS . . . . . . . . . . . . . . . . . . . . . 213 Cartridge map with shipments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 Beverage supply chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 The warehouse with packaging lines and loading docks . . . . . . . . 220 Cartridge external architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Cartridge internal architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 The supply chain structure in the BASELL case . . . . . . . . . . . . . . 238 A schematic view of the BASELL planning process . . . . . . . . . . . 239

List of Tables

1.1

Real and penalty costs considered by SAP APO SNP . . . . . . . . . 19

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17

Raw material procurement costs in the supply chain example . . Location independent costs in the supply chain example . . . . . . . Resource capacities and capacity expansion costs . . . . . . . . . . . . . Production process data in the supply chain example . . . . . . . . . Transportation lanes in the example supply chain model . . . . . . . The locations in the example supply chain model . . . . . . . . . . . . . Location product data maintained version-independently . . . . . . Version-specific costs for the location products in the example . . Resources in the example supply chain model . . . . . . . . . . . . . . . . PPM header data in the example model . . . . . . . . . . . . . . . . . . . . . PPM component data in the example model . . . . . . . . . . . . . . . . . PPM resource capacity consumption data in the example . . . . . . Product plan assignment data in the example model . . . . . . . . . . Product specific transportation lanes in the example model . . . . Means of transport data - constrained transportation lane . . . . . Means of transport data - unconstrained transportation lane . . . Product-specific means of transport in the example . . . . . . . . . . .

4.1 4.2

Settings in the SNP optimizer profile . . . . . . . . . . . . . . . . . . . . . . . 83 Demand forecast in the supply chain example . . . . . . . . . . . . . . . . 93

6.1

Consumer product industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.1

Products, extruders and production conditions . . . . . . . . . . . . . . . 137

44 44 45 45 46 54 57 58 60 68 69 69 69 77 78 78 78

References

1. E. D. Andersen and K. D. Andersen. Presolving in Linear Programming. Mathematical Programming, 71:221–245, 1995. 2. E. D. Andersen and Y. Ye. Combining Interior-point and Pivoting Algorithms for Linear Programming. Technical report, Department of Management Sciences, The University of Iowa, Ames, Iowa, 1994. 3. R. Andrade, A. Lisser, N. Maculan, and G. Plateau. BB Strategies for Stochastic Integer Programming. 2005. in press. 4. H. Bartsch and P. Bickenbach. Supply Chain Management mit SAP APO. Galileo Press, Bonn, Deutschland, 2002. 5. A. Ben-Tal and A. Nemirovski. Robust Solutions of Linear Programming Problems Contaminated with Uncertain Data. Mathematical Programming, 88:411– 424, 2000. 6. G. Berning, M. Brandenburg, K. G¨ ursoy, V. Mehta, and F.-J. T¨ olle. An Integrated System Solution for Supply Chain Optimization in the Chemical Process Industry. OR Spectrum, 24(3):371–401, 2002. 7. J. R. Birge. Stochastic Programming Computation and Applications. INFORMS Journal on Computating, 9:111–133, 1997. 8. R. E. Burkhard. Methoden der Ganzzahligen Optimierung. Springer, Wien, New York, 1972. 9. A. Chakraborty, A. Malcom, R. D. Colberg, and A. A. Linninger. Optimal Waste Reduction and Investment Planning under Uncertainty. Computers and Chemical Engineering, 28:1145–1156, 2004. 10. A. Charnes and W. W. Cooper. Chance-constrained Programming. Management Science, 5:73–79, 1959. 11. L. Cheng, E. Subrahmanian, and A. W. Westerberg. Design and Planning under Uncertainty: Issues on Problem Formulation and Solution. Computers and Chemical Engineering, 27:781–801, 2003. 12. T. A. Ciriani, S. Gliozzi, E. L. Johnson, and R. Tadei, editors. Operational Research in Industry. Macmillan, Houndmills, Basingstoke, UK, 1999. 13. R. J. Dakin. A Tree Search Algorithm for Mixed Integer Programming Problems. Computer Journal, 8:250–255, 1965. 14. C. B. Dantzig. Linear Programming under Uncertainty. Management Science, 1:197–206, 1955.

308

References

15. G. B. Dantzig. Linear Programming and Extensions. Princeton University Press, Princeton, New Jersey, 1963. 16. G. M. De Beuckelaer. It’s Broken, Let’s Fix It - The Zeitgeist and Modern Enterprise. Springer, Berlin, Deutschland, 2001. 17. J. T. Dickersbach. Supply Chain Management with APO. Springer, Berlin, Deutschland, 2004. 18. E. D. Dolan, R. Fourer, J.-P. Goux, and T. S. Munson. Kestrel: An Interface from Modeling Systems to the NEOS Server. Technical report, Argonne National Laboratory, 2002. URL = http: www-neos.mcs.anl.gov/neos/ftp/kestrel2.pdf. 19. E. D. Dolan and T. S. Munson. The Kestrel Interface to the NEOS Server. Technical report, Argonne National Laboratory, 2002. URL = http: www-neos.mcs.anl.gov/neos/ftp/kestrel.pdf. 20. W. Domschke, A. Scholl, and S. Voß. Produktionsplanung. Springer, Heidelberg, 2nd edition, 1997. 21. M. A. Duran and I. E. Grossmann. An Outer-Approximation Algorithm for a Class of Mixed-Integer Nonlinear Programms. Mathematical Programming, 36:307–339, 1986. 22. C. A. Floudas. Nonlinear and Mixed Integer Optimization. Oxford University Press, Oxford, UK, 1995. 23. C. A. Floudas. Deterministic Global Optimization: Theory, Methods and Applications. Kluwer Academic Publishers, Dordrecht, Holland, 2000. 24. C. A. Floudas and X. Lin. Continuous-Time versus Discrete Time Approaches for Scheduling of Chemical Processes: A Review. Computers and Chemical Engineering, 28:2109–2129, 2004. 25. C. A. Floudas and X. Lin. Mixed Integer Linear Programming in Process Industry: Modeling, Algorithms, and Applications. Annals of Operations Research, 139(1):131–162, 2005. 26. R. Fourer and J.-P. Goux. Optimization as an Internet Resource. Interfaces, 31(2):130–150, 2001. 27. R. M. Freund and S. Mizuno. Interior Point Methods: Current Status and Future Directions. Optima (Mathematical Programming Society Newsletter), 51:1–9, 1996. 28. A. M. Geoffrion. Generalized Benders Decomposition. Journal of Optimization Theory and Applications, 10:237–260, 1972. 29. P. E. Gill, W. Murray, and M. H. Wright. Practical Optimization. Academic Press, London, 1981. 30. F. Glover and M. Laguna. Tabu Search. Kluwer Academic Publisher, Dordrecht, The Netherlands, 1997. 31. J. Gottlieb and C. Eckert. Solving Real-World Vehicle Scheduling and Routing Problems. International Scientific Annual Conference Operations Research 2005, Bremen, Germany, Sept. 2005. 32. M. Gr¨ otschel. Mathematische Optimierung im industriellen Einsatz. Lecture at Siemens AG, Munich, Germany, Dec 07, 2004. 33. M. Gr¨ otschel. private communication, 2005. 34. A. Gupta and C. D. Maranas. Managing Demand Uncertainty in Supply Chain Planning. Computers and Chemical Engineering, 27:1219–1227, 2003. 35. O. K. Gupta and V. Ravindran. Branch and Bound Experiments in Convex Nonlinear Integer Programming. Management Science, 31:1533–1546, 1985.

References

309

36. P. M. J. Harris. Pivot Selection Methods of the Devex LP Code. Mathematical Programming, 5:1–28, 1973. 37. R. Horst and P. M. Pardalos, editors. Handbook of Global Optimization. Kluwer Academic Publishers, Dordrecht, Holland, 1995. 38. R. Horst, P. M. Pardalos, and N. V. Thoai. Introduction to Global Optimization. Kluwer Academic Publishers, Dordrecht, Holland, 1996. 39. M. G. Ierapetriou and C. A. Floudas. Effective Continuous-Time Formulation for Short-Term Scheduling. 1. Multipurpose Batch Processes. Industrial and Engineering Chemistry Research, 37:4341–4359, 1998. 40. M. G. Ierapetriou and C. A. Floudas. Effective Continuous-Time Formulation for Short-Term Scheduling. 2. Continuous and Semicontinuous Processes. Industrial and Engineering Chemistry Research, 37:4360–4374, 1998. 41. M. G. Ierapetriou, T. S. Hene, and C. A. Floudas. Continuous Time Formulation for Short-Term Scheduling with Multiple Intermediate Due Dates. Industrial and Engineering Chemistry Research, 38:3446–3461, 1999. 42. J. P. Ignizio. Goal Programming and Extensions. Heath, Lexington, Massachusetts, USA, 1976. 43. S. L. Janak, C. A. Floudas, J. Kallrath, and N. Vormbrock. Production Scheduling of a Large-Scale Industrial Batch Plant: I. Short-Term and MediumTerm Scheduling. Industrial and Engineering Chemistry Research, in print, 2006a. 44. S. L. Janak, C. A. Floudas, J. Kallrath, and N. Vormbrock. Production Scheduling of a Large-Scale Industrial Batch Plant: II. Reactive Scheduling. Industrial and Engineering Chemistry Research, in print, 2006b. 45. S. L. Janak, X. Lin, and C. A. Floudas. Enhanced Continuous-Time UnitSpecific Event-Based Formulation for Short-Term Scheduling of Multipurpose Batch Processes: Resource Constraints and Mixed Storage Policies. Ind. Chem. Eng. Res., 43:2516–2533, 2004. 46. Z. Jia and M. Ierapetritou. Efficient Short-term Scheduling of Refinery Operations based on a Continuous Time Formulation. Computers and Chemical Engineering, 28:1001–1019, 2004. 47. E. L. Johnson, M. M. Kostreva, and U. H. Suhl. Solving 0-1 Integer Programming Problems arising from Large Scale Planning Models. Operations Research, 33:803–819, 1985. 48. P. Kall. Stochastic Linear Programming. Springer, Berlin, 1976. 49. J. Kallrath. The Concept of Contiguity in Models Based on Time-Indexed Formulations. In F. Keil, W. Mackens, H. Voss, and J. Werther, editors, Scientific Computing in Chemical Engineering II, pages 330–337. Berlin, 1999. 50. J. Kallrath. Combined Strategic and Operational Planning - An MILP Success Story in Chemical Industry. OR Spectrum, 24(3):315–341, 2002. 51. J. Kallrath. Gemischt-Ganzzahlige Optimierung: Modellierung in der Praxis. Vieweg, Wiesbaden, Germany, 2002. 52. J. Kallrath. Planning and Scheduling in the Process Industry. OR Spectrum, 24(3):219–250, 2002. 53. J. Kallrath. Modeling Languages in Mathematical Optimization. Kluwer Academic Publisher, Dordrecht, The Netherlands, 2004. 54. J. Kallrath. Solving Planning and Design Problems in the Process Industry Using Mixed Integer and Global Optimization. Annals of Operations Research, 140:339–373, 2005.

310

References

55. J. Kallrath and J. M. Wilson. Business Optimisation Using Mathematical Programming. Macmillan, Houndmills, Basingstoke, UK, 423 pages, 1997. 56. N. Karmarkar. A new polynomial time algorithm for linear programming. Combinatorica, 4:375–395, 1984. 57. W. Karush. Minima of Functions of Several Variables with Inequalities as Side Constraints. Master thesis, Department of Mathematics, University of Chicago, Chicago, 1939. 58. R. B. Kearfott. Rigorous Global Search: Continuous Problems. Kluwer Academic Publishers, Dordrecht, The Netherlands, 1996. 59. W. K. Klein-Haneveld and M. H. van der Vlerk. Stochastic Integer Programming: General Models and Algorithms. Annals of Operational Research, 85:39– 57, 1999. 60. E. Kondili, C. C. Pantelides, and R. W. H. Sargent. A General Algorithm for Short-Term Scheduling of Batch Operations - I. MILP Formulation. Computers and Chemical Engineering, 17:211–227, 1993. 61. S. Kreipl and M. Pinedo. Planning and Scheduling in Supply Chains: An Overview of Issues in Practice. Production and Operations Management, 13(1):77–92, 2004. 62. H. W. Kuhn and A. W. Tucker. Nonlinear Programming. In J. Neumann, editor, Proceedings Second Berkeley Symposium on Mathematical Statistics and Probability, pages 481–492, Berkeley, CA, 1951. University of California. 63. R. Kuik, M. Solomon, and L. N. van Wassenhove. Batching Decisions: Structure and Models. European Journal of Operational Research, 75:243–263, 1994. 64. A. H. Land and A. G. Doig. An Automatic Method for Solving Discrete Programming Problems. Econometrica, 28:497–520, 1960. 65. Y. M. Lee and T. I. Maindl. A Web-Based Chemical Formulation Optimization Tool. Lecture at the INFORMS 1998 Fall Meeting, Paper SA04-2, 1998. 66. X. Lin and C. A. Floudas. Design, Synthesis and Scheduling of Multipurpose Batch Plants via an Effective Continuous-Time Formulation. Computers and Chemical Engineering, 25:665–674, 2001. 67. X. Lin, C. A. Floudas, S. Modi, and N. M. Juhasz. Continuous-Time Production Scheduling of a Multiproduct Batch Plant. Industrial and Engineering Chemistry Research, im Druck, 2002. 68. P. McMullen. The Maximum Number of Faces of Convex Polytopes. Mathematika, 17:179–184, 1970. 69. S. P. Meyn. Stability, Performance Evaluation, and Optimization. In Handbook of Markov Decision Processes, volume 40 of Internat. Ser. Oper. Res. Management Sci., pages 305–346. Kluwer Acad. Publ., Boston, MA, 2002. 70. H. Meyr. Supply Chain Planning in the German Automotive Industry. OR Spectrum, 26/4:447–470, 2004. 71. G. E. Moore. Cramming more Components onto Integrated Circuits. Electronics, 38(8):114–117, 1965. 72. B. A. Murtagh and M. A. Saunders. Large-scale Linearly Constrained Optimization. Mathematical Programming, 14:41–72, 1978. 73. G. L. Nemhauser and L. A. Wolsey. Integer and Combinatorial Optimization. John Wiley and Sons, New York, 1988. 74. Newspaper Article. SAP schickt mySAP SCM 5.0 an erste Kunden. Computerwoche, 42:24, Oct 21, 2005.

References

311

75. R. K. Oliver and M. D. Webber. Supply-chain Management: Logistics Catches up with Strategy. In M. Christopher, editor, Logistics – The Strategic Issues, pages 63–75. Springer, Berlin, Deutschland (reprint of OUTLOOK 1982), 1992. 76. M. Padberg. Linear Optimization and Extensions. Springer, Berlin - Heidelberg, 1996. 77. M. L. Pinedo. Planning and Scheduling in Manufacturing and Services. Springer, New York, 2005. 78. A. Pr´ekopa. Stochastic Programming. Kluwer Academic Publishers, Dordrecht, The Netherlands, 1995. 79. J. Rohde, H. Meyr, and M. Wagner. Die Supply Chain Planning Matrix. PPSManagement, 5(1):10–15, 2000. 80. C. Romero. Handbook of Critical Issues in Goal Programming. Pergamon Press, Oxford, 1991. 81. H. Rommelfanger. Fuzzy Decision Support-Systeme - Entscheiden bei Unsch¨ arfe. Springer, Heidelberg, 2nd edition, 1993. 82. A. Ruszczy´ nski and A. Shapiro. Stochastic Programming, volume 10 of Handbooks in Operations Research and Management Science. Elsevier, NorthHolland, 2003. 83. M. W. P. Savelsbergh. Preprocessing and Probing Techniques for Mixed Integer Programming Problems. ORSA Journal on Computing, 6:445–454, 1994. 84. R. Scheckenbach and A. Zeier. Collaborative SCM in Branchen. Galileo Press, Bonn, Deutschland, 2003. 85. M. J. Schniederjans. Goal Programming: Methodology and Applications. Kluwer Academic Publishers, Boston, MA, 1995. 86. R. Schultz. Stochastic Programming with Integer Variables. Mathematical Programming Ser. B, 97:285–309, 2003. 87. S. Sen and J. L. Higle. An Introductory Tutorial on Stochastic Linear Programming Models. Interfaces, 29(2):33–61, 1999. 88. P. Spelluci. Numerische Verfahren der nichtlinearen Optimierung. Birkh¨ auser, Basel, 1993. 89. H. Stadtler. Linear and Mixed Integer Programming. In H. Stadtler and C. Kilger, editors, Supply Chain Management and Advanced Planning, pages 335–344. Springer, Berlin, Deutschland, 2000. 90. H. Stadtler. Supply Chain Management – An Overview. In H. Stadtler and C. Kilger, editors, Supply Chain Management and Advanced Planning, pages 7–28. Springer, Berlin, Deutschland, 2000. 91. H. Stadtler. Supply Chain Management and Advanced Planning. Talk at EURO/INFORMS 2003, Istanbul, Turkey, July 2003. 92. H. Stadtler and C. Kilger, editors. Supply Chain Management and Advanced Planning. Springer, Berlin, 3rd edition, 2004. 93. C. Suerie. Time Continuity in Discrete Time Models - New Approaches for Production Planning in Process Industries, volume 552 of Lecture Notes in Economics and Mathematical Systems. Springer, Heidelberg, Germany, 2005. 94. Supply-Chain Council. Supply-Chain Operations Reference-model – SCOR Version 7.0 Overview. Technical report, Supply-Chain Council, 1400 Eye Street, NW, Suite 1050, Washington DC, 20005, USA, 2005. www.supplychain.org. 95. M. Tawarmalani and N. V. Sahinidis. Convexification and Global Optimization in Continuous and Mixed-Integer Nonlinear Programming: Theory, Algorithms, Software, and Applications, volume 65 of Nonconvex Optimization And

312

96.

97. 98.

99. 100. 101. 102. 103. 104.

References Its Applications. Kluwer Academic Publishers, Dordrecht, The Netherlands, 2002. H. Tempelmeier. Supply Chain Planning with Advanced Planning Systems. In Proceedings of the 3rd Aegean International Conference on Design and Analysis of Manufacturing Systems, Tinos Island, Greece, May 19–22, 2001. R. J. Vanderbei. Linear Programming - Foundations and Extensions. Kluwer, Dordrecht, The Netherlands, 1996. J. Viswanathan and I. E. Grossmann. A Combined Penalty Function and Outer-Approximation Method for MINLP Optimization. Comp. Chem. Eng., 14(7):769–782, 1990. S. W. Wallace. Decision Making Under Uncertainty: Is Sensitivity Analysis of any Use? Operations Research, 48:20–25, 2000. H. P. Williams. Model Building in Mathematical Programming. John Wiley and Sons, Chichester, 3rd edition, 1993. L. A. Wolsey. Integer Programming. Wiley, New York, US, 1998. H. J. Zimmermann. Fuzzy Set Theory and its Applications. Kluwer Academic Publishers, Boston, MA, 2nd edition, 1987. H. J. Zimmermann. Fuzzy Sets, Decision Making, and Expert Systems. Kluwer Academic Publishers, Boston, MA, 1987. H.-J. Zimmermann. An Application-Oriented View of Modeling Uncertainty. European Journal of Operations Research, 122:190–198, 2000.

About the Authors

Dr. Josef Kallrath has built his reputation as an outstanding modeler of real world optimization problems through extensive experience in Europe, the USA, and Asia. He solves industry problems with a broad spectrum of scientific computing methods that range from physical modeling to decision process support, as well as production planning and scheduling by mathematical optimization. He is a recognized expert in modeling/optimization, and a teacher, writer, and consultant. In addition to years of industrial experience, he has taught graduate courses in mathematical modeling at Heidelberg University. He is also expert in eclipsing binary analysis and teaches graduate and undergraduate courses in astronomy and applied mathematics at the University of Florida (Gainesville, FL). He leads the working group Praxis der mathematischen Optimierung of the Gesellschaft f¨ ur Operations Research, the OR society of the German speaking world. He runs numerous seminars and workshops on real world optimization and holds a diploma in physics and a doctorate in Astronomy from Bonn University (Germany) and a professorship of the University of Florida. He has written reviews on mixed integer optimization and on planning and scheduling of real world problems, in addition to about 70 research papers in astronomy, applied mathematics, and industrial optimization. He is author of two books on mixed integer optimizing, one on modeling languages in mathematical optimization, and one on eclipsing binary stars. Dr. Thomas I. Maindl deals with strategic research and development topics related to supply chain management and applies mathematical modeling and optimization to real world problems including, but not limited to, supply chain management. His experience is drawn from projects in Europe, the USA, and Asia on supply chain planning and scheduling, distribution network design, delivering web-based formulation optimization, schedule optimization, medical cancer diagnosis, analyzing the stability of dynamical systems, and applying the theory of general relativity to satellite orbits and includes several years of working for a global chemical company in the USA. Dr. Maindl holds a master’s and a doctorate degree in Astronomy from the University of Vienna

314

About the Authors

(Austria). He has written several research papers in astronomy, theory of general relativity, mathematical modeling, and web-based optimization and has been teaching undergraduate and graduate courses in astronomy and celestial mechanics at the University of Vienna, undergraduate courses in business informatics at the University of Applied Sciences in Darmstadt, and teaches graduate courses in supply chain planning with advanced planning systems at the University of Cologne.

Index

A abbreviations XXV absolute value function 31 acceptance 141, 142, 206, 263 activities 26 addcut 290 advanced planning 3 advanced planning system see APS algorithm 297 Branch and Bound 290 enumeration 298 evolutionary 11, 24, 124, 138, 275 exponential time 278 genetic 24 homotopy 288 optimization 23 polynomial time 278 rule-based 8 allocation problem 26 alternative solutions 281 APO see SAP APO advanced planning system 9 APS XXV, 6, 8, 9, 243 Archimedian approach 36, 294 arithmetic tests 294 ATP XXV, 7, 109, 117, 274, 276, 297 automotive industry 125 Available-to-Promise see ATP axentiv 125

B BAPI XXV, 212 basic feasible point 279

basic feasible solution 279 basis 279, 294, 297 re-inversion of the 282 batch constraints 167, 168 batch production 167 big M method 283, 284 bill of material XXV, 14, 55, 61, 239, 297 BOM see bill of material bounds 283, 287, 289, 290, 298 treatment of 284 upper 285 Branch and Bound 290, 298 Branch and Cut 298 branching 290 generalized upper bound 290 on a variable 291 breadth-first strategy 291 Business Application Programming Interface see BAPI

C calendar information 140 campaign 83, 85, 167 campaign constraints 168 campaign production 167 Capable-to-Match see CTM Capable-to-Promise see CTP capacity 122, 239 capacity planning 4, 109, 115 case period 151 central path 289 CIF XXV, 9, 53, 117, 220

316

Index

class A customer 180 client 31 clique 294 co-production 18, 156, 196, 199, 201 co-products 64, 162, 163 column generation 277 columns 26, 279, 300 complexity 255 concave 83 constraint programming see CP constraints 25, 30, 239, 240, 298 disaggregation of 294 in SAP APO see SNP optimizer in the example model 43 mode-capacity 160 constructive heuristics 24 continuous-time formulations 256, 267 contract manufacturing 13 contribution margin 18, 57, 84 conventions XXV convex 83, 298 Core Interface see CIF cost 123, 239, 240 concave 83 convex 83 delay 184 duty 179 external purchase 184, 186, 197 in SAP APO see SNP optimizer in the example model 43 inventory 183 mode changing 183 product purchase 182 rented inventory 183 total variable 184 transport 178, 179, 183, 239 utilities 182 variable production 182 CP XXV, 10, 25, 34, 38, 138, 267, 275 crash 283, 284 cross-over 289 CTM XXV, 16, 105, 108, 111, 116, 298 strategies 17, 112 CTP XXV, 7, 276, 298 currency unit XXV cuts 298 cutting stock problem 26, 260 cutting-planes 298 cycle time 108

D Dash optimization 143 data 25 consistency checks 238, 240, 265 data consistency checker 39 decision variables 26 decomposition 20, 84, 89, 124, 130, 132, 139, 222, 267, 268 priority 84 product 89 time 20 degeneracy 281 demand forecast 38 rolling 237, 239 demand forecasting see demand planning demand planning XXV, 5, 7, 135, 274 depot location 26 depth-first strategy 290 detailed scheduling 4 discrete-time formulations 167, 168, 301 distribution and transportation planning 8 documentation 34 SAP APO 41 domain 27 of a variable 290 relaxation 29 DP see demand planning dual degeneracy 281 dual problem 298 dual value 282, 298 duality gap 289, 298 duty cost 179

E edge-following algorithm 280 elementary row operations 281 Enterprise Resource Planning see ERP ERP XXV, 243, 298 eta-factors 282 evolutionary algorithms see algorithm evolutionary strategies 34 example planning horizon 152 supply chain model 42, 79 Explanation Tool 270, 275 external purchase 181

Index

F feasible point 23, 24, 33–35, 256, 258–260, 299 feasible problem 299 fixed setup plans 158 forced demand table 180 functions linear 299 nonlinear 300 fuzzy set 37

G gap see integrality gap duality 289 genetic algorithm 24 goals 35, 138 graphical user interface see GUI GUI XXV, 41, 51, 141, 142, 207, 208, 211–214, 216, 220, 221, 223–229, 232–234

317

integration SAP APO with SAP R/3 53 SNP optimizer with PP/DS 85 with SAP R/3 and SAP APO 238 interchangeability of products 13 interior-point methods 18, 278, 284, 287–289 inventory capacity 171 demand point 171 end of planning horizon 170 initial stock 171, 239 rented 173, 183 requirements 112, 114, 237, 244 safety stock 124, 172 site 169 IP XXV, 290

K Kuhn-Tucker conditions 288, 299

H

L

heuristics 15, 35 constructive 24 homotopy parameter 287 hybrid methods 284

Lagrangian function 288 lexicographic approach 294 Lexicographic Goal Programming 36 linear combination 299 linear independence 299 Linear Programming see LP liveCache 14, 275, 276, 299 location 53 location product 13, 55, 90 logarithmic barrier method 288 lot size 122, 237 in SAP APO see SNP optimizer lot sizing 154 LP XXV, 25, 30, 33, 81, 124, 130, 279, 291, 299 LU factorization 282

I i2 Technologies 40, 105 ILOG 206, 207 cartridge 206, 208, 209, 211–213, 220, 221, 223, 231 ODF (optimization development framework) 206, 212–214, 221, 223, 225–228, 233, 234, 236 implicit enumeration 290 improvement methods 24, 256, 260, 299 in-transit shipment 169 independent infeasible sets 193 index sets 27, 28 infeasibilities 194 diagnosing 193 InfoCube 14, 275, 299 initial feasible basis 283 initial solution 283 Integer Programming see IP integrality gap 189, 291, 292, 299 relative 291 scaling of penality terms 292, 293

M maintenance 157 Markov processes 38 mass loss during transport 170 master data 13, 41 in the example model 51 location see location location product see location product PDS see PDS PPM see PPM

318

Index

product see location product production data structure see PDS production process model see PPM resource see resource transportation lane see transportation lane master planning 5, 7, 8, 109, 115, 125, 126 Material Requirements Planning see MRP matrix 277, 279–282, 289, 297, 298, 300 matrix generation 194 maximin 32 metaheuristics 24, 34 simulated annealing 34 tabu search 34 MILP XXV, 25, 30, 32, 33, 81, 84, 98, 123, 124, 238, 246, 290, 300 rounding 189 minimax 32 minimum ratio rule 285 MINLP XXV, 25, 33, 33, 300 MIP XXV MIQP XXV, 33 Mixed Integer Linear Programming see MILP Mixed Integer Nonlinear Programming see MINLP Mixed Integer Programming see MIP Mixed Integer Quadratic Programming see MIQP mode changes 154, 155, 158 sequence-dependent 155 model 300 predefined 21–23, 25, 39, 40, 50, 254, 266, 268, 269 purpose of a 257 model and version management 52 modeling 21 modeling language 39, 40, 143 mp-model 143 OPL Studio 126 Xpress-MP 143 modeling system 39, 40, 300 models in TriMatrix 247 mathematical 22, 238 mechanical 22 purpose of 22

modes 153 MRP XXV, 6–10, 235, 300 MRP II 300 multi-criteria objectives 187 multi-criteria problems 35 mySAP SCM 5.0 270

N net present value 153 network design 5, 26 network flow problem 300 neural networks 34 Newton-Raphson algorithm 288 NLP XXV, 25, 33, 300 node selection see selection Nonlinear Programming see NLP NP complete 293, 300 NP hard 293

O objective function 25, 31, 301 choice of 181 degeneracy of the 185, 188 in SAP APO see SNP optimizer ODBC XXV Operations Research XXV optimization 241, 243, 301 ... and SAP APO 39 algorithm 301 chance constrained 37 definition 23 definition (colloquial) 23 multi-stage stochastic 37 portfolio 269 robust 37 stochastic 37, 302 under uncertainty 36 versus simulation 35 optimization algorithm (definition) 23 optimum global 299 local 300 order-based planning 16

P parameter study 35 Pareto optimal 35 PDS XXV, 14, 51 pegging 16, 112, 114

Index dynamic 16 fixed 16 penalty costs in SAP APO see SNP optimizer performance 33, 124 phase I and phase II 283 piecewise linear approximation 83 pivot 301 pivoting 280 planning 301 allocation 126 budget 126 capacity see capacity planning demand 7 hierarchical 199, 204, 273, 274 master see master planning mid-range 128, 131, 134 network 5 operational 274 order-based 16, 134 order-driven 125, 126, 131, 134 production see production planning sales 126 short-term 136 strategic 5, 126, 131, 274 tactical 5, 274 transportation see transportation planning under uncertainty 268 planning horizon 85, 151, 152 planning version 52 active 53 version-dependent data 55–57 portfolio optimization 26 post-optimal analysis 85, 301 PP/DS XXV, 10, 85, 274, 275 PPM XXVI, 14, 51, 90, 98, 301 creating in SAP APO 61 plan 62, 67 preprocessing 139, 228, 246, 249, 293 presolve 293, 294, 301 pricing 281, 301 devex 280 partial 280 priorities 36, 291, 294, 295 problem allocation 26 blending 26 cutting stock 26, 260

319

degenerate 280 infeasible 284, 299 sequencing 26 unbounded 302 procurement type 56 product in SAP APO see location product lifecycle 105 production 163 capacity 163, 237 minimum requirements 164, 166 multi-stage 157 rates 157 total on reactor 166 production data structure see PDS production planning 4, 5, 8, 10 Production Planning and Detailed Scheduling see PP/DS production planning and scheduling 7 production process model see PPM programming chance constrained 37 goal 268, 294, 299 linear see LP mixed integer linear see MILP mixed integer nonlinear see MINLP nonlinear see NLP stochastic 37, 38 successive linear 302

Q QP XXVI, 33 Quadratic Programming see QP

R ranging 28, 301 raw material availability 162 raw material pricing nonlinear 182 reactor Last-in-Chain 155 subject to design decisions 162 topology 162, 194 real-world problems 34, 248 reduced costs 39, 301 relaxation 124, 241, 301 continuous 298 of domain 29 relaxation of constraints 194, 195

320

Index

reporting 242 resource 13, 59 capacity 60, 61 types in SNP 59 resource utilization 129 restrictions see constraints Result Indicators 270 revenue 182 rounding 130, 190 routing 55 rules 262, 263

S sales forecast see demand forecast SAP APO XXVI, 243 ... and modeling 269 APX (optimization extension workbench) 208, 215, 224, 225 components 9, 10, 273, 274 PP/DS (production planning/ detailed scheduling) see PP/DS SNP (supply network planning) see SNP TP/VS (transportation planning / vehicle scheduling) 11, 205, 274, 276 definition 9 documentation 41 model 52 active 53 optimizer see SNP optimizer planning version see planning version release 10, 13, 16, 51, 53, 115, 138, 199, 203, 209, 215, 218, 222, 239, 276 release 5.0 275 transaction 51 SAP R/3 115, 117, 219, 243 release 239 scale-up 40 scaling 284, 293, 301 scheduling 8, 10, 15, 17, 25, 32, 34, 38, 253–256, 259, 261, 262, 265, 267, 275, 276, 293, 297, 301 backward 112 detailed 4, 7, 10, 14, 108, 121, 124, 134–136, 138, 273 finite 11, 39 forward 112, 114

in the chemical industry 125 in the process industry 267 rules in ... 262 short 121 under uncertainty 268 vehicle 273 SCM X, XI, XXVI, 3, 108, 113, 120, 121, 125, 302 SCOR model 4 SCP matrix 6, 8, 9 selection of branching variable 291 of node 290, 292 semi-continuous variables see variables semiconductor manufacturing 105, 106 Moores law 107 supply chain modeling 110 supply chain planning 108 sensitivity analysis 37, 258, 261, 302 sequence-dependent mode changes 146 sequence-dependent setup time 146 sequencing 26, 242, 245, 246 service level 121 setup matrix 196, 199 shadow price 39, 283, 302 shelf-life 56, 119, 147, 197 shutdowns 157, 237, 240 simplex algorithm 277, 278, 280, 282, 285, 289, 302 dual 18, 82, 84, 286, 287 primal 18, 82, 84, 286, 287 simulation 35, 37, 52, 53, 300 SNP XXVI, 10, 12, 242, 244, 247, 274, 275, 302 CTM see CTM heuristics 15 optimization see SNP optimizer optimizer 205 planning book 86, 91, 97 key figure 92, 94 planning horizon 85 planning methods 15 SNP optimizer 18, 39, 113, 124, 209, 211, 218, 220 aggregation 84 constraints 19, 76, 82, 85, 87, 98 costs 19, 57, 63, 68, 83, 86, 99 maintaining 86 customizing 89

Index decomposition 20, 84, 89 demand categories 84, 93 incremental optimization 85 logs 86, 95, 96 lot sizes 82, 88, 90, 99 model 42, 247 adding objects 69 consistency check 86, 95 objective function 18, 84, 244 penalty costs 57, 87 planning run 95, 98, 124 profiles 80–91, 95, 98 software CPLEX 8, 39, 105, 114, 126, 139, 207, 208, 221, 268, 287 Mosel 238 TriMatrix 246–249 Xpress-MP XV, 8, 39, 114, 143, 166, 189, 238, 268, 287 solution heuristic 299 number of 279 optimal 301 solver 143 CPLEX 8, 39, 105, 114, 126, 139, 207, 208, 221, 268, 287 mp-opt 143 Xpress-MP XV, 8, 39, 114, 143, 166, 189, 238, 268, 287 sparsity 282, 287, 289 stock see inventory storage sites 146 strategic network planning 7 supply chain example model 42 master data 51 execution 5 operations 5 planning 5 Supply Chain Engineer 43, 69, 70, 77 supply chain management see SCM supply chain model 41, 79 supply chain planning matrix 6, 273 Supply Network Planning see SNP Supply-Chain Council 4

T targets 35, 36, 294, 295, 299 termination criterion 289, 291 time bucket 14, 60, 67, 75, 83–85, 87, 90, 91, 93, 98, 109, 123, 124, 197, 199–202, 274, 275, 301, 302

321

see also time slice 27 time period 301 see also time bucket 27, 248 time slice 144, 147, 151–153, 168, 177, 199, 201, 302 commercial 178 see also time bucket 27 transaction 51 transport 176 transport mean 176, 179 transport time 179 transportation lane 72, 88, 90 transportation planning 5, 8 routing 5 TriMatrix 247–249 two-phase method 283, 284

U user interface 131, 238, 240 utilization rate 146, 147, 164–166, 195, 200

V variables 25, 302 artificial 283 basic 279–283, 297 binary 29, 31, 83, 155, 158–161, 168, 173, 176, 179 continuous 29 discrete 30, 32 external purchase 155, 156 free 30, 295 integer 29, 168, 189 mode-duration 154, 160, 161 non-basic 279–281, 283, 300 partial integer 30 production 154 semi-continuous 29, 155, 156, 163, 165, 166, 168, 177, 202 semi-integer 30 slack 284, 302 state 155, 157 stock 155, 173 surplus 284, 302 transport 155, 177, 178 unconstrained 30 vector 302 vector minimization 35 vehicle routing 4, 206