Real Optimization with SAP® APO

Josef KallrathThomas I. Maindl

Real Optimizationwith SAP® APO

With 73 Figuresand 30 Tables

123

Professor Dr. Josef Kallrath

E-mail: josef.kallrath@web.de

Dr. Thomas I. Maindl

E-mail: thomas.maindl@web.de

Cataloging-in-Publication Data

Library of Congress Control Number: 2006923242

ISBN-10 3-540-22561-7 Springer Berlin Heidelberg New YorkISBN-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 orparts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, inits current version, and permission for use must always be obtained from Springer-Verlag.Violations are liablefor prosecution under the German Copyright Law.

Springer is a part of Springer Science+Business Mediaspringeronline.com

© Springer-Verlag Berlin Heidelberg 2006Printed 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 andregulations and therefore free for general use.

Cover design: design & production GmbHProduction: Helmut PetriPrinting: Strauss Offsetdruck

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

Trademarks

“SAP” and mySAP.com are trademarks of SAP Aktiengesellschaft, Systems, Applications and Products in DataProcessing, Dietmar-Hopp-Allee 16, D-69190 Walldorf, Germany. The publisher gratefully acknowledges SAP’skind permission to use its trademark in this publication. SAP AG is not the publisher of this book and is notresponsible 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 registeredtrademarks 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.

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 theauthors point out how relatively young even the word “model” is. On top ofthat, the concept is rather elusive. How to deal with a technology that findsapplications in things as different as logistics, robotics, circuit layout, financialdeals and traffic control?

Although, during the last decades, we made significant progress, the broadpublic remained largely unaware of that. The days of John von Neumann,with his vast halls full of people frantically working mechanical calculatorsare long gone. Things that looked completely impossible in my youth, likesolving mixed integer problems are routine by now. All that was not justachieved by ever faster and cheaper computers, but also by serious progressin mathematics. But even in a world that more and more understands thatit cannot afford to waste resources, optimization remains to a large extentunknown.

It is quite logical and also fortunate that SAP R©, the leading supplier ofenterprise management systems has embedded an optimizer in his software.The authors have very carefully investigated the capabilities and the limits ofAPO. Remember that optimization is still a work in progress. We do not havethe tool that does everything for everybody. Some sales people will claim tohave such a miracle weapon every once in a while, out of enthusiasm so blindthat it turned into ignorance. But the serious technicians among us all knowthat such a thing does not exist, and never will.

For the creators of APO, I have the following advice. Do not get offendedby the fact that the authors discovered deficiencies. In some cases you willbe inspired to remove the weak points. In other cases you may decide not toaddress 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 alreadygood product.

Also for the users this book is a very important help. It is essential tounderstand 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 optimiza-tion. Without good solid information about the capabilities of your tool youare more likely to break something than to make something.

To those that would be disappointed by the fact that APO is not every-thing for everybody, I can only say in German: “Eine eierlegende Wollmilchsaubringt außer Bellen meistens nichts zustande!”

January 2006 Gerard De BeuckelaerMember of the BoardDirector of Strategic DevelopmentUTI SN, Bucharest, Romania

Preface

This book describes and demonstrates how SAP R© APO can be used to tackle“real” optimization problems arising in industry and focuses on optimization1

based on mixed integer linear programming (MILP). In a unique combinationit deals with the aspects of model-building and solving algorithms as well aswith the implementation in commercial supply chain management software,SAP APO being a typical example of an advanced planning system (APS).

As many enterprises have implemented SAP R© software for Enterprise Re-source Planning (ERP) in a global scale successfully we feel that a logicalextension of this backbone is to be seen in optimization for procurement, pro-duction and distribution. Decision makers become more and more convincedof the benefits of using optimization techniques and to formulate and imple-ment models that address the actual problems that cannot be solved usingjust ERP software. This book bridges the domains of economists and businessengineers who deal mostly with ERP-like solutions on the one hand and theoperation research experts and mathematicians who typically deal with moreor less isolated optimization applications on the other hand. The availabilityof APS software that is fully integrated into the ERP software and systemlandscapes provides a unique opportunity to utilize these two domains in theform of a tightly integrated symbiosis. Certainly there is still some work todo to convince “business people” of the huge potentials of optimization tech-niques and at the same time convincing the “optimization practitioners” ofthe potential value of APS that are based on a predefined mathematical modeland allow for changing optimization model settings by changing pre-set para-meters. One of the biggest challenges is to work towards better understandingeach other, a seemingly obvious issue that nevertheless is very much neglectedin the real world. Especially this last task is made increasingly difficult be-cause the term optimization, as outlined on page 23 is often used in differentmeanings. In this book we speak of real optimization – meaning that in an1 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 orthat strict and tight bounds are computed quantifying the maximal differencebetween the objective function of the current feasible solution to the optimum.Thus, from the mathematical point of view this leads to incorrect labeling ofsome supply chain management (SCM) and ERP systems as optimizationproviders where in reality just certain rules are applied to real world prob-lems resulting in possibly feasible, but by no means optimal recommendationsfor solving supply chain problems. The value and consequences of obtainingoptimal 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 projectdesigners, projects leaders, the IT personnel inside the companies, but alsooperations research practitioners, supply chain management consultants, anddecision makers in the area of tool selection for optimization tasks. Grad-uates in the economic sciences, business and operations research, but alsomathematicians and physicists with interest in solving real optimization prob-lems might benefit from reading this book. We do not expect a strong back-ground in mathematics and optimization but rather a certain openness tobecome familiar with the concepts and nomenclature of optimization andto acquire the skills necessary to understand the described algorithms andmodels. Our book is not supposed to introduce the reader into SAP, SAP R©R/3 R©, mySAPTMERP, or SAP APO in general. The reader is advised to keepin mind that the optimization engine is just one part of SAP APO and thatthe software supports a wealth of other functionalities and business processes.This book rather summarizes when optimization is useful (Sect. 10.2.1), itprovides a sound overview of optimization model formulation and solving aswell as implementation in SAP APO and leads to interpreting the results inthe right way. At the same time we demonstrate the strengths and weaknessesof the two possible approaches2 – using an integrated advanced planning3 and2 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.

3 The number of case studies using SAP APO (SNP optimizer) discussed in thisbook is most likely not representative for the number of companies using SAPAPO (SNP optimizer) successfully. Current SNP live implementations we areaware of at the time of the writing using the SNP optimizer are with clients inplastics, and in surgical and hygiene items. Current SNP project implementa-tions (with optimizer) planned to go live in the first quarter of 2006 are witha catalyst manufacturer and an automotive supplier. Planned SNP projects tobegin in the first quarter 2006 are with a windmill manufacturer (SNP optimizer)and industrial automation products manufacturer (constraint propagation-basedalgorithm Capable-To-Match, CTM). All these projects have been implementedor will be implemented by axentiv AG (Darmstadt). As it is very difficult toobtain 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 wejust said and explicitly stress what this book is and what it is not :

• it is a book on mathematical optimization in SAP APO for operationsresearch practitioners, consultants, or project team members involved inSAP 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 availabil-ity (permission to write about it in this book) and suitability (didacticalissues)

• 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 mathematicalassumptions enabling to select the best planning philosophy and approachfor a real world optimization problem at hand

• it is a book for readers in companies having selected SAP APO and whowant to improve their cooperation with external consultants by an im-proved understanding of technical issues and foundations

• it is a book for consultants who specialized on introducing SAP APO tocompanies and exploiting SAP APO optimization facilities to its best

• it is a book encouraging the reader to think and to establish an own andindependent opinion

• it is a book which tries to provide clear answers and ideas to real worldoptimization projects involving SAP APO

• it is not an SCM book• it is not a textbook on mySAPTMSCM• 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 – wewould consider them in a future edition of this book.

XII Preface

• it is not a marketing book for Dash Optimization, ILOG, or any otherprovider of optimization algorithms, nor for AUDI, axentiv, Ferrari, orMathesis

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 inChap. 1. This chapter deals with the role of optimization in supply chainmanagement (SCM) and introduces the concept of commercially availablesoftware products, so-called advanced planning systems (APS).

In Chap. 2 we give an introduction into models, model building and op-timization. We introduce the main objects of optimization: variables, con-straints and objective function and give a brief sketch of optimization projects.We conclude this chapter by highlighting the basic ideas and intention of op-timization in SAP APO.

The Chapters 3 and 4 provide a step-by-step introduction into how anoptimization model is built in SAP APO. The more general steps of buildinga supply chain model are explained in Chap. 3 along with an idea how amathematical formulation might look like. Chap. 4 demonstrates how theoptimizer-specific settings are made and the optimization is actually run inSAP APO. By adjusting the parameters we treat this example supply chainmodel as both an LP and an MILP problem.

In Chap. 5 we use supply chain planning in the semiconductor industry asan example of advanced planning in high technology industries. In additionto optimization we discuss a constraint propagation approach that is verypopular in this particular industry. Chap. 6 focuses on consumer goods.

Chap. 7 has been contributed by Ruth Wassermann, Matthias Lauten-schlager, Boris Reuter, and Christian Steiner (axentiv AG, Darmstadt, Ger-many) and discusses a planning problem in the automotive industry and ascheduling problem occurring in the chemical industry. The detailed schedul-ing is part of the overall planning process including SAP R/3, the SAP APOcomponents Demand Planning, Supply Network Planning, and ProductionPlanning/Detailed Scheduling, and ILOG R© cartridge.

Chap. 8 deals with a planning problem in the process industry: a multi-location, multi-period planning problem of a network of multi-purpose reac-tors used in the chemical industry to derive optimal production plans. Thisproduction planning case study focuses strongly on the MILP model and de-scribes a typical situation in which a complete optimization solution has beenimplemented in industry prior to the introduction of SAP APO. The questionsthen arises whether it is possible to replace the system by SAP APO or tointerface it as an individual model. In order to do so, we add appropriate SAPAPO related comments to the mathematical model description. In addition,this case provides a good example of what is needed in terms of documentationif 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 modelshave been interfaced to SAP APO. This chapter indicates alternative tracksand focuses on problems and issues to be considered when taking the approachof interfacing own optimization models to SAP APO. In two of the threecases both the SAP APO optimizer and an external solver are used to tackledifferent planning tasks in one SAP implementation. Section 9.2 and 9.3 havebeen contributed by Remi Lequette (ILOG, Gentilly Cedex, France) and AxelHecker (Mathesis GmbH, Mannheim, Germany), respectively.

A summary of what can be learned from this book and many years ofexperience in SAP APO and optimization projects is given in Chap. 10. Herewe also discuss which impact advanced planning and scheduling systems suchas SAP APO have in larger companies and which possible consequences thishas for optimization in the future.

In the appendix we give an overview of the different SAP APO componentsfollowed by some of the mathematical foundations of optimization enablingthe reader to develop a deeper understanding and to be able to fully exploitthe benefits of mathematical optimization. Finally, we provide a glossary anda subject index for easy reference.

Reading Recommendations

The book has been structured in such a way that the chapters, especiallyChapters 1 to 4 depend on each other while Chapters 5 to 9 are independentfrom each other and thus can be read in any sequence. Chap. 10 providesa summary which for some readers might be the first part to look at (thereare, believe it or not, detective story readers who first want to know whowas the murderer). Of course, the chapters of the book can be read in thesequence arranged in this book. But, depending on the interest of the reader,deviations from this sequence might be appropriate. As the book addressesdifferent types of readers we suggest the following paths. These paths dependon background, interest and goal [Orientation and Real World Optimization(1); SAP APO and mathematical foundations (2), Support of own work inSAP APO projects or when producing a master or PhD thesis (3)]:

XIV Preface

profession background goal path

mathematician

scientists

no SCM

no SAP

(1)

(2)

(3)

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

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

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

economist

SCMno SAP APO

(1)

(2)

(3)

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

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

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

economist

SCM

good knowledge

in mathematics

(1)

(2)

(3)

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

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

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

economist

SCM

poor knowledge

in mathematics

(1)

(2)

(3)

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

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

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

practitioner

consultants

good knowledge

in mathematics

(1)

(2)

(3)

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

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

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

practitioner

consultants

poor knowledge

in mathematics

(1)

(2)

(3)

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

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

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

Most chapters, especially the application Chapters 5 to 9 are written in sucha 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 mentionthat in most cases the book is starting off a topic in an elementary way thatis easy to understand, but might increase in difficulty to a level that mightnot seem adequate to all readers. We choose this proceeding for being able todeal with the topics to a sufficient level of detail, address a wide variety ofreaders, and provide each of them some interesting aspects making this booka companion for quite some time of their work on optimization. We hope thatevery reader will find at least parts of the book useful and will come to theconclusion it was worthwhile to read this book.

This book is partly based on lectures at the University of Heidelberg, Uni-versity of Cologne, and the University of Florida (Gainesville, FL), conferencepapers and experience from industrial projects. We particularly stress the dif-ferent approaches when tackling optimization problems with mathematicalmodel formulation tools and with commercial advanced planning systems. Byshowing the strengths and limitations of both approaches we hope to givenovices and practitioners in supply chain management an orientation andsupport 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 bothauthors had in celestial mechanics, experiencing the inspiring atmosphere ofthe Vienna Observatory and the interaction with Prof. Dr. Rudolf Dvorak4

who encouraged both of us to do some more scientific work also during ourindustrial life. This is not to say that one could not write a book on supplychain issues without a celestial mechanics background – but it definitely helps,especially when watching M13 through the observatory’s large refractor aftera 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 ofhis book. This contributed to Chap. 6.

We are grateful to Ms. Melanie Seliger6 who contributed to Chap. 1, helpedin defining the example model (Chap. 3), and contributed to researching re-sults for Sect. 8.3 and Mr. Clemens M. Merk who helped with translating work-ing manuscripts on Supply Chain Management. We thank Prof. Dr. HartmutStadtler7 for his interest and constructive criticism of the book manuscript.His long-year appreciation of many activities of JK, not only during the workof this book, but also other optimization activities such as the GOR workinggroup “Praxis der mathematischen Optimierung” was always very encour-aging. A special word of thanks is directed to Prof. Dr. Martin Grotschel8

for numerous discussions on supporting mathematical optimization in indus-try. JK thanks Prof. Dr. Robert Daniel9 for giving more detailed insight intoXpress-MPTM.

We are grateful to a number of colleagues who read the manuscript criti-cally and made many valuable suggestions, especially Dr. Ulrich Eberhard10,Dr. Hans-Joachim Pitz11, Steffen Rebennack12, Dr. Anna Schreieck13, againProf. Dr. Hartmut Stadtler14, and Dr. Ruth Wassermann15.4 Institut fur Astronomie, Universitat Wien, Turkenschanzstr. 17, A-1180 Wien,

Austria5 NYU Stern, New York, NY, USA6 POM Prof. Tempelmeier GmbH, Leichlingen, Germany7 Universitat Hamburg, Hamburg, Germany8 Zuse Institut Berlin, Berlin, Germany9 Dash Optimization, Blisworth House Blisworth, GB-Northamptonshire NN7

3BX, England10 BASF Aktiengesellschaft, D-67056 Ludwigshafen, Germany11 BASF Aktiengesellschaft, KTE/P-J630, D-67056 Ludwigshafen, Germany12 Universitat Heidelberg, Heidelberg, Germany13 BASF Aktiengesellschaft, Scientific Computing (GVC/S-B009), D-67056 Lud-

wigshafen, Germany14 Universitat Hamburg, Hamburg, Germany15 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. 39-43, pp. 105-120, pp. 128-131) from Josef Kallrath & John M. Wilson, BusinessOptimisation Using Mathematical Programming, (1997, [55]), Macmillan PressLtd., Houndsmill, Basingstoke, Hamsphire RG21 6XS, UK.

We thank Dr. Werner A. Muller17, the publishing director of Springer’sEconomics and Management Science section for his constructive support, thetime he spent with us in several meetings, all his advise during various phasesof this book project, and for being a patient editor. Thanks is also directed toBarbara Karg18 for her clear answers, instructions and help regarding variouslayout issues in the final production phase of this book.

Overall we thank everybody in the acknowledgement list and also othersproviding minor comments or suggestions who preferred not to be listed forcontributing to this three years project producing this book. It was an in-teresting project and we hope that the reader feels encouraged by the spiritof this book – the reader’s feedback will be appreciated and will likely beconsidered in a future edition of this book.

Weisenheim am Berg, January 2006 Josef Kallrath19

Mannheim, January 2006 Thomas I. Maindl20

16 Loughborough University, Loughborough, UK17 Springer-Verlag GmbH, Tiergartenstrasse 17, 69121 Heidelberg, Germany18 Springer-Verlag GmbH, Tiergartenstrasse 17, 69121 Heidelberg, Germany19 Contact this author by sending an e-mail to josef.kallrath@web.de20 Contact this author by sending an e-mail to thomas.maindl@web.de

Contents

Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Conventions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XXV

Part I Introduction

1 Supply Chain Management and Advanced PlanningSystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Supply Chain Planning – a Brief Introduction . . . . . . . . . . . . . . . 3

1.1.1 The Supply-Chain Operations Reference Model . . . . . . . 41.1.2 Supply Chain Planning and Advanced Planning Systems 61.1.3 Advanced Planning Systems and Optimization . . . . . . . . 8

1.2 SAP APO as an Advanced Planning System . . . . . . . . . . . . . . . . 91.2.1 Components of SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.2 Optimization in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3 Fundamentals of Supply Network Planning in SAP APO . . . . . 121.4 Planning Methods in SAP APO Supply Network Planning . . . . 15

1.4.1 SNP Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.2 SNP Capable-to-Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.3 SNP Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Introduction: Models, Model Building and Optimization . . . 212.1 An Important Warning on Modeling and Optimization . . . . . . . 212.2 Mathematical Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3 The Main Ingredients of Optimization Models . . . . . . . . . . . . . . . 26

2.3.1 Indices and Index Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.3 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

XVIII Contents

2.3.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.5 The Objective Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4 Classes of Problems in Mathematical Optimization . . . . . . . . . . 322.4.1 A Deterministic Standard MINLP Problem . . . . . . . . . . . 32

2.4.1.1 Comments on Solution Algorithms . . . . . . . . . . . 332.4.1.2 Optimization Versus Simulation . . . . . . . . . . . . . 35

2.4.2 Multi-objective Optimization . . . . . . . . . . . . . . . . . . . . . . . 352.4.3 Optimization Under Uncertainty . . . . . . . . . . . . . . . . . . . . 36

2.5 Implementing Models and Solving Optimization Problems . . . . 382.5.1 Implementing Optimization Models . . . . . . . . . . . . . . . . . . 382.5.2 Solving Optimization Problems . . . . . . . . . . . . . . . . . . . . . 39

2.6 Optimization and SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 Model Building in SAP APO Supply Network Planning . . . 413.1 The Example Supply Chain Model . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.1 The Supply Chain Structure . . . . . . . . . . . . . . . . . . . . . . . . 423.1.2 Constraints and Costs in the Example Model . . . . . . . . . 433.1.3 A Mathematical Formulation of the Example Model . . . 45

3.2 Supply Chain Model Master Data . . . . . . . . . . . . . . . . . . . . . . . . . 513.2.1 Models and Planning Versions in SAP APO . . . . . . . . . . 513.2.2 Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.2.3 Products and Location Products . . . . . . . . . . . . . . . . . . . . 553.2.4 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2.4.1 General Resource Data . . . . . . . . . . . . . . . . . . . . . 593.2.4.2 Resource Capacity Variants . . . . . . . . . . . . . . . . . 61

3.2.5 Production Process Models . . . . . . . . . . . . . . . . . . . . . . . . . 613.2.5.1 General PPM Data . . . . . . . . . . . . . . . . . . . . . . . . 623.2.5.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.2.5.3 Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.2.5.4 Product Plan Assignment . . . . . . . . . . . . . . . . . . . 673.2.5.5 PPM Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.2.5.6 PPM Data in the Example Model . . . . . . . . . . . . 68

3.2.6 Assembling the Parts with the Supply Chain Engineer . 693.2.7 Transportation Lanes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4 Optimization in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1 Recap of the Supply Chain Model . . . . . . . . . . . . . . . . . . . . . . . . . 794.2 Optimizer Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.2.1 The Optimization Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.2.2 Scaling the Costs in the Master Data – the SNP Cost

Profile and SNP Cost Maintenance . . . . . . . . . . . . . . . . . . 864.2.3 Working Towards Steady Results – the SNP

Optimization Bound Profile . . . . . . . . . . . . . . . . . . . . . . . . . 874.2.4 Lot Sizes for Shipments – the SNP Lot Size Profile . . . . 884.2.5 Decomposition Methods and the SNP Priority Profile . . 89

Contents XIX

4.2.6 Settings in SAP APO Customizing – the SNPPlanning and Parallel Processing Profiles . . . . . . . . . . . . . 89

4.2.7 The Time Bucket Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.3 The Planning Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.3.1 SNP Planning Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.3.2 Continuous Variant of the Model . . . . . . . . . . . . . . . . . . . . 934.3.3 Discrete Variant of the Model . . . . . . . . . . . . . . . . . . . . . . . 98

4.4 Some Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.4.1 A Mathematician’s View . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.4.2 The Standard Business Software View . . . . . . . . . . . . . . . 101

Part II Detailed Case-Studies

5 Planning in Semiconductor Manufacturing . . . . . . . . . . . . . . . . . 1055.1 Semiconductor Manufacturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.1.1 The Manufacturing Process . . . . . . . . . . . . . . . . . . . . . . . . . 1065.1.2 Semiconductor Business Challenges . . . . . . . . . . . . . . . . . . 107

5.2 Supply Chain Business Practices . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.2.1 Semiconductor Capacity and Master Planning . . . . . . . . 1095.2.2 Semiconductor Supply Chain Modeling . . . . . . . . . . . . . . . 1105.2.3 Semiconductor Supply Chain Planning and SAP APO . 111

5.2.3.1 Capable-to-Match for Semiconductor . . . . . . . . . 1115.2.3.2 Optimization for Semiconductor . . . . . . . . . . . . . 113

5.3 The Semiconductor Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.3.1 The Business Objectives and Project Scope . . . . . . . . . . . 1155.3.2 The Supply Chain Structure . . . . . . . . . . . . . . . . . . . . . . . . 1165.3.3 SNP Implementation in SAP APO . . . . . . . . . . . . . . . . . . 117

6 Consumer Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.1 Supply Chain Challenges Characterizing the Consumer

Products Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.2 The Carlsberg Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.2.1 The Carlsberg Business Objectives and Project Scope . . 1216.2.2 The Supply Chain Structure in the Carlsberg Case . . . . 1216.2.3 SNP Optimization Implementation in SAP APO . . . . . . 123

7 Customized Optimization Solutions for the Automotiveand Chemical Industries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.1 Automotive Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7.1.1 The Complete Planning System . . . . . . . . . . . . . . . . . . . . . 1267.1.2 Strategic Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.1.3 Mid-Range (Budget and Master Production) Planning . 128

7.1.3.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297.1.3.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

XX Contents

7.1.3.3 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307.1.3.4 Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1307.1.3.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.1.4 Order-driven Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317.1.4.1 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327.1.4.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1327.1.4.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1337.1.4.4 Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1337.1.4.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1347.2 Chemical Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.2.1 The Architecture of the Complete Planning System . . . . 1357.2.2 Production Planning and Detailed Scheduling . . . . . . . . . 1367.2.3 Approximation Methods in SAP APO PP/DS . . . . . . . . 138

7.2.3.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387.2.3.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

7.2.4 Cartridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1387.2.4.1 Cartridge Planning Scenario . . . . . . . . . . . . . . . . 1397.2.4.2 Optimization Problem (Overview) . . . . . . . . . . . 1397.2.4.3 Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1397.2.4.4 Smelter/Simple Extruder Model . . . . . . . . . . . . . 1407.2.4.5 Extruder Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417.2.4.6 Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1417.2.4.7 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

7.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1427.3 The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8 Operative Planning in the Process Industry . . . . . . . . . . . . . . . 1438.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438.2 A Tailored MILP Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

8.2.1 Basic Assumptions and Limitations of the Model . . . . . . 1478.2.2 General Framework of the Mathematical Model . . . . . . . 147

8.2.2.1 Indices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1478.2.2.2 Index Sets and Indicator Tables . . . . . . . . . . . . . 1488.2.2.3 The Problem Data . . . . . . . . . . . . . . . . . . . . . . . . . 1498.2.2.4 Time Discretization . . . . . . . . . . . . . . . . . . . . . . . . 1518.2.2.5 The Concept of Modes . . . . . . . . . . . . . . . . . . . . . 1538.2.2.6 The Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

8.2.3 The Mathematical Model – the System of Constraints . . 1568.2.3.1 Modeling the Production . . . . . . . . . . . . . . . . . . . 1568.2.3.2 Modeling Mode-changing Reactors . . . . . . . . . . . 1578.2.3.3 Multi-stage Production . . . . . . . . . . . . . . . . . . . . . 1628.2.3.4 Minimum Production Requirements . . . . . . . . . . 1648.2.3.5 Batch and Campaign Production . . . . . . . . . . . . 1678.2.3.6 Modeling Stock Balances and Inventories . . . . . 169

Contents XXI

8.2.3.7 Dedicated Inventories at Sites (Free Origin) . . . 1698.2.3.8 Modeling Transport . . . . . . . . . . . . . . . . . . . . . . . . 1768.2.3.9 Keeping Track of the Origin of Products . . . . . . 1798.2.3.10 Including Demands and Demand Constraints . . 180

8.2.4 Defining the Objective Functions . . . . . . . . . . . . . . . . . . . . 1818.2.4.1 Maximizing Contribution Margin . . . . . . . . . . . . 1828.2.4.2 Maximizing Margin – Satisfying Demand . . . . . 1858.2.4.3 Minimizing Cost While Satisfying Full Demand 1858.2.4.4 Maximizing Total Sales . . . . . . . . . . . . . . . . . . . . . 1858.2.4.5 Maximizing Net Profit . . . . . . . . . . . . . . . . . . . . . . 1878.2.4.6 Multi-criteria Objectives . . . . . . . . . . . . . . . . . . . . 1878.2.4.7 Maximizing Total Production . . . . . . . . . . . . . . . 1888.2.4.8 Maximizing Production of Requested Products 188

8.2.5 Implementation of the Model . . . . . . . . . . . . . . . . . . . . . . . 1888.2.5.1 Estimating the Quality of the Solution . . . . . . . 1898.2.5.2 Comparing Solutions of Different Scenarios . . . . 1908.2.5.3 Description of the Output . . . . . . . . . . . . . . . . . . 191

8.2.6 Real Life Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1938.2.6.1 Diagnosing Infeasibilities . . . . . . . . . . . . . . . . . . . . 1938.2.6.2 Seemingly Implausible Results . . . . . . . . . . . . . . . 1958.2.6.3 Relaxation of Constraints . . . . . . . . . . . . . . . . . . . 195

8.3 The SAP APO View on this Problem . . . . . . . . . . . . . . . . . . . . . . 1968.3.1 (Non)linear Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1978.3.2 Objective Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1978.3.3 Demand Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1988.3.4 Detailed Comments on the Tailored MILP Model . . . . . . 199

8.3.4.1 Basic Assumptions and Limitations . . . . . . . . . . 2008.3.4.2 General Framework of the Model . . . . . . . . . . . . 2008.3.4.3 The Mathematical Model – the Constraints . . . 2018.3.4.4 Description of the Outputs . . . . . . . . . . . . . . . . . . 2038.3.4.5 Diagnosing Infeasibilities . . . . . . . . . . . . . . . . . . . . 203

8.3.5 Concluding Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

9 Case Studies – Interfacing Tailored Models to SAP APO . . 2059.1 Developing Tailored Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2059.2 The ILOG Cartridge Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

9.2.1 ILOG Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2079.2.1.1 The Optimization Development Framework

and Cartridges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2089.2.2 The Bulk Distribution Case . . . . . . . . . . . . . . . . . . . . . . . . . 208

9.2.2.1 Business Context . . . . . . . . . . . . . . . . . . . . . . . . . . 2089.2.2.2 SAP APO Project . . . . . . . . . . . . . . . . . . . . . . . . . 2099.2.2.3 Cartridge Motivations . . . . . . . . . . . . . . . . . . . . . . 2099.2.2.4 Solution Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 2119.2.2.5 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

XXII Contents

9.2.2.6 Project Information . . . . . . . . . . . . . . . . . . . . . . . . 2159.2.3 The Load Builder Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

9.2.3.1 Business Context . . . . . . . . . . . . . . . . . . . . . . . . . . 2169.2.3.2 SAP APO Project . . . . . . . . . . . . . . . . . . . . . . . . . 2189.2.3.3 Cartridge Motivations . . . . . . . . . . . . . . . . . . . . . . 2189.2.3.4 Solution Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 2199.2.3.5 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2229.2.3.6 Project Information . . . . . . . . . . . . . . . . . . . . . . . . 222

9.2.4 The Cartridge Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 2239.2.4.1 External Architecture . . . . . . . . . . . . . . . . . . . . . . 2249.2.4.2 Data Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 2279.2.4.3 Internal Architecture . . . . . . . . . . . . . . . . . . . . . . . 227

9.2.5 About Cartridge Projects . . . . . . . . . . . . . . . . . . . . . . . . . . 2289.2.5.1 The Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2289.2.5.2 The Inception Phase . . . . . . . . . . . . . . . . . . . . . . . 2309.2.5.3 Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2339.2.5.4 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2339.2.5.5 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2349.2.5.6 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

9.3 Production and Sales Planning in the Chemical Industry . . . . . 2379.3.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2379.3.2 Task and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2379.3.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

9.3.3.1 Data Download from SAP R/3 and SAP APO. 2399.3.3.2 Checks on Completeness and Consistency . . . . . 2409.3.3.3 User Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2409.3.3.4 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2419.3.3.5 Iterations and Adjustments . . . . . . . . . . . . . . . . . 2419.3.3.6 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

9.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2429.3.4.1 The “Human Factor” . . . . . . . . . . . . . . . . . . . . . . . 2439.3.4.2 “Plug-in” Solution Versus SNP . . . . . . . . . . . . . . 243

9.3.5 Future Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2459.3.5.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2459.3.5.2 Task and Objectives . . . . . . . . . . . . . . . . . . . . . . . 2469.3.5.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Part III Concluding Considerations - The Future

10 Summary, Visions and Perspective . . . . . . . . . . . . . . . . . . . . . . . . . 25310.1 What Can Be Learned from this Book? . . . . . . . . . . . . . . . . . . . . 25310.2 A Summary of Experience in Optimization Projects . . . . . . . . . 255

10.2.1 When Is Optimization Useful at All? . . . . . . . . . . . . . . . . . 25510.2.2 Data and Optimization Model . . . . . . . . . . . . . . . . . . . . . . 261

Contents XXIII

10.2.3 Rules in Planning and Scheduling Problems. . . . . . . . . . . 26210.2.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26310.2.5 Interfacing Tailored Models . . . . . . . . . . . . . . . . . . . . . . . . . 265

10.3 Further Developments in Real World Optimization . . . . . . . . . . 26510.3.1 Simultaneous Operative and Strategic Optimization . . . 26610.3.2 Rigorous Approaches to Scheduling . . . . . . . . . . . . . . . . . . 26710.3.3 Planning and Scheduling Under Uncertainty . . . . . . . . . . 26810.3.4 A Mathematician’s Dream . . . . . . . . . . . . . . . . . . . . . . . . . . 26810.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 . . . . . . . . . . . . . . . . . . . . . . 273A.1 SAP APO Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273A.2 Hierarchical Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

B Mathematical Foundations of Optimization . . . . . . . . . . . . . . . . 277B.1 Linear Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

B.1.1 A Primal Simplex Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 279B.1.2 Computing Initial Feasible LP Solutions . . . . . . . . . . . . . . 283B.1.3 LP Problems with Upper Bounds . . . . . . . . . . . . . . . . . . . . 284B.1.4 Dual Simplex Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 286B.1.5 Interior-point Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

B.2 Mixed Integer Linear Programming . . . . . . . . . . . . . . . . . . . . . . . . 290B.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 thisbook.

Abbreviation Meaning

APS Advanced Planning SystemATP Available-to-Promise

BAPI R© Business Application Programming InterfaceBOM Bill of MaterialB&B Branch and Boundcf. confer (compare)CIF Core Interfacecu currency unitCP Constraint ProgrammingCTM Capable-to-MatchCTP Capable-to-PromiseDP Demand Planninge.g. exempli gratia (for example)ERP Enterprise Resource PlanningGUI Graphical User Interfacei.e. id est (that is)IP Integer ProgrammingLP Linear ProgrammingMILP Mixed Integer Linear ProgrammingMIP Mixed Integer ProgrammingMIQP Mixed Integer Quadratic ProgrammingMINLP Mixed Integer Nonlinear ProgrammingMPEC Mathematical Programming with Equilibrium ConstraintsMRP Material Requirements PlanningNLP Nonlinear ProgrammingODBC Open DataBase ConnectivityOR Operations ResearchPDS Product Data StructurePP/DS Production Planning and Detailed Scheduling

XXVI Conventions and Abbreviations

PPM Production Process ModelQP Quadratic ProgrammingSAP APO SAP Advanced Planning and OptimizationSCM Supply Chain ManagementSNP Supply Network Plannings.t. subject tow.r.t. with respect to

Part I

Introduction

1

Supply Chain Management and AdvancedPlanning Systems

One of the most prominent applications of optimization in today’s businessworld is using advanced planning in supply chain management (SCM). Inshort, SCM refers to coordinating material, information and financial flows ina company’s value chain including business partners such as suppliers, con-tract manufacturers, distributors, and customers. In the following chapter wegive a concise introduction to the SCM and supply chain planning terms andconcepts sufficient for the following context of optimization applied to supplychain problems and introduction of the SAP APO software. For a more thor-ough treatment of SCM and advanced planning see the ample literature onthis 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 consul-tants 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’spoint of view has been created. We will stick to our short and broad defini-tion as it is sufficient for the purpose of this book.

SCM is a business economics term and the involved tasks and processesas well as solution methodologies are classified in a business-oriented way. Tosomeone with a mathematically oriented science background this may appearless exact and precise than desired. Therefore there is an arbitrary large po-tential for misunderstandings and conflict when dealing with mathematicalissues such as optimization in SCM. We see it as a primary target for thisbook to help build a bridge between business administration and economicson the one hand and the exact sciences on the other hand. The basic advisein this context is to agree on some sort of communication quality standardsensuring that precise definitions are used and that it is checked whether allparticipants involved in the communication mean and understand the samewhen using certain terms.

4 1 Supply Chain Management and Advanced Planning Systems

Deliver Deliver DeliverDeliverSource SourceSource SourceMake MakeMake

Plan

Suppliers’Supplier

SupplierYour Company

Customer Customer’sCustomer

Internal or External Internal or External

Return Return

ReturnReturnReturnReturnReturn

Return

PlanPlan

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

In this chapter we will focus on the aspects of SCM relevant to optimizationas well as on the role SAP APO as a software tool plays when it comes tomathematical optimization. For a more thorough discussion of definitions andissues in and around SCM we refer the reader to the abundant literature onthis 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 processesand concepts of actually doing supply chain management in a standardizedway. The Supply-Chain Council, a non-profit organization formed as an in-dependent consortium in 1996, standardizes supply chain terminology andprocesses in the widely accepted and adopted Supply-Chain Operations Ref-erence (SCOR R©) model. The Supply-Chain Council focuses on practitionersrather than academia and comprises several hundred members, the majorityof which are companies and organizations applying SCM and the SCOR prin-ciples to their business. The SCOR model aims at improving supply chainprocesses and structures to serve customers’ needs as well as possible. There-fore it takes into account processes and transactions from the “supplier’s sup-plier” to the “customer’s customer” enabling supply chain evaluations fromdifferent aspects – from within and outside the company. The model is di-vided into four hierarchical levels dealing with process types, process categories,process elements, and, finally, implementation. None of these four hierarchicallevels touches solution methodologies such as mathematical methods or opti-mization techniques, however. In each level predefined best practice buildingblocks are available which can be used to model supply chain processes in aneasily reconfigurable way. Figure 1.1 shows the SCOR model’s level one withthe five elementary management processes plan, source, make, deliver, andreturn. In each of the process types there is potential for optimization suchas 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, forinstance, distinguishes between 30 process categories covering planning, exe-cuting, and enabling. One of the biggest benefits of using a standard modellike SCOR is introducing a standard terminology enabling efficient communi-cation between the parties involved in implementing a supply chain strategy.The Supply-Chain Council has created a glossary that defines more than 300terms and metrics allowing standardized performance benchmarking of a givensupply chain.

Diving a bit deeper into the four processes source, make, deliver, and returnwe have to distinguish between planning the future events in the supply chainand dealing with current events and tasks. The earlier is widely called sup-ply chain planning (SCP), the latter supply chain execution (SCE) or supplychain operations. Examples of SCP are strategic and tactical planning such asnetwork design, network or master planning, production planning, transporta-tion planning and routing, demand forecasting, and so on; examples for SCEinclude event tracking (for instance, in transportation), warehouse operations,transportation load consolidation, shop floor control in manufacturing execu-tion, etc. From the nature of these tasks it is quite straightforward to see thaton the one hand SCP typically is done once in a while in order to get resultsthat remain valid between instances of executing the SCP process, and SCEon the other hand is in some sense “always online” because it has to be readyto trigger and execute certain actions in response to real-world events. Masterplanning as a typical SCP process, for instance, is – depending on the typeof industry and particular business – done once a day, once a week or evenless frequently and results in a rough-cut plan that allocates resources in theproduction network to certain activities that work towards fulfilling customerdemands. Due to the fact that these plans typically affect multiple locationsand hence involve not only communication with electronic systems, but alsoa certain amount of human interaction before they are actually executed, itis not feasible to execute them continually.1 Optimization as a solution tech-nology for supply chain problems, at least on the tactical planning level, is“offline”, too. It takes a snapshot of the business data of interest, optimizesaccording to a well-defined model, and writes the results back to the businessdata repository (which usually is some sort of transactional business softwaresystem such as SAP R/3 or mySAP ERP). Often, performance, process, andproblem localization requirements chase optimization away from SCE tasks:for most companies it is undesirable to re-calculate all delivery routes in thecase of one delivery truck out of many dozen being involved in a traffic acci-dent, for example. A more desirable scenario in this case would probably beto apply some local, rules-based algorithm that might suggest to extend the1 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 makeproduct changes expensive. A good master planning algorithm takes this intoaccount.

6 1 Supply Chain Management and Advanced Planning Systems

AvailableTo

Promise(ATP)

TransportationPlanningScheduling

DistributionPlanning

ProductionPlanningMaterial

Require-ments

Planning(MRP)

Master Planning

Strategic Network Planning

DemandPlanning

long-term

short-term

Procure Produce Distribute Sell

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 remainingcustomers from safety stock. Optimization will be successful in this area ifthe model is thoroughly designed to match the specific businesses, but thisusually 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 wejust did has been taken by Rohde et al. (2000, [79]) who define the supplychain planning matrix classifying SCP tasks by planning horizon and supplychain process. In Fig. 1.2 we give a version of the SCP matrix; note thesimilarity of the processes along the x-axis with the SCOR process typessource, make, and deliver. The vertical axis in the SCP matrix correspondsto the time horizon affected by the corresponding planning processes and alsogives an idea about how frequently the planning activities are performed.Although the SCP matrix is not completely adopted in the literature and hassome structural drawbacks (cf. Tempelmeier, 2001, [96]), we will use it as atool displaying SCM functionality “at one glance” – without asking questionslike “Why does MRP belong to procurement?” or “Does demand planningreally belong to supply chain planning?”. With the exception of stand-aloneMaterial Requirements Planning (MRP) we see the functional modules of theSCP matrix in software systems called advanced planning systems (APS):2

2 MRP is essentially a straightforward calculation of dated material requirements ina 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 supplychain processes creating suggestions for network design, cooperative suppliercontracts, distribution structures, manufacturing programs, etc. Decisionsmade based upon this module are strategic and thus long-term in natureand consequently cannot be undone or changed without considerable finan-cial impact. The underlying data of such decision processes are mostly not inthe transactional business software but in archives such as data warehouses.This leads to most companies setting up strategic network planning projectsusing in-house or external consultants with customized mathematical softwaretools independently of their enterprise business software.

Demand Planning takes a supporting role to the planning processesby generating forecasted demand figures that are fed into the other planningmodules. Its functionality is based on statistical methods, on “collaboration”between business partners such as key customers or distributors that canhelp estimate future demand, and on data analysis methods such as “what-ifanalyses”, aggregation/disaggregation, etc.

Master Planning creates feasible mid-term production plans synchro-nizing the material flow along the supply chain and ensuring efficient resourceutilization in procurement, production, warehousing, and distribution. Usu-ally this is a centrally executed process because its outcome affects the wholesupply chain and respects interdependencies of different supply chain partssuch as production facilities being able to manufacture the same product.Master planning depends on input data obtained from network design, de-mand planning, and cost data from all parts of the supply chain – these costsare used to decide between options in procurement, production, and trans-portation of goods. Depending on the complexity of the supply chain and itsprocesses master planning is often restricted to consider bottleneck materialsand/or resources or aggregated production processes.

Available- and Capable-to-Promise (ATP/CTP) help in order pro-mising. When a customer order for a specific product comes in, ATP checksquantities in stock and planned receipts (from procurement and production)across the entire supply chain to determine a delivery date for the order. Op-tionally, CTP can create production orders for the required product, whichinvolves changing and adapting production plans according to incoming cus-tomer orders and available resource capacity.

Production Planning and Scheduling creates detailed, short-termproduction plans for individual production areas (e.g., plants) based on theresults from master planning. The tasks can be divided into lot sizing, resourceutilization planning and detailed scheduling. Similar to master planning, thegoal 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 processesin 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 function-ality 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 orrestricting processes as in master planning. The detailed production plan ispassed on to manufacturing execution / shop floor control systems and henceleaves the classical domain of APS.

Distribution and Transportation Planning determines which quan-tities of goods are transported via which routes in the supply chain at whattimes. Distribution planning deals with transportation quantities and stocklevels in connection with customer deliveries considering stock and transportcapacities whereas transportation planning performs routing and load plan-ning determining cost effective and timely deliveries.

1.1.3 Advanced Planning Systems and Optimization

APS supplement the existing optimization programming libraries and pureoptimization engines with “ready-to-use” applications covering certain SCMprocesses. Almost all major business software providers offer an APS as partof their application suite covering the processes described above to a larger orsmaller extent. They typically divide their software into modules covering oneor more of the SCP matrix elements; often enough the quality of this coverageis dependent on the industry – good functionality for production planning inthe process industry does not necessarily imply that the respective APS iswell-suited for discrete manufacturing such as high tech. In a complete SCMsolution these modules have to work together in an integrated way which setshigh standards for implementing and running those APS solutions. Often itis most beneficial to use the APS and the ERP system from the same vendorto take advantage of native system integration technologies.

Optimization techniques are applicable in the areas of Strategic NetworkPlanning, Master Planning, Production Planning and Scheduling, and Dis-tribution and Transportation Planning. The remaining areas are typicallytackled with statistics (Demand Planning), rules-based algorithms (sales or-der promising, ATP/CTP), or transactional and/or rules-based processing(MRP). Commercially available APS that make use of optimization usuallyoffer comprehensive, but predefined mathematical models for one or more ofthese application areas. We see those commercial APS as an augmentation tothe programming libraries, pure optimization engines, e.g., Xpress-MPTM andCPLEX R©, and respective modeling systems and languages (cf. Stadtler, 2000,[89]). Most APS use ILOG’s optimizer library, but the model formulation it-self is kept as a company secret and only documented by stating supply chainparameters such as products, locations, customer orders, late delivery penal-ties, etc. that go in the model equations and the objective function. Therefore,before an actual implementation of such an APS is started a thorough investi-gation of the applicability of the vendor’s model is essential in order to avoidsurprises upon implementation: in contrast to custom applications developedby 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 ofimplications 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 appli-cation software, offers the advanced planning system SAP APO3. The nameSAP APO however is difficult to find in company publications and the SAPwebsite http://www.sap.com because the APS is now marketed as part ofmySAPTMSCM, one software solution offered in the mySAPTMBusiness Suite.One SAP product enabling the mySAP SCM solution is SAP R© SCM, and partof this product SAP SCM is the application SAP APO along with two otherapplications dealing with supply chain visibility, event management, and in-ventory collaboration. Henceforth, for an easier reference to the software thereader might have heard of or is familiar with already, we will continue towrite SAP APO when we mean SAP’s APS offering.

In a similar way, we will refer to the ERP offering of SAP as mySAPTMERP.After the release SAP R/3 Enterprise 4.70 a shift was made to the mySAPERP solution containing SAP ERP Central Component as the direct SAPR/3 successor. In the case studies later in this book we still refer to SAPR/3 if this is the product actually implemented at the time of the respectiveprojects.

1.2.1 Components of SAP APO

Figure 1.3 shows how SAP APO covers the functionality in the SCP matrixand states the respective SAP terminology.

“Network Design” was available in SAP APO based on MILP up to re-lease 3.1 and has been discontinued by SAP due to business reasons. Thismight have been due to the conceptual separation of an operational APS andstrategic projects such as network design being based on specialized softwareof niche players in the market (cf. the related comment on p. 7). For thisreason we decided to leave Network Design in Fig. 1.3, but we will not furtherelaborate on this SAP APO functionality.

MRP can be seen as a rules-based mechanism of creating supply elementsfor demand without considering constraints such as material availability andavailable 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. therelated footnote on p. 6) and the user can choose which parts of the supplychain (which products, for instance) shall be planned in SAP APO and whichshall be planned in mySAP ERP. This is because SAP APO and mySAPERP 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

GlobalAvailable

ToPromise(GATP)

TransportationPlanning /

VehicleScheduling

Deployment

ProductionPlanning

DetailedScheduling

(PP/DS)

SAP APO planning

algorithms

SAP R/3

Supply Network Planning (SNP)

Network Design

DemandPlanning

(DP)

long-term

short-term

Procure Produce Distribute Sell

Fig. 1.3. SAP applications and components covering the supply chain planningmatrix

– given a properly configured CIF connection – ensures real-time integrationof the transaction system (mySAP ERP) and the APS (SAP APO). Plannedproduction orders that are created by a planning process in SAP APO areimmediately transferred to mySAP ERP and can be used by a subsequentMRP 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 notin its original mathematical meaning SAP APO, in some of its components,provides strict optimization algorithms in the sense of the definition givenin Sect. 2.2. The following is a list of components (sometimes also called“modules”) in SAP APO using planning algorithms along with a summary ofthe types of the implemented algorithms (we refer to SAP APO release 4.1):

• Supply Network Planning (SNP): mid-term multi-location production anddistribution 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 single-location 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 planningtasks is in accordance with the expectations of the business administration andeconomics. The techniques listed can be divided into two classes: a) heuris-tics being reasonable approaches finding feasible (hopefully good) solutionsquickly and b) algorithms called optimization in the colloquial language ofbusiness administration and economics. In the sense of the exact mathemati-cal sciences aiming for preciseness and optimality there is no doubt that LPand MILP are exact optimization algorithms in the sense of the definition inSect. 2.2, constraint propagation and evolutionary algorithms are not. How-ever, hybrid approaches – constraint propagation and evolutionary algorithmscoupled with bound-generating methods – are also exact.4 As in this book westick to real optimization in the sense of the definition given in Sect. 2.2 we donot cover constraint propagation and evolutionary algorithms, realizing thatthe nature of standard planning software as a means for solving a wide varietyof planning problems and the desires of clients implementing and using suchsoftware requires these latter algorithms being part of the solution portfoliooffering.

Regarding advanced modeling requirements such as finite scheduling, se-quencing and vehicle routing there is indication that the lack of real opti-mization in commercial APS software is due to the current impracticability offormulating 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 undisputableexact mathematical sense. Therefore we restrict the focus of this book to SNPwhen it comes to optimization wholly within SAP APO.

As it is usually the case with commercial APS, the variables and equationsconstituting the optimization model are predefined and not revealed by thevendor. Depending on business parameters originating from the transactionsystem mySAP ERP and/or SAP APO itself such as locations, products, re-source capacities, late delivery penalties, etc. the actual optimization modelis built by the model generator in a pre-processing step (see Fig. 1.4). Theoptimization engine receives this model along with transactional data (suchas 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 labeledand positioned as what they are: reasonable approaches finding feasible (hopefullygood) solutions. From a technical point of view one could in some cases supportthe argument that due to the availability of only non-exact data, striving for thestrict optimum may be less important. However, this claim can only be justifiedusing technical methods appropriate for analyzing non-exact data, which leadsback 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 areready to be analyzed in SAP APO and – in the case of a connected system –in mySAP ERP. Additionally, for diagnostic purposes users can evaluate tech-nical protocols of the model generator and the optimization engines. Modelgeneration and diagnostics will be covered in Chapters 3 and 4, where we willdiscuss the application-specifics in more detail.

1.3 Fundamentals of Supply Network Planning in SAPAPO

As we have seen in Sect. 1.2, SAP APO uses real optimization in the sense ofthe definition given at the beginning of Sect. 2.2 primarily in Supply NetworkPlanning. Therefore we think it is a good idea to spend two introductorysections on this SAP APO component.

Supply Network Planning (SNP) is used for the compilation of supplychain-wide, realizable mid- and long-term plans for on schedule coverage ofestimated requirements from demand planning as well as existing customerorders. In addition to the selection of optimal sources of supply consideringpurchasing, production, distribution, and transport, SNP is responsible formaintaining the required safety stock levels covering demand uncertainties.The planning process is quantity and period orientated; this involves day-exact order deadlines without consideration of detailed order sequences. As aresult of SNP processes companies receive information about supply demandson 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. Planningissues in SNP can be addressed with SAP APO Alert Monitor functions. TheAlert Monitor issues more or less detailed warnings about an existing planningproblem according to its configuration.

SNP is based on certain SNP-relevant master data, specifically locations,products, resources, production process models (or – alternatively – productdata structures), as well as transportation relations between locations.5 Dif-ferent location types such as (production) plants, distribution centers, pointsof stock transfer, customers, etc. are available. The characteristics of theselocations, like geographic location or potential restrictions are saved in thelocation as well as in other corresponding master data (e.g., resources thatexist in locations).

Suppliers can be defined as contract manufacturers. Contract manufactur-ing is recognized as the manufacture or assembly at a supplier (the contractmanufacturer) whose components are delivered by the ordering company or athird party (contract manufacturing with third party purchase). An exampleare packaging processes, where the contractor receives material and wrappingfrom another company, performs the final packaging process and returns thepackaged product to the company. Transport relations exist between the in-dividual locations. These relations do not only include distance, specification,means of transportation, etc., but also transportation costs, which are relevantfor 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 aggregationinto different product groups for mid-term planning is possible. In SAP APO aproduct at a specific location is an object called location product. In the prod-uct master data SNP offers interchangeability of products. Interchangeability,available since SAP SCM release 4.0, distinguishes between the discontinua-tion of a product, the replacement chain, and the form-fit-function-class. Allthree functions are considered by the heuristics, CTM, and the optimizer. Dur-ing 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 var-ious directions and various steps (e.g., product A for product B, product Afor product B or C, product A for product B and later product B for productC and then again for product A, etc.). This allows to include promotions orseasonally changing products in the planning process. The form-fit-function-class finally consists of interchangeable, completely substitutable, materialswhich have identical characteristics (form, fit, and function).

SNP resources are either defined as bucket resources, which are SNP-specific and contain details about possible utilization hours and the availablecapacity, or as single-mixed and multi-mixed resources. The latter ones areused 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 ofsupply 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 forSNP and continuous capacity for PP/DS planning.6 Minimal, normal, andmaximal capacities can be defined for the mentioned types of resources in theresource master data. The single capacity load levels can be specified accord-ing to amount and rate, while violating minimal and maximal capacities canbe tied to penalty costs.

The last principal step in master data setup for SNP is the definition ofSNP production process models (PPMs) and production process model plans(PPM plans).7 The PPM describes when a PPM plan can be used for theproduction of a product while the actual PPM plan includes the bills of ma-terial (BOM) and the routing. This allows for a customer order-independentdescription of the production process for the manufacture of one or more prod-ucts. Typically, the individual operations and activities in a SNP PPM spanseveral actual process steps on the shop floor which results from the mid-term planning environment and decreases calculation time of a given plan.In the SAP APO concept master planning does not require time-resolutionfiner than a day. For detailed scheduling SAP APO offers PP/DS PPMs for amore detailed modeling of the production processes. Each activity in a SNPPPM is assigned a mode which defines the required resources on which theactivity is performed, and the activity relationships in the PPM reflect theactual sequence of process steps in the routing.

If the user is familiar with Demand Planning (DP) in SAP APO, he orshe will find the basic setup of SNP comparable to that of DP regarding theplanning area, the basic planning object structure, the planning book, andthe assignment of key figures and characteristics in the InfoCube8. The SNP-relevant transactional data is saved in liveCache, a memory-resident relationaldatabase optimized for fast data-access. The master data is explicitly storedin the SAP APO database.9

6 Rather than planning in discrete time buckets like SNP, production planningand detailed scheduling (PP/DS) plans production activities time-continuously(“exact to the second”) and therefore requires continuous capacity data in itsresource master data.

7 As of SAP APO release 4.1 an alternative way of modeling production for – es-sentially – all SAP APO components is provided by the production data structure(PDS). Because SAP continues to support the PPM and in order to stay compat-ible 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.

8 An InfoCube is an instance of a multi-dimensional data model within the SAPBusiness Information Warehouse which is also available in SAP APO. Technically,an InfoCube consists of a number of relational tables arranged according to thestar scheme: a large fact table in the center is surrounded by several dimensiontables.

9 On possible integration scenarios with mySAP ERP (SAP R/3) see for instanceDickersbach (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 NetworkPlanning

Three methods are available for SNP differing in the mathematical methodsused and in the consideration of material and capacity constraints. For a com-plete picture of the methods offered by SNP we will discuss all three methods.SAP distinguishes heuristics, optimization-based planning, and Capable-to-Match (CTM).

1.4.1 SNP Heuristics

The term heuristics derives from the Greek “heuriskein” and means to findor discover and was originally used for the description of the art of invention.Heuristics are procedures for solving problems and discovering new knowledgebased on a logic sequence of steps. In the field of supply chain planning theyare deployed to find a sufficiently good solution in an acceptable period oftime 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 ne-glected (infinite heuristics), it is not guaranteed that a feasible solution willbe found, nor an optimal solution. After the infinite heuristics run, SAP APOcan examine the capacity situation displaying information about when andwhere resource overloads caused by the generated plan occurs. By interac-tively adjusting the resource loads into the past or future capacity utilizationmay be adjusted (capacity levelling) for one resource at a time. Afterwardsthe effects of the adjustments on the load on other resources can be evaluated.

In SAP APO the available heuristics are multi-level heuristics, networkheuristics, and location heuristics. The source of supply determination of allthree processes is based on priorities and quotas. Quotas indicate to whatfraction the product requirements are supposed to be received from a sourceor are to be delivered to a location.

In regard to the heuristic functions it is necessary to differentiate betweenplanning processes that are executed in context with interactive planning oras background processing. For interactive planning all three options are avail-able: location, network, and multi-level heuristics. In location heuristics, onlylocation products from a single, predetermined location are considered in theplanning 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 sup-posed to be planned and components considered, multiple location heuristicsruns can be executed. In network heuristics, all locations of the supply chainare considered in the planning process, but again in a single-level fashion; con-sequently, only planning for final products is possible. In multi-level heuristicsthe network is viewed as a whole and the final products are broken down ac-cording to all their respective BOM levels. Hence, planning for primary andsecondary products occurs.

16 1 Supply Chain Management and Advanced Planning Systems

Background processing is done by specifically configured ABAPTM pro-grams. Since SAP SCM release 4.0 it is possible to perform a BOM explosionby setting a check mark in the location and network heuristics, which allowsplanning the components of the final product at the according locations. Sincethe network heuristics in combination with this mark offers the same functionas the multi-level heuristics in interactive planning, multilevel heuristics arenot offered in background processing.

1.4.2 SNP Capable-to-Match

Capable-to-Match (CTM) is a finite, multi-level, and cross-plant planningmethod available in SNP.10 The methodology behind it is constraint prop-agation. Other than an optimizer, CTM does not optimize total cost but isbased on heuristics driven by priorities, e.g., regarding demand sequences andthe choice between purchasing alternatives. Costs are considered for deriv-ing priorities in relation to sourcing decisions in case there is an alternativebetween in-house production and procurement/transportation comparing themulti-level cost of PPMs related to production and the shipping costs relatedto external procurement.

Supporting detailed order-based planning CTM offers a pegging methodthat 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 peg-ging structure describes the material flow between orders across all BOMlevels from the finished product up to raw material supply. The quantities ofdemand and supply elements can deviate from each other – resulting fromdifferent lot sizes for instance. Therefore, in some cases, demands are peggedto several supply elements and the supply elements cover multiple demands.SAP APO distinguishes fixed and dynamic pegging. In the first case the peg-ging relationships are stored in the liveCache – the memory-resident databaseholding transactional data – and remain unchanged until a new planning runthat re-determines fixed pegging is executed. Dynamic pegging relationshipson the other hand may change whenever new supply or demand elements arewritten into liveCache as they are calculated on-line in the liveCache. CTMplanning can deal with both pegging types.

The result of a CTM planning run is always a feasible – not necessarilymathematically optimal – production plan.11 It is a sequential algorithm thatworks through the list of demands and tries to fulfill one after the other as10 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 developmentwas initiated in the late 1990’s and constantly enhanced. Even though it wasoriginally focused on semiconductor manufacturing, today customers in variousindustries use it. See Sect. 5.2.3.1 for a discussion of CTM for semiconductor.

11 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 orderswhich 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 prioritizeddemands

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

Multi-level SDM algorithm:Capable-to-Match (CTM)

Material requirements planningmulti-site capacity check

check of transportation capabilities

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

and the first one on the list is fulfilled by a series of planned production andtransport orders via several production steps at different locations originatingfrom raw material supply. This demand sequence is built based upon prioritiesthat are set by the user/implementor based on any demand characteristicavailable in SAP APO such as customer, customer group, product (group),order dates, etc. Similarly to prioritizing demand, priorities are also assignedto categories of supply such as inventory, in-house production, safety stockshortfall, etc. These priorities together with quotas for different classes ofsupply (e.g. “use up inventory rather than procuring from location A” or“procure 40% from location B and 60% from location C”) define CTM’ssearch strategy for covering the demands. The stock categorization is based onavailable inventory and planned supply with possible assignment of inventorycategories or stock limits to the individual locations.

CTM tries to cover all demands on their respective due dates. To do so itutilizes forward and backward scheduling. If on-time delivery is not possibleCTM can use a combination of several strategies for dealing with delayeddemand:

• Minimize delays: switch from backward to forward scheduling and fulfillthe demand with as little delay as possible, up to a maximum delay afterwhich the demand is left unsatisfied.

• Gradually postpone demand date: add a certain number of days to thedemand’s due date and try again. This way a little “buffer” in resourceavailability 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 prioritizedlist, and try to fulfill the other demands first. This increases the chancefor subsequent demands to be satisfied on time. The opposite in CTM isthe domino strategy allowing late fulfillment of the demand in questionthat may cause a late fulfillment of the other demands depending on thecapacity situation.

• Down-binning scenarios: based on certain rules, try to use higher qualityproduct to cover demands of lower quality product.

• Allow shortages, i.e., a partially satisfied demand will be considered ful-filled.

As a result of CTM planning the user receives the assignment of sourcesand scheduling of demands as well as the appropriate secondary demandswithin a mid-term demand and distribution plan which also considers partialshipments.

From the rules-based approach just described CTM derives its “locality”: itworks one demand at a time fixing all orders originating from demands alreadyprocessed 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, itis worthwhile to evaluate using the SNP optimizer.

1.4.3 SNP Optimization

The optimization-based planning exploits exact mathematical optimizationalgorithms and facilitates the computation of mathematically optimal andfeasible solutions. The SNP optimizer in SAP APO is based on linear andmixed integer linear programming (LP and MILP) using ILOG’s CPLEX asthe 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 pointmethods (see Appendix B.1).

The decisions about the sources of supply for the products in question de-pend on the resulting costs, the cost factors considered in SAP APO are listedin Table 1.1. The basic idea of the SNP optimizer is to plan the whole supplychain with the objective of optimizing total cost. The costs are maintained inSAP APO and can be chosen so that the actual business objective (such as in-creasing customer service, decreasing inventory levels across the supply chain,etc.) is addressed by the optimization model. In the optimization profile theoptimization objective can be set to either cost minimization or profit maxi-mization. The difference is in the way the system interprets the non-deliverypenalty costs. In the case of profit maximization this penalty is seen as therevenue of selling a particular product. Hence, the total profit is then calcu-lated as the quantity of goods produced times the respective revenues less allcosts defined to be relevant for the optimization run. The relevant costs canbe 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 Dimension Comment

production cost by production processmodel

linear or piecewise linear

production resourcecapacity expansion cost

by resource family can be time-dependent

production resourcecapacityunder-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 resourcecapacity expansion cost

by resource family can be time-dependent

shelf life cost by material and location procurement cost used forcalculating penalty cost fordisposing of a product withpast shelf life date

safety stock deficitpenalty cost

by material and location

handling resourcecapacity expansion cost

by resource family can be time-dependent

transportation cost by material and lane linear or piecewise linear

transportation resourcecapacity 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 thenon-delivery penalty is usedinstead of the late deliverycost; can be time-dependent

The constraints considered by the SNP optimizer can be soft, pseudo-hard, orhard. Examples for soft constraints are bottlenecks which are caused by deliv-ery dates and that can be compensated by capacity expansions or additionalshifts. Soft constraints can be “violated” by the solution resulting in penaltycosts that go in the objective function. Pseudo-hard constraints are charac-terized by possible violations that, however, result in very large (“infinite”)penalty costs. The consequence is that the optimizer only allows violationsif 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 becomplied with the plan becomes unrealizable and finding an optimal solutionmathematically infeasible leading to a termination of the algorithm. The op-tion to define conditions and restrictions as soft or pseudo-hard constraints isnecessary since business goals can be at odds with each other.

Since the existence of many restrictions or – to a higher extent – dis-crete variables can lead to high computational efforts, SAP APO offers vari-ous possibilities to reduce the storage and runtime requirements by dividingthe problem into parts. Particularly in case the supply chain model resultsin a MILP problem solver runtimes can get very high; integer models are aconsequence of discrete decisions such as modeling lot size intervals. As theimplementor does not have direct access to SAP’s mathematical model for-mulations these methods of handling solution times are the appropriate wayof influencing the behavior of the SAP APO optimizer (apart from changingmaster data that define the coefficients in the model equations). Especiallywhen dealing with large MILP problems the runtime of the algorithm might becut by decomposing the problem into smaller subproblems. SAP offers time,product, and resource decomposition. With time decomposition the originalproblem is split up into successive subproblems which are solved sequentially.Product decomposition creates product groups for which the total systemis optimized individually. Resource decomposition is based on the analysis ofthe material flow and the basic decisions about production. After the analysis,subproblems are developed for the individual resources according to which theresource assignment is generated. With product and resource decompositionpriority profiles can be established to determine the sequence in which theoptimizer aggregates and plans product groups and resources. Another possi-bility for simplifying the planning problem is incremental planning where theoptimization is only done for a segment of the supply chain model or on thebasis of a previously developed plan. Finally, there is an option for verticaland horizontal aggregation of planning data where the optimization is dealingwith aggregated data rather than with data at the high-detail level. Verticalaggregation is concerned with product demand and horizontal aggregationdeals with subgroups of the supply chain network.

Chapter 4 goes into some more detail on how and where to actually setthese optimizer options in SAP APO.

2

Introduction: Models, Model Building andOptimization

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

2.1 An Important Warning on Modeling andOptimization

Modeling is an important concept and methodology in various disciplines. Inthis book we encounter on the one hand the data model in SAP and the pre-defined model implemented in SAP APO, and on the other hand a data modeland an optimization model used in mathematical optimization. Although theterms data model and optimization sound the same in the IT world and inthe mathematical world there are important differences in their meaning andinterpretation. Naturally, it helps in communication to define clearly what onemeans when using certain terms. But in reality there is more than just theterms and definition: there is a whole world of ideas and thinking behind theseharmless words. In supply chain projects bringing together SAP consultants,specialists customizing SAP APO, and mathematical model builders it is nec-essary to build some communication bridges before starting the project. Tosupport this process, we first want to create some awareness of the historicaland philosophical background of modeling.

The terms modeling or model building are derived from the word model. Itsethymological 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, ab-stract 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 geometryand especially Phythagoras around 600 B.C. distinguish between wheel andcircle, between field and rectangle. Around 1100 D.C. a wooden model of thelater Speyer cathedral was produced; the model served to build the real cathe-dral. Astrolabs and celestial globes have been used as models to visualize themovement of the moon, planets and stars on the celestial sphere and to com-pute the times of rises and settings. Until the 19th century mechanical modelswere understood as pictures of the reality. Following the principals of classicalmechanics the key idea was to reduce all phenomena to the movement of smallparticles. Nowadays, in physics and other mathematical sciences one will talkabout models if

• one, for reasons of simplifications, restricts oneself to certain aspects of theproblem (example: if we consider the movement of the planets, in a firstapproximation the planets are treated as point masses),

• one, for reasons of didactic presentation, develops a simplified picture forthe more complicated reality (example: the planetary model is used toexplain the situation inside the atoms),

• one uses the properties in one area to study the situation in an analogueproblem.

A model is referred to as a mathematical model of a process or a problem if itcontains the typical mathematical objects (variables, terms, relations). Thus,a (mathematical) model represents a real world problem in the language ofmathematics using mathematical symbols, variables, equations, inequalitiesand other relations.

It is very important when building a model to define and state preciselythe purpose of the model. In science, we often encounter epistemological ar-guments. In engineering, a model might be used to construct some machines.In operations research and optimization, models are often used to supportstrategic or operative decisions. All models enable us to

• learn and understand situations which do not allow easy access (very slowor 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 modelsin SAP APO and individual tailored optimization models differ most. Themodels in SAP APO support operative decisions for a set situation. It is notpossible to vary the situation completely and play around with all possibleideas (although SAP APO allows some scenarios to be investigated). A cus-tomized optimization model allows any numerical experiment one can thinkof (provided it is coded properly).

Both the standard SAP APO optimization model and tailored optimiza-tion 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 thefollowing sense:

• to avoid unwanted side products as much as possible,• to minimize costs, or• to maximize profit, earnings before interest and taxes (EBIT), or contri-

bution margin.

Regarding the purpose of a model we have to warn the reader or the consul-tants who want to use SAP APO or “own models” to be embedded to SAPAPO that in real life, especially in SAP IT structures, we might face a seriousproblem: the different purposes behind the SAP data model and the tailoredoptimization model. The model, or better the customizing of the mySAP ERPor SAP APO systems has often been developed or finished before anybodythought about using SAP APO to support an operative decision problem.This may lead to difficulties because – as we stated above – the model shouldalways be developed in such a way that one knows precisely what purposethe model should serve. And, as we see in the next section, in mathematicaloptimization data and concepts might be used differently than in the worldoutside mathematical optimization. In any case, it is necessary and very usefulthat the clients using the optimization components of SAP APO understandthe ideas behind the predefined models in SAP APO.

2.2 Mathematical Optimization

Optimization1 is a mathematical discipline analyzing and developing algo-rithms to solve optimization problems. In an optimization problem, one triesto minimize or maximize a quantity associated with a decision problem such aselapsed time or cost, by exploiting available degrees of freedom under a set ofrestrictions (constraints). Optimization problems arise in almost all branchesof industry, e.g., in product and process design, production, logistics, andeven strategic planning (see the list below). While the word optimization, innontechnical or colloquial language, is often used in the sense of improving,the mathematical optimization community sticks to the original meaning ofthe word related to finding the best value either globally or at least in a localneighborhood. For an algorithm being considered as a (mathematical, strict orexact) optimization algorithm in the mathematical optimization communitythere is consensus that such an algorithm computes feasible points provenglobally (or locally) optimal for linear (nonlinear2) optimization problems. In

1 Appendix B contains a deeper treatment of mathematical optimization.2 Note that this is a definition of a mathematical optimization algorithm and not

a statement saying that computing a local optimum is sufficient for nonlinearoptimization problems arising in industry.

24 2 Introduction: Models, Model Building and Optimization

the context of mixed integer linear problems (in this book we mostly considerthis class) an optimization algorithm (Grotschel, 2004, [32] and Grotschel,2005, [33]) is expected to compute a proven optimal solution or to generatefeasible points and, for a maximization problem, to derive a reasonably tight,non-trivial upper bound. The quality of such bounds are quantified by theintegrality gap discussed on page 291. It depends on the problem, the purposeof the model and also the accuracy of the data what one considers to be agood quality solution. A few percent, say, 2 to 3%, might be acceptable forthe example discussed on page 257. However, discussion based on percentagegaps become complicated when the objective function includes penalty termscontaining coefficients without a strict economic interpretation. In such casesscaling is problematic3; see also the example in Appendix B.2. For practicalpurposes it is also relevant to observe that solving mixed integer linear prob-lems and the problem of finding appropriate bounds is often NP complete(cf. Appendix B), which makes these problems hard4 to solve. This compli-cates developing standard software designed to be able to cope with a widevariety of optimization problems within an acceptable and predictable rangeof computing time. The simplex algorithm and the Branch&Bound methoddescribed in Appendix B are examples for optimization algorithms. Evolu-tionary algorithms (genetic algorithms fall into this group), metaheuristicsor constructive heuristics do not fall in this class unless they are coupledwith a bound generating method. In this book we refer to evolutionary al-gorithms and metaheuristics as improvement methods. In standard businesssoftware finding the optimum of a nonlinear or hard-to-solve problem is oftenapproached by using evolutionary algorithms/iterated search which – after apre-set maximum calculating time – in a wide variety of cases encountered inbusiness optimization return an acceptable solution in a vicinity of a local op-timum (hopefully) close to the global optimum. As these algorithms per se donot provide a proof of optimality or bounds, they can be used in conjunctionwith methods generating non-trivial bounds, which helps in judging the qual-ity of the solution. In industry, such a solution provided after a predictablecomputing time is what many clients expect from a standard software packagenot specific to their individual optimization problem.

Although the supply chain community usually uses the term optimizationnot in its original mathematical meaning, SAP APO contains strict opti-mization algorithms in the sense of the definition given above in some of itscomponents.3 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 thehighest priority goal, then one cares about the next level goal, and so on.

4 A consequence of this structural property is that these problems scale badly. Ifthe problem can be solved to optimality for a given instance, this might not be soif the size is increased slightly. While tailor-made optimization algorithm such ascolumn generation, Branch&Price techniques can often cope with this situationfor 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 weneed to represent our problem by a mathematical model, that is, a set ofmathematical relationships (e.g., equalities, inequalities, logical conditions)representing an abstraction of our real-world problem. This translation is partof the model building phase (which is part of the whole modeling process), andis 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 andapproximates the real world accurately enough. SAP APO contains alreadya predefined model saving us the work of developing a customized model(this holds not only for the optimizer, but also for the CP and evolutionaryapproaches in SAP APO). Usually, a model in mathematical optimizationconsists of four key objects:

• data, also called the constants of a model,• variables (continuous, semi-continuous, binary, integer), also called deci-

sion variables or parameters,• constraints (equalities, inequalities), also called restrictions, and• the objective function.

The data may represent cost or demands, fixed operation conditions of areactor, capacities of plants and so on. The variables represent the degreesof freedom, i.e., what we want to decide: How much of a certain productis to be produced, whether a depot is closed or not, or how much materialwill we store in the inventory for later use. Classical optimization (calculus,variational calculus, optimal control) treats those cases in which the variablesrepresent continuous degrees of freedom, e.g., the temperature in a chemicalreactor or the amount of a product to be produced. Mixed integer optimizationinvolves variables restricted to integer values, for example counts (numbersof containers, ships), decisions (yes-no), or logical relations (if product A isproduced then product B also needs to be produced). The constraints canbe a wide range of mathematical relationships: algebraic, analytic, differentialor integral. They may represent mass balances, quality relations, capacitylimits, and so on. The objective function expresses our goal: minimize costs,maximize utilization rate, minimize waste, and so on. Mathematical modelsfor 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 programmingcommunity, constraint programming (CP) shows increasing popularity andcan 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 SAPAPO 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 butit illustrates the wide range of possible applications (note that many have aconnection to supply chain optimization):

application area / problem type problem class

production planning (production, logistics, marketing) MILP, MINLPcutting stock problems (1D,2D) MILP, MINLPsequencing problems (putting activities into order) MILPscheduling (planning activities subject to resource limits) CPallocation problems (resources to orders, people to tasks) MILP, CPdistribution and logistics (supply chain optimization) MILPblending problems (production and logistics) (MI)LP, (MI)NLPrefinery planning and scheduling NLP, MINLPprocess design (chemical and food industry, refineries) MINLPengineering design (all areas of engineering) NLP, MINLPmarket clearing problems (energy markets) LP, MILP, NLPportfolio optimization (production, energy market, finance) MILP, MINLPselection and depot location problems (strategic planning) MILPinvestment and de-investment problems (strategic planning) MILPnetwork design (planning, strategic planning) MILP, MINLPfinancial problems (strategic planning) MILP, MINLP

2.3 The Main Ingredients of Optimization Models

Mathematical problems revolve around variables. Variables are used to modelthe decisions “how much”, “how many”, “what kind”, “where to”, “wherefrom”, and so on. Variables are often thought of in algebraic terms as repre-senting “unknown quantities”. Symbols such as x, y and z may be used todenote variables. These are commonly used in textbooks on algebra for “un-knowns”. However, in our work we want to make a distinction between whatis unknown and what is the direct result of a decision. Therefore, the variablesor unknowns are often thought of as “decision quantities” and are also calleddecision variables.5

For example, if a manager of a factory has to make a decision as to howmany trucks to dispatch at fixed 5 minute intervals, starting with the earliestat 08:30 a.m., then initially the planned departure time of the last truck isunknown. However, the final departure time is not a direct decision, but thetotal number of trucks to dispatch is. Once we know that 20 trucks are to bedispatched, the planned departure time of the last truck is known. Thus thekey 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 prob-lem situation. It may often be useful to pose questions such as “what doesthe decision maker need to know?” in order to identify what are the necessarydecisions and hence the variables of the model. In this part of the process weare 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: imple-mentation issues, conceptual aspects, and readability. The last point speaksfor 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 thinkof each variety of production at a particular location and in a particular timeperiod as totally separate from one another. Instead we think of a genericvariable, or array of variables, x, to model production and introduce indicesto indicate time period and location. The indices are linked with x and areused 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 timeperiods is numbered from 1 through to 12 and t tells us to which one we arereferring. Let l = 1, 2, 3, 4, 5 be the index for location. To be more precise, tis the index and {1, 2, ..., 12} is its index set representing time buckets of 12months, for instance. Similarly, l and {1, 2, ..., 5} accordingly. We then definextl 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 themodeler uses the subscripted notation as a shorthand way of writing.

Scaling up models can be handled easily when indices are used. The rangesover which the indices are allowed to vary are scaled down for prototypemodels and then ranges can be extended later. More than two indices canbe associated with a variable, but it is often found that notation becomesvery cumbersome when more than four subscripts and associated indices areused, particularly by a non-expert modeler. As an upper limit on indices isapproached it may be beneficial to rethink the nature of the variables. In anymodel the choice of which variables to use (not simply the choice of namesor characters to use to denote them) will not be unique and may depend onpersonal style.

When integers are used as subscripts the set of index values which a partic-ular 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 anindex set for locations which appears as l ∈ {Walldorf, PaloAlto, Shanghai}.

If we define the sets T = {1, 2, ..., 12} and L = {1, 2, ..., 5} we can formequivalent expressions such as

xtl ≤ 5 ; t ∈ T , l ∈ Lxtl ≤ 5 ; t = 1, 2, ..., 12 ; l = 1, 2, ..., 5xtl ≤ 5 ; ∀t , ∀l .xtl ≤ 5 ; ∀{tl}

.

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 readas “t is an element of set T ”, and ∀l means “for all l”. If xtl ≤ 5 should holdonly for certain index combinations we could write, for instance,

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

Conceptually, index sets represent the basic objects of a model. Dependingon the decision problem this can be products, sites, time buckets, transporttypes and other objects. Index sets provide the logical link between the math-ematical optimization model and the data model.

2.3.2 Data

Mathematical optimization models rely on data of consistent quality beingreadily available. This will not always be so. Indeed, collecting data is one ofthe most critical problems involved in solving large scale optimization prob-lems. It may be overly optimistic to assume that we can obtain informationon the costs of each of 17 stages of a production process. People we ask forinformation may not even be able to agree on a definition of cost let alonequantify aspects of it. Thus what we do will be a compromise, which may leadto a lack of user confidence in the model.

What we must do is to devise the best procedures we can for data collectionand see that procedures are adhered to if the model is going to be used repeat-edly on data which may change over time. New data must be collected underthe 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 obtainedunder certain assumptions and stress that results should still be helpful inproviding decision support provided appropriate caution is maintained.

Optimization tools should allow users to vary data by making use of sensi-tivity, post-optimality and ranging analyses which may go a considerable wayto 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 thisby recognizing that variables can be classified according to type. In mathe-matical programming the usual types of variables are:

• Continuous variables, x ≥ 0

These are non-negative variables which can take any value between zero andsome 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 continuousvariable 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 betweenzero and some specified finite upper limit. Throughout the book we use lower-case Greek characters for all integer variables or other special variables. Integervariables are introduced, for instance, into the model described in Section 6.2.2by 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 values0 or 1. Note that a binary variable, say δ, always obeys the weaker restriction0 ≤ δ ≤ 1 with upper limit 1. Such a restriction is called relaxation, or tobe more precise, a domain relaxation, and is a very useful concept to treatoptimization problems containing integer variables.

Binary variables are used to model decisions which have exactly two out-comes, e.g., to begin a project or to not begin it. In this instance we maychoose to associate the value “1” with the commencement of the project andthe value “0” with non-commencement. These associations are arbitrary andare decided on by the modeler. Notice that a binary variable models the logicof a decision, not necessarily an actual value which occurs in the client’s world.In many models continuous variables occur alongside binary variables, the bi-nary variables being used to model major dichotomies in the decision makingand the continuous variables modeling the consequences of these decisions.

There are other types of variables listed below, but their definitions maybe 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 valuebounded by X− and X+, i.e., x = 0 or 0 < X− ≤ x ≤ X+, where thelower limit X− is any positive number, X− > 0, and the upper limit X+ maytake the value infinity. These variables are used to model aspects of industrialprocesses where either nothing is produced or if anything is produced, it hasto 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 siteson different continents. They can ship goods from one site to another. Butif goods are shipped then the requirement is that at least, say, 50 tons, areshipped. Otherwise no transport is possible.

• Partial integer variables

Partial integer variables, also known as semi-integer variables, are variablesthat must be integral if they lie below some stated model-dependent value,otherwise they are considered to be continuous variables. They are a gener-alization of semi-continuous variables. The reason for having such variablesis that once a variable is larger than some stated value any fractional partassociated with it will be sufficiently small compared to the integer part ofits value that it may be regarded as relatively insignificant. Thus the variablecan be regarded as continuous once it is relatively large.

Binary, integer, semi-continuous and partial integer variables are oftenreferred 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 benon-negative unless otherwise stated. Sometimes, however,

• Free variables

are useful to represent quantities unrestricted in sign. They can take anypositive, zero or negative value. They are also called unconstrained variables.

In contrast to the earlier remark about variables usually being non-negative, free variables exist to model varying quantities such as “growth”,“change” or “net profit” where the desired value of a variable could be pos-itive or negative, or indeed zero. A free variable can be thought of as thedifference between two non-negative variables, e.g., x−y, and it is possible toavoid the use of free variables in models, but this will be unnecessary withinoptimization software packages.

It is not obligatory to use single letters to denote variables. In fact itmay 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 inmind that it makes mathematical relations more difficult to read). However,there is a trade-off between mathematical elegance and the use of mnemonicnames which might improve the understanding of a model, particularly tothose 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 cantake. 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 greaterthan or equal to. The relations < (less than) and > (greater than) cannot beused directly used due to the structure of the algorithms but can be modeledas described in Kallrath (2002, [51], Sect. 5.3).

In LP and MILP models, the left-hand side must be a linear expression inthe 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 orzero constant (coefficient)6 and the constant·variable items added together.Products or powers (e.g., xy or x5) of variables, or even functions of variablessuch as ex are not permitted in linear models. Thus typical constraints include

x + y + w = 122x − 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-constantterms on to the left-hand side of the constraint for input into the optimizationsoftware. In fact it is often convenient to use this style of constraint to clarifymodeling, e.g., in the constraint

new stock = old stock + production + purchases − sales

Using binary variables it is possible to model sophisticated logical relations orpiecewise linear functions, e.g., those in Sect. 8.2.4.1, as linear constraints. Asshown in Kallrath (2002, [51], Sect. 5.4) it is also possible to model the absolutevalue 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 rea-sonable objective function. Profit maximization or cost minimization may beappropriate, but sometimes more sophisticated accountancy measures such as“earnings before interest and taxes (EBIT)” may have to be used as objectivefunctions. 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. Someof these may involve maximization and some minimization and are likely toconflict, e.g., sales maximization and stock minimization may be desirablein a retailing environment but are in direct conflict. It will be best to elicitfrom a client some principal objectives and test how the solution to a modelimpinges on other objectives. Attempts at combining objectives and handling6 Conventionally variables with zero coefficients are omitted, so not all variables

are necessarily present in the expression. Also a coefficient of 1.0 is conventionallynot 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. How-ever, in LP or MILP models, ultimately an objective function must be a linearexpression in variables and must be maximized or minimized.

Two particular types of objective functions sometimes used in schedulingdeserve special consideration: Minimax and Maximin. Let us assume we wantto minimize the makespan of a set of jobs j ∈ J to be finished, i.e.,

min{

maxj∈J

{tj}}

, (2.1)

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 islarger than the completion time of all events, but is the minimal time valuethat satisfies that requirement.

The Maximin objective, max {minj∈J {tj}}, which is, loosely speaking, theopposite 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 thetime 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 occurringin mathematical optimization and which are relevant to the supply chainaspects related to SAP APO.

2.4.1 A Deterministic Standard MINLP Problem

Mixed integer nonlinear optimization problems are the most general classwithin algebraic optimization7. They are specified by the augmented vec-tor xT

⊕ = xT ⊕ yT established by the vectors xT = (x1, ..., xnc) andyT = (y1, ..., ynd

) of nc continuous and nd discrete variables, an objectivefunction f(x,y), ne equality constraints h(x,y) and ni inequality constraintsg(x,y). The problem

min{

f(x,y)∣∣∣∣h(x,y) = 0g(x,y) ≥ 0,

h : X × U → IRne

g : X × U → IRni ,x ∈ X ⊆ IRnc

y ∈ U ⊆ ZZnd

}(2.2)

7 Algebraic optimization models may contain products and explicit functions ofvariables 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 leastone of the functions f(x,y), g(x,y) or h(x,y) is nonlinear. The vector in-equality, g(x,y) ≥ 0, is to be read component-wise. Any vector xT

⊕ satisfyingthe 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 feasiblepoints is called an optimal solution. From this definition it follows that theproblem might not have a unique optimal solution.

Let us consider the following pure integer nonlinear problem with twointeger variables y1 and y2

miny1,y2

{3y1 + 2y2

2

∣∣∣∣ y41 − y2 − 15 = 0y1 + y2 − 3 ≥ 0,

y1, y2 ∈ U = IN0 = {0, 1, 2, ...}}

One feasible point is y1 = 3 and y2 = 66. All feasible points are given by(y1

y2

)=

(y1 = λy2 = λ4 − 15

), λ ∈ {2, 3, 4, ...} .

The optimal solution y∗ = (y1, y2)∗ = (2, 1) and f(y∗) = 8 is unique. Thereexists 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 getthe following structured problems known as

acronym type of optimization f(x,y) h(x,y) g(x,y) nd

LP Linear Programming cTx Ax − b x 0

MILP Mixed Integer LP cTx⊕ Ax⊕ − b x⊕ ≥ 1

MINLP Mixed Integer NLP ≥ 1

MIQP Mixed Integer QP xT⊕Qx⊕ + cTx⊕ Ax⊕ − b x⊕ ≥ 1

NLP Nonlinear Programming 0

GLOBAL Gobal Optimization ≥ 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 frequentlyto LP and MILP than to NLP or MINLP problems. QP refers to quadraticprogramming problems. They have a quadratic objective function but onlylinear constraints. QP and MIQP problems often occur in applications of thefinancial service industries.

2.4.1.1 Comments on Solution Algorithms

Since some problems occur as subproblems of others for obtaining a good per-formance it is very important that the algorithms to solve the subproblemsare well understood and exploited efficiently. While LP problems as describedin 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 approx-imately linearly in m), the computational complexity of MILP and MINLPgrows exponentially with nd but depends strongly on the structure of theproblem. Numerical methods to solve NLP problems work iteratively and thecomputational problems are related to questions of convergence, getting stuckin “bad” local optima and availability of good initial solutions. Global opti-mization techniques can be applied to both NLP and MINLP problems andits complexity increases exponentially in the number of all variables enteringnonlinearly into the model. It is understandable that the current release ofSAP APO does not consider NLP or MINLP models.

SAP APO offers several solution approaches to planning and schedulingproblems, among them MILP but also constraint programming (CP) andevolutionary algorithms. Thus, those active in problem solving need to knowa great deal about good modeling practice and how to connect models andalgorithms. For that reason, we strongly recommend that practitioners andconsultants obtain a deep understanding of the algorithms involved in SAPAPO and consult the technical documentation. The following table containsa series of books which we consider as valuable regarding the background ofalgorithms or in the context of solving real-world optimization problems:

LP problems Padberg (1996, [76])MILP problems Nemhauser and Wolsey (1988, [73]), Wolsey (1998, [101])NLP problems 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, therealso exists constraint programming often used for solving scheduling problems,and heuristic methods, better called metaheuristics, which can find feasiblepoints of optimization problems, but can only prove optimality or evaluatethe quality of these feasible points when used in combination with determin-istic approaches. Such methods include Simulated Annealing , Tabu Search (seeGlover and M. Laguna, 1997, [30]), Genetic Algorithms, Evolution Strategies,Ant Colony Optimization, and Neural Networks. These methods are not op-timization methods in the strict sense as they cannot prove optimality orgenerate safe bounds. However, for very hard problems, they can be used tofind feasible points of optimization problems. Section 10.2.1 discusses whenexact 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 simu-lation, we add some comments on the relationship between simulation andmathematical optimization. In contrast to simulation (parameter values arefixed by the user, feasibility has to be checked separately, no proof on op-timality), mathematical optimization methods compute directly an optimalsolution and guarantee that the solution satisfies all constraints. While inoptimization feasible solutions are specified a priori and implicitly by theconstraints, in simulation somebody has to ensure that only those combina-tions of parameter values are evaluated or considered which represent “ap-propriate scenarios”. There is another fundamental difference. Mathematicaloptimization deals with declarative representations of problems while modelformulations using simulation approaches appear much more procedural.

Optimization problems cannot be solved by simulation (also called para-meter studies), i.e., by evaluating the objective function and comparing theresults of various scenarios. Nevertheless, since experts of simulation tech-niques have developed intuition and heuristics to select appropriate scenariosto be evaluated, and simulation software exists to perform their evaluation,simulating a real world problem creates understanding and knowledge. Butthere is no guarantee that the optimal solution or even a solution close tothe optimum will be found. This is especially troublesome for complex prob-lems, or those which require decisions of large financial impact as the decisionproblem discussed in Sect. 10.2.1.

2.4.2 Multi-objective Optimization

Multi-objective optimization, also called multi-criteria optimization or vec-tor minimization problems, involves several objective functions. A simple ap-proach to solve such problems is to express all objectives in terms of a commonmeasure of goodness leading to the problem how to compare different objec-tives on a common scale. Basically, one can distinguish two cases. Either thesearch is for Pareto optimal solutions, or the problem has to be solved forevery objective function separately.

When minimizing several objective functions simultaneously the conceptof Pareto optimal solutions turns out to be useful. A solution is said to bePareto optimal if no other solution exists that is at least as good accordingto 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 requirethat all the objectives should come close to some targets, measured each in itsown scale. The targets we set for the objectives are called goals. Our overallobjective can then be regarded as to minimize the overall deviation of ourgoals 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 optimiza-tion problems in which targets are specified for a set of constraints. There aretwo basic approaches for goal programming: the preemptive (lexicographic)approach and the Archimedian approach.

In preemptive goal programming, goals are ordered according to impor-tance and priorities. It is recommended if there is a ranking between incom-mensurate objectives available. The goal at priority level i is considered to beinfinitely8 more important than the goal at the next lower level, i + 1, butthey are relaxed by a certain absolute or relative amount when optimizingfor 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 outputrate (i = 3). In the Archimedian approach weights or penalties are applied fornot achieving targets. A linear combination of the violated targets weightedby some penalty factor is added, or establishes the objective function.

Goal programming offers an alternative approach but should not be re-garded as without defects. The specific goal levels selected greatly determinethe answer. Therefore, care is need when selecting the targets. It is also im-portant 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 thebasic idea, as well as in Schniederjans (1995, [85]). The reader is also referredto 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 areassumed to be exact and deterministic; SAP APO is no exception. This as-sumptions leads to deterministic models. If the input data are subject touncertainty we are lead to optimization under uncertainty, i.e., optimizationproblems 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. Thoseuncertainties can arise for many reasons:

• Physical or technical parameters only known to a certain degree of accu-racy. Usually, for such input parameters safe intervals can be specified.

• Process uncertainties, e.g., stochastic fluctuations in a feed stream to areactor, 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 etal., 2004, [9]), or strategic design optimization problems (cf. Kallrath, 2002,[50]) involving uncertain demand and price over a long planning horizonof 10 to 20 years.

8 It would also be possible to define weights which express how much the ith ob-jective 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 facingconceptual problems such as identifying the stochastic nature of process en-tering the optimization model, or interpreting the results properly. Thus, isnot a surprise that it took until now that the number of applications using,for instance, stochastic programming is strongly increasing. A detailed reviewon optimization under uncertainty is provided by Kallrath (2005, [54]). Herewe provide just a light version of the main points found in this review.

The first step to model real world problems involving uncertain input datais 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 verycrucial that the assumptions are checked which are the basis of the varioussolution approaches. Below we list and comment on some techniques whichhave been used in real world projects or which one might think of to use.

• Sensitivity analysis is conceptually a difficult problem in the context ofMIP, and is, from a mathematical point of view, not a serious approachto solve optimization problems under uncertainty (Wallace, 2000, [99]).However, this approach can be successfully applied to an optimizationmodel embedded into a Monte Carlo simulation to establish how strongthe objective function values depend on fluctuation of some input data.If the problem can be solved to quickly optimality one could proceed asfollow. The problem is solved for a set of input data generated randomlyaround nominal values. The distribution of a few thousand input values ismapped to a distribution of objective function values.

• Stochastic Programming, in particular multi-stage stochastic models, alsocalled recourse models, have been used for a long time (cf. Dantzig, 1955,[14], Kall, 1976, [48], or Birge, 1997, [7]). In stochastic programming, themodels contain the information on the probability information of the sto-chastic uncertainty and the distribution does not depend on the decisionin most cases. While stochastic MILP is an active field of research (cf. thesurveys of Klein-Haneveld and van der Vlerk, 1999, [59] or Sen and Higle,1999, [87], and, more recently, in the Handbook of Stochastic Programming,Ruszczynski 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 constrainedprogramming problems and dates back to Charnes and Cooper (1959, [10]).A more recent overview on general chance-constrained methods is givenby Prekopa (1995, [78]).

• Fuzzy set modeling supporting uncertainties which fall into the class ofvague 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 rela-tively new approach to deal with optimization under uncertainty in casethat 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 (whichis, unfortunately, often the case in real world optimization problems).

• Decisions based on Markov processes (cf. Meyn, 2002, [69]) and/or thecontrol of time-discrete stochastic processes allow for decision-dependentprobability distributions but typically require stronger assumptions on thestochasticity. Cheng et al. (2003, [11]) give an excellent illustration of suchtechniques applied to design and planning under uncertainty.

Despite the conceptual difficulties, it is strongly recommended that if somedata, e.g., demand forecasts in planning models, or production data in schedul-ing are subject to uncertainties, one should consider whether the assumptionthat planning and modeling is exclusively based on deterministic data canbe discarded and uncertainty can be modeled. If probability distributions forthe uncertain input data can be provided, stochastic programming or chanceconstrained programming is the means of choice.

2.5 Implementing Models and Solving OptimizationProblems

2.5.1 Implementing Optimization Models

In the model building phase, real-world optimization problems are structuredaccording to their basic objects, variables, objective function and constraintsdiscussed in Sect. 2.3. There are several approaches to put such a model intothe computer:

• Programming or computer science approaches use a programming languagesuch as FORTRAN, C, or C++ to combine the model and the data andeither produce a matrix or other input file for a commercial solver, or eveninclude the solution algorithms in one program. In standard business soft-ware this approach is quite common because there is minimal to no needof changing the model in a client-specific way and keeping the model, thebusiness logic, and – probably – the solver together in one developmentenvironment reduces development complexity. Another advantage is keep-ing together application design and optimization development in one toolresulting in seamless applications. Disadvantages are the difficulty to un-derstand and to be read by others, the difficulty to maintain the code, andthe dependence on operating systems and compilers, to mention a few.

• In table or spreadsheet approaches the mathematical structure is extractedfrom table templates to be filled with data. In the past this approach wasoften found in software packages used in the process industry and especiallyrefineries. The models were usually confined to linear problems or nonlinearones with a very special structure. Those approaches are usually subjectto data management problems, they are restricted to two dimensions, andscale-up can be a tedious work.

2.6 Optimization and SAP APO 39

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

Based on what has been outlined we can summarize: in the optimizer SAPAPO contains a predefined model coded in the programming languages ABAPand C/C++. The detailed mathematical model formulation is not revealed bySAP, which is understandable from the commercial and intellectual propertypoints of view, but it may create a disadvantage because it makes the inter-pretation of the results very difficult. In addition, such concepts as reducedcosts 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 whichhas an algorithm implemented capable of solving the problem listed above.SAP APO uses ILOG’s CPLEX as the solver for LP and MILP problems. Inthe ideal case, the optimal solution is returned. In reality, when trying tosolve real-world problems, we often experience that a problem is returnedwith the statement “problem is infeasible”. Thus, as discussed in Sect. 8.2.6.1a modeling system should also support the identification of infeasibilities. Ithelps also to use a data consistency checker which reports hard infeasibilities orconflicting data. Nowadays optimization problems can also be solved directlyvia 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 eliminatesthe 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 optimiza-tion model and solution approach in the strict sense of mathematical opti-mization. This applies to SNP optimizer using the MILP solver CPLEX, whichtogether with Xpress-MP, is considered the best worldwide. Due to the natureof SAP APO as a standard business software tool its mathematical optimiza-tion model is predefined and designed to meet the requirements of as manyindustries as possible. It has been pointed out that the SNP model formulationis not open and thus is not easy to qualify the solution.

In other modules (e.g., CTM or finite scheduling in PP/DS) SAP usesconstraint programming and evolutionary algorithms which are both not con-sidered as mathematical optimization approaches without an in-depth analy-sis 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 (seeSect. 10.3.2) one has to take into account that SAP want to offer a scalableapproach working reasonably well in many application areas and industries.

Despite the availability of advanced modeling systems and modeling lan-guages (cf. Kallrath, 2004, [53]), SAP APO as well as other APS providershave coded their models in C or C++. May be taste has been triggered thisdecision, may be speed was a major issue when the decision had been madebetween choosing a modeling language or system compared to programminglanguages. With improved technology and hardware this has become less of anissue and now, some of the modeling systems have been drastically improvedfor speed and are very fast. The reason for preferring C or C++ may also liein the fact that in software companies such as SAP or i2 Technologies far morepeople are found with a computer science background than a mathematicalprogramming background. In the latter community modeling languages aremore 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, itis of less importance to the client whether the model has been coded in C orC++, or in a modeling language. However, if SAP APO would become openin the sense that the user can access the variables and constraints, a modelinglanguage would definitely be the better choice. A modeling language wouldalso make it easier to modify and extend the predefined model.

When discussing SAP APO (SNP) and comparing its optimization modelto customized models one has to appreciate and count positively for SAP thatthe developers managed to build a model which has reasonable scaling proper-ties and that this very model serves clients in completely different applicationareas and industries. Scaling properties means that the model and the as-sociated solver technology usually works for small problems as well as largeproblems. Serving different application areas means to comprise requirementsfrom different areas. A customized model does not need to pay attention tothese aspects because it is developed from scratch once for one purpose only.Therefore, it is understandable that in case a client wishes some model en-hancement of SAP APO great care and effort is required when SAP’s technicaland mathematical personnel is to modify and extend the model.

If the models and solution approaches embedded in SAP APO are used asthey are, the user does not necessarily need to know about the variables, in-dices etc. discussed in Sect. 2.3. The software produces the answer for a usernot familiar with mathematics. However, to interpret the answer it wouldstrongly help to understand the mathematics and, especially, the constraints.The more complexity is involved in a real world planning process the morecrucial it becomes to have personnel involved who can understand and appre-ciate this complexity and are not intimidated by it.

In order to give a more exhaustive picture of the way optimization is usedin commercial business software, in the following two chapters we will have acloser look at how “modeling” is done in SAP APO SNP.

3

Model Building in SAP APO Supply NetworkPlanning

Starting point of supply chain optimization in SAP APO is a supply chainmodel. Within this model so-called master data defines the detailed structuresuch as the number and types of locations and products. Transportation lanesdefine possible goods movements between locations, the respective durations,costs, etc. Setting up a supply chain model as described in this chapter largelyrefers to SNP in general no matter whether the optimizer, constraint propaga-tion 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 bythe different algorithms so that the user has to be carefully following the doc-umentation or – and this is still the best method after years of SAP APOavailability in the market – try out different settings.

This part of the book is kept rather brief in order to focus on optimizationrather than master data setup issues. We refer to the literature such as Dick-ersbach (2004, [17]) and Bartsch and Bickenbach (2002, [4]) for more thoroughexplanations regarding the SAP APO master data concept.

The intention of this chapter is to serve as a recipe on how to quickly setup an SNP supply chain model that can be used for optimization. Chap. 4continues the cookbook by using the results from this chapter for an actualoptimization run preceded by a discussion of the various profiles that influencethe structure of the (MI)LP itself. Readers familiar with setting up a supplychain model in SAP APO and not intending to reproduce our example intheir system right away may postpone reading this chapter and skip forwardto Chap. 4.

We use a very simple example supply chain model and show how to formu-late it in SAP APO step by step. We do not claim to include all aspects andfacets of SAP APO setup and certainly do not intend to deliver an alternativeto the SAP APO application documentation. Having said that, anyone withsome basic familiarity with the SAP user interface SAP R© GUI should be ableto implement our little example.

SAP is the only business software provider known to the authors thatmakes 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 ex-tensive than the Encyclopedia Britannica. The SAP APO section can be foundat http://help.sap.com/ in the section Documentation → mySAP BusinessSuite → SAP Supply Chain Management. We expressly encourage the inter-ested reader to refer to this documentation.

As the actual model equations defining the LP and MILP models in SAPAPO are intellectual property of SAP they are among the best-kept companysecrets. Therefore we cannot state our little example model in its mathematicalnotation 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 externalsourcing partners. As simple as it might look, the problem is a good start-ing point for experimenting with the SAP APO optimizer and still providesquick results. The objective function of the (MI)LP model is designed to re-duce inventory, optimize production quantities, and optimize procurement ofcomponents while maximizing the customer service level. Technically, the ob-jective is to create a least cost production plan considering the demands, theconstraints, 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 in-troduce 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. P1is the high-grade and expensive product, P2 and P3 are mid-grade and low-grade products, respectively. The company has three customer regions withhomogenous 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 industrialkey customers). All three products are made in the factory F1 which has oneproduction line represented by resource R1. As producing any of the productsconsumes a certain amount of capacity on the production resource R1 allthree products compete for available R1 capacity.

Figure 3.1 shows the structure of this example supply chain we want toimplement in SAP APO demonstrating the SNP optimizer setup. As we do

3.1 The Example Supply Chain Model 43

P1 P2 P3

F1

C1

C2

C3

X1 X2

S1

X1

S2

R1

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 rep-resenting the permissible goods movements, modeled as transportation lanesas we will see a bit later. The customers C1, C2, and C3 can order any of theproducts P1, P2, and P3. We do not model static sourcing assignments forcomponent X1, but let the optimizer decide whether to source it from S1 orS2. Figure 3.2 shows the locations and possible transportation relationshipson 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 requiredand planned with SNP. The prime supplier of the company is S1 who candeliver both components, but has limited availability of X1. As a backup thecompany uses a second supplier, S2, for component X1 who charges a higherprice for it (cf. Table 3.1). In the model limited supply of X1 from supplierS1 is represented as a constraint limiting the transportation quantity of rawmaterial X1 from S2 to the factory F1 as we will see shortly.

Incoming customer demand and/or demand forecasts drive the planningprocess. As mentioned earlier, the goal is to minimize total cost which isgiven as the sum of production cost, procurement cost, storage cost, and thepenalties for delayed delivery or lost customer orders (no delivery). Whenevera customer cannot be serviced within a time of 30 days after the demand duedate a sale is regarded to be lost and the no delivery penalty incurs. Table 3.2summarizes the product-specific costs in the model.

44 3 Model Building in SAP APO Supply Network Planning

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

LocationProduct S1 S2 F1

X1 60 80 1000X2 30 - 1000

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

ProductCost type P1 P2 P3 X1 X2

Production [cu/piece] 25 15 15 - -Delay penalty [cu/(piece · day)] 10 5 5 - -No delivery penalty [cu/piece] 350 250 180 - -Storage [cu/(piece · day)] 2 1 1 0.5 0.5

Table 3.2. Location independent costs in the supply chain example (cu . . . cur-rency unit). Delay and no delivery penalties only apply to customer locations wheredemand is created

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

3.1 The Example Supply Chain Model 45

ResourceR1 T1

Normal capacity 8 h/day 1000 pieces/dayExtended capacity 16 h/day -Capacity expansion cost 2000 cu/h -

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

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

ProductP1 P2 P3

Material consumption X1 [pieces] 3000 2000 1000Material consumption X2 [pieces] 1000 1000 1000Resource consumption R1 [hours] 6 4 4Processing time [days] 1 1 1Production output [pieces] 1000 1000 1000

Table 3.4. Production process data in the supply chain example. The values referto a product base quantity of 1000 pieces, e.g., it takes six hours of R1 capacity tomake 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 foritself.

3.1.3 A Mathematical Formulation of the Example Model

As an illustration for optimization practitioners, in the following paragraphswe 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 T1S1 F1 yes: X2 noS2 F1 no noF1 C1 no noF1 C2 no noF1 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 inmind that this does not describe how the model is built in the SNP optimizerbecause the mathematical model in SAP APO is not public!

We start by stating the sets of indices which define the domains of theinput data, variables, constraints and costs included in the model. Unlike inthe subsequent model formulation where we will stick to the mathematicalformulation without filling in the example data, we here also give the setelements in this particular example:

C := {C1, C2, C3} : customersV := {S1, S2} : vendors (suppliers)F := {F1} : plantsX := {X1, X2} : componentsY := {P1, P2, P3} : finished products

p ∈ P := {P1, P2, P3, X1, X2} : productsr ∈ R := {R1} : resource(s)l ∈ L := {S1, S2, F1, C1, C2, C3} : locationst ∈ T := {1, . . . , NT } : time bucketsd ∈ D := {1, . . . , ND} : demands

The data stored in the database need to be prepared and processed in suchway that they can be used as the input data in this model. Note that thestructure of data fields is dominated by the purpose they are used for, andtherefore there might be structural differences between the data in the datamodel and those required by the mathematical model.

First, we deal with the demand data and prepare for using late deliveryand non-delivery penalties. We use the index d ∈ D to refer to individual de-mands that in the “ERP domain” are defined as (product, customer location,time bucket, quantity) quadruples. More detailed input data (in time) is to beaggregated accordingly. The vector Dd holds the quantity of demand d. Indi-cator tables provide the link between “ERP-like” demands and our indexeddemand quantities: the elements of the indicator table IP

pd are 1 if demand d

is for product p and 0 otherwise , and ILld is 1 if demand d occurs at location l

and 0 otherwise. Note that for each demand d exactly one of each IPpd and IL

ld

are 1. Taking the length of the time buckets, the late delivery and non-deliverycosts into account, the tables CL

dt and CNd 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 tothe maximum delay there is a time bucket TD

d for each demand d after whichno further deliveries are possible and a non-delivery penalty needs to be paidfor the open quantity:

Dd : quantity of demand dIPpd : 1 if demand d is for product p (unique), otherwise 0

ILld : 1 if demand d is at location l (unique), otherwise 0

CLdt : cost of late delivery of demand d in time bucket t

CNd : cost of non-delivery of demand d

TDd : 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 ofcomponent p′ needed for making product p. The table Rpr defines the resourcecapacity consumption of resource r for making one unit of product p. In casewe want to consider lot sizes in production, we will also need the lot sizes ofthe products Lp, given in units of product p. Making one unit of product phas the cost CP

p associated to it:

Bpp′

{≥ 0 , (p ∈ Y, p′ ∈ X )= 0 otherwise

Rpr

{≥ 0 , (p ∈ Y)= 0 otherwise

Lp : lot size of product pCP

p : production cost

The resources r (in our example there is only one) offer a standard capacityRC

r and extended capacity RXr . Utilizing the resource with a load between RC

r

and RXr involves a capacity expansion cost of CX

r 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):

RCr : standard capacity of resource r

RXr : extended capacity of resource r

CXr : capacity expansion cost of resource r

Storing one unit of product p leads to the storage costs CSp , per time period :

CSp : storage cost of product p

Procuring one unit of product p at location l incurs procurement costs givenby CP

lp:CP

lp : procurement cost

There is a limit TXll′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

TXll′pt : capacity of transportation lane l → l′, for product p, time bucket t

Finally, we provide the initial stock level, S0lp, of product p at location l:

S0lp : 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 produc-tion as integer variables αlpt. The blpt variables are used for modeling productconsumption by production processes and the variables fdt are used to trackfulfilment of each demand d for calculating late and non-delivery penalty costs:

αlpt : production at location l in lots of product p in time bucket tblpt : production consumption at location l of product p in time bucket tslpt : stock at location l of product p at the end of time bucket t, slp0 := S0

lp

tll′pt : transport volume from location l to l′ of product p in time bucket tdlpt : delivered product at location l, product p in time bucket tfdt : delivered quantity to satisfy demand d in time bucket trlpt : external purchase at location l of product p in time bucket tcrt : used capacity of production resource r in time bucket tc′rt : used extended capacity of production resource r in time bucket t

Because of the choice to aggregate suppliers, plants, and customers into loca-tions, and components and finished goods into products we have to introducea number of additional bounds (a good modeling tool or the solver’s presolv-ing technology will exploit these bounds and will eliminate variables wherepossible). 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 thecustomer locations, i.e.,

slpt = 0 ; ∀l ∈ C , ∀{pt} .

Transportation is only allowed from suppliers to plants for components andfrom plants to customers for finished products. Additionally, it is necessarythat the products exist at both ends of the transport connection (see thecomment 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 locationsand plants (cf. Table 3.1):

3.1 The Example Supply Chain Model 49

rlpt = 0 for l ∈ C , ∀{pt}rlpt = 0 for p ∈ Y , ∀{lt} .

In addition to these domain restrictions, note that all variables are only cre-ated for existing combinations of location and product. Component X2, forinstance, 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 an-other index table included in the bounds above. For readability reasons we donot state these bounds in the equations, however.

The material balance models the material flow:∑l′

tl′lpt+Lpαlpt+slp,t−1+rlpt =∑l′

tll′pt+dlpt+slpt+blpt , ∀{lpt} (3.1)

The left-hand-side of (3.1) contains the ingoing material flow into a nodebalance point ∀{lpt}: inbound transport, production, stock level at the endof the previous time bucket, and external purchase. The right-hand-side of(3.1) contains outbound transport, demand fulfillment, the stock level of timebucket t, and the consumption of component p by production processes.

The deliveries dlpt are used to satisfy demand, which is captured in fdt:

dlpt −∑

d

ILldI

Ppdfdt = 0 , ∀{lpt}

∑t

fdt ≤ Dd , ∀d .

Note that several terms ILldI

Ppdfdt can contribute to the delivery variable dlpt,

i.e., one delivery dlpt can contribute to satisfying multiple demands “of differ-ent age” for product p at customer location l. No further deliveries are allowedafter the maximum delay time bucket TD

d :

fdt = 0 , ∀{dt|t > TD

d

}.

Let us explicitely formulate the production process now. We start with con-suming components blp′t defined by the bill of material (BOM) coefficientsBpp′ :

Lpαlpt =∑p′

Bpp′blp′t , ∀{lpt}

and continue with the resource consumptions:∑p

RprLpαlpt = crt , ∀{lrt}

crt ≤ RCr + c′rt , ∀{rt}

crt ≤ RXr , ∀{rt}

Finally, the transportation volume constraint in Table 3.3 is formulated:

50 3 Model Building in SAP APO Supply Network Planning

tll′pt ≤ TXll′pt , ∀{ll′pt} .

Note that the time-dependence of TX is not used in this example (it couldbe used to modeling river shipment with varying water levels in winter andsummer, for instance). For the objective function, in this example minimizingtotal cost, we add the cost of late delivery, CD,

CD =∑

d

∑t

CLdtfdt ,

the cost of non-delivery, CN ,

CN =∑

d

CNd

(Dd −

∑t

fdt

),

the total production cost, CP ,

CP =∑

l

∑p

∑t

CPp Lpαlpt ,

the total procurement cost, CB ,

CB =∑

l

∑p

∑t

CPlprlpt ,

the total capacity expansion cost, CX ,

CX =∑

r

∑t

CXr c′rt ,

and the total storage cost, CS ,

CS =∑

l

∑p

∑t

CSp slpt .

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

min z , z := CX + CP + CS + CB + CD + CN .

As mentioned above the purpose of this model is to provide an illustration ofhow 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 asthe 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 isset 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 chainmodel 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 systemssuch 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 willstate the SAP APO transactions which we use as menu paths in the SAP SCMsystem. The release we used for the menu paths and the screen shots is SAPSCM 4.1 SP 4. For quick access via the command field in the SAP GUI therespective transaction codes are given in parentheses. From anywhere withinthe SAP APO system a transaction can be reached by preceding the transac-tion code with “/n”, for example enter “/n/SAPAPO/MVM” for getting toModel and Version Management.

Before we start with creating the master data and setting the parametersfor an SNP planning run we would like to mention that many settings can bedefined in a time-dependent fashion. The scrap value of a production processcan decrease with time to model yield learning curves in production, for in-stance. Another example is phasing certain components in or out. For the sakeof brevity and clarity we do not discuss these features here and refer to theproduct 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 pro-duction processes in SAP APO. SAP recommends to use the PDS for newSAP APO implementations and for upgrade projects, but continues to sup-port the PPM data model. As for our purposes there is no significant differencewhether we use PDS or PPM in our example supply chain model we will stickto the well tried production process model (PPM). This way readers who haveaccess 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 orPPM is used because both are representations of the production process; thedifference is primarily in how the underlying data are entered, how they arecreated, 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 datadefining the supply chain such as locations, transportation lanes, products,resources, and production process models. It is created in SAP APO Modeland Version Management at the menu path Advanced Planning and Opti-mization → Master Data → Planning Version Management → Model and1 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 dataelements 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 dif-ferent supply chain models and planning versions in the system.

By pressing the Create button (looking like an empty sheet of paper, seeFig. 3.3) and selecting Model from the appearing drop-down menu a newmodel is created (we call our example model SIMPLE ). The only parame-ters for creating the supply chain model object are the model name and adescribing short text.

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

For each model at least one planning version must exist. Planning versionscontain a selection of data for the actual planning process and – unlike themodel that contains master data – the version holds transactional data such asforecasted demand, customer orders, or planned production orders, for exam-ple. Additionally, some version-dependent properties of products, locations,and resources are stored in the planning version allowing it to easily createsimulation versions for what-if analyses. Examples of such version-dependentdata are penalty costs for unfulfilled customer demand which we will uselater. A planning version is created in the Model and Version Managementtransaction by selecting the model and choosing Planning Version from thedrop-down menu of the Create button (see Fig. 3.4). The model/version pa-rameters are relevant for SNP and other planning modules. For our purposeswe check the box next to Local Time Zone because we will use location timezones different from UTC. The other SNP parameters remain at their defaultvalues 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 in-house. Leaving the box unchecked results in the optimizer creating plannedproduction orders for those products without reference to a PPM (for adescription of production process models or PPMs see Sect. 3.2.5). In our

3.2 Supply Chain Model Master Data 53

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

example it does not make a difference whether this feature is activated ornot and hence we do not change the default value.

• Consider Stock Transfer Horizon of Source Location affects CTM planningonly.

If SAP APO is to be used in connection with an ERP system such as mySAPERP it is important to know that only one model and one planning versionreceive data from the other systems. These are called active model and activeplanning version. Other models and versions are typically used for simulationplanning runs before the actual operative results are transferred to the exe-cution system (by copying the respective model/version into the active one,for instance). The active model and version are always called model 000 andplanning version 000. As we do not use mySAP ERP integration in our ex-ample we will work in the SIMPLE model and version. For more informationon integrating SAP APO with mySAP ERP via the Core Interface (CIF), seeDickersbach (2004, [17]).

3.2.2 Locations

Locations correspond to physical entities of the modeled company and/orbusiness partners and can have different types such as production plant, dis-tribution center, supplier, or customer. Since SAP SCM release 4.0 suppliers

54 3 Model Building in SAP APO Supply Network Planning

are called vendors. The path for maintaining locations in SAP APO is Ad-vanced Planning and Optimization → Master Data → Location → Location(/SAPAPO/LOC3). Apart from the location code and a descriptive text, nec-essary data entries are location type, time zone, and calendar. If – like inthe example – the address of the location is given by specifying at least thecountry, the time zone and certain data pertaining to transportation will besuggested by the system. Figure 3.5 shows the location maintenance screenwith the address tab selected, Table 3.6 the individual locations that have tobe created in our example.

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

Location Location Type Country Region/City

S1 Vendor Hungary BudapestS2 Vendor Italy MilanF1 Production Plant Austria ViennaC1 Customer France ParisC2 Customer Germany BerlinC3 Customer Switzerland Zurich

Table 3.6. The locations in the example supply chain model

Note that upon creation the location is created for the active planningversion 000. As the version-specific location data are intended for TP/VS2

we do not need to take care of setting special version-specific parameters2 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 locationdata is version-specific, go to the location master entry screen, press the SetPlanning Version button, choose a planning version (such as SIMPLE ) andselect Change. All but the version-specific fields in the location master datawill be read-only.

We do have to assign the locations to the model SIMPLE, though. Werecommend doing this in one process for all master data later on instead doingit from each individual master data maintenance screen. We will demonstratethis process in Sect. 3.2.6.

3.2.3 Products and Location Products

SAP APO distinguishes between product properties that depend only on theproduct itself and those that additionally depend on the specific locationwhere a product may reside or be processed. An example for “global” productdata is the product code that is a company-wide (or – in this context – asupply chain-wide) constant, a location-specific property may be storage cost.An important attribute for a location product is the procurement type thatdetermines whether a product can be produced at a specific location or not.Via the procurement type planning algorithms determine whether to look forsupply from other locations, from production, or whether to just assume thatdemands are handled externally.

In our little example we use three end products (P1, P2, and P3 ) manu-factured from two different components X1 and X2. Consequently, these fivedifferent products can occur at different locations in the supply chain, whichresults 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 productionprocesses look like – the location product master data defines only propertiesof products at specific locations and does not contain bill of material or routinginformation.

In SAP APO each location product needs to be created. We create thelocation products in two steps: first the planning version-independent dataand then we create the location product for the planning version SIMPLE andadd version-dependent parameters. The menu path for maintaining product-related data in SAP APO is Advanced Planning and Optimization → MasterData → Product → Product (/SAPAPO/MAT1).

In the first step we maintain the product codes, descriptions, units ofmeasure, and the procurement types (see Figs. 3.6 and 3.7).

56 3 Model Building in SAP APO Supply Network Planning

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

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

Procurement types determine whether the planning algorithm will try tomanufacture the product at the specified location (type E ), source it fromanother location involving transportation (type F ), or choose either alterna-tive depending on costs or other supply chain settings (type X ). Type P isused for products not planned in SAP APO; e.g., it is used in CTM modelsat supplier locations, in our optimization example we use procurement typeF instead. Table 3.7 gives the data to be used when creating the locationproducts.

In order to implement the costs and (soft) constraints explained earlierin Sect. 3.1.2, there are some planning version-dependent location productattributes to be maintained. These include procurement costs, storage costs,and penalties for late delivery and no delivery along with the maximum orderdelay that distinguishes between late and no delivery. The location productprocurement costs are also used for calculating penalties for expired productquantities 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 FX1 S2 FX1 F1 F

X2 S1 Component X2 PC FX2 F1 F

P1 F1 Product P1 PC EP1 C1 FP1 C2 FP1 C3 F

P2 F1 Product P2 PC EP2 C1 FP2 C2 FP2 C3 F

P3 F1 Product P3 PC EP3 C1 FP3 C2 FP3 C3 F

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 costis interpreted as the revenue generated by selling one unit of the respectivelocation product for optimizing profit or contribution margin.

For creating the location product for our planning version SIMPLE, selectthe planning version on the product master entry screen via the Choose plan-ning 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 procurementand storage costs for component X1 at the supplier S2 and Fig. 3.9 showsmaintaining the delivery penalties. The units of measure are currency units

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

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, currencyunits 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 thanthe maximum delay value the demand is dropped and the no delivery penaltyincurs.

Product X1 X2Location S1 S2 F1 S1 F1

Procurement cost 60 80 1000 30 1000Storage cost 0.5 0.5 0.5 0.5 0.5

Product P1 P2 P3Location F1 C1, C2, C3 F1 C1, C2, C3 F1 C1, C2, C3

Storage cost 2 2 1 1 1 1Delay penalty - 10 - 5 - 5No delivery penalty - 350 - 250 - 180Maximum delay - 30 - 30 - 30

Table 3.8. The version-specific costs for the location products in the example supplychain. See text for units and more information

Each location product has to be created and maintained in our planningversion SIMPLE. For clarity, we summarize the cost information relevant forlocation products from Sect. 3.1.2 in Table 3.8.

We suggest maintaining the penalty costs at a detailed location product-specific and demand category level like in Fig 3.9 in order to leave room foreasy 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 demandforecasts 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 resourceR1 at the production plant F1 and one transportation resource T1 that weuse 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 → Re-source → Resource (/SAPAPO/RES01) leads to the resource maintenanceentry screen. In the example in Fig. 3.10 we look at resource T1 in our plan-ning version SIMPLE.

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

Clicking the Create button leads to a form like in Fig. 3.11 in which theresource attributes are defined. In this context it is important to select thecorrect tab before entering data in order to create a resource of the righttype (Transportation for T1 and Bucket for R1 ). For production processes inSNP 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 thisscreen. All the non-listed attributes remain at their default values (e.g., wecould change the capacity utilization rate to model the effect of breaks, ex-pected machine downtime, overtime, etc.). Factory calendar 99 is a predefinedcalendar including international holidays, AT corresponds to the country thefactory F1 is located in.

60 3 Model Building in SAP APO Supply Network Planning

Fig. 3.11. Resource master data in SAP APO. c© SAP AG

ResourceT1 R1

Category T PLocation - F1Time zone CET CETBucket dimension MASS TIMEFactory calendar 99 ATBucket capacity 1000 8Unit KG HNumber of periods 1 1Period type Day DayDays – 30 30Days + 180 180

Table 3.9. Resources in the example supply chain model

The capacity in SNP is defined by planning time bucket which by definition isone day. Consequently, R1 is available for eight hours a day, T1 can transport1000 kg per day. If, for instance, one transportation turn takes only six hours,a transportation process executed on resource T1 can transport four times1000 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 lanecapacity 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 theproduction capacity of R1 such as defined in Sect. 3.1.2. In order to model thisfeature we define a capacity variant of R1 with associated penalty cost. First,we create and save a Quantity/Rate Definition via the Definitions button inthe 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 entrycorresponds to a maximum extended capacity of 16 hours a day (instead ofeight hours in normal mode) for the cost of 2000 currency units per hour.

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

Now the quantity/rate definition is assigned to a capacity variant of R1 viathe Capacity Variants button in the master data screen of R1 (cf. again thescreen in Fig. 3.11). Pressing the + Interval button lets you add a capacityvariant. The variant identification for extended capacity is 79 and referencesthe quantity/rate definition from before. Figure 3.13 sketches the capacityvariant screen after adding MAX CAPACITY. The other two variants on thescreen 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 andrepresents the probably most complex master data object in SAP APO. Itcombines information from the bill of material (BOM) listing the componentsa product consists of and the routing that defines what production steps arenecessary along with the respective resource usage to make the product. Thecomponents in the PPM correspond to BOM data whereas data relating toresources define the modes of a PPM. As outlined in Fig. 3.14, a PPM isorganized in operations and activities and the components and modes areassigned 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 themathematically optimal solution would suggest to close it.

62 3 Model Building in SAP APO Supply Network Planning

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

Input materials

Operation 1

Activity 1

Res. a, b,..

Output materials

Operation n

Activity 1

Res. c, d,..

Input materials Output materials

Fig. 3.14. Schematic structure of a PPM. Input and output materials are also calledcomponents, 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 thePPM 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 SAPAPO 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 definingthe production process of the product P1 in location F1. The menu path toPPM 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 asshown in Fig. 3.15 – in our case the Plan field contains PPM P1 and Use ofa 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

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

Clicking the Create button leads to the screen for maintaining the PPMsuch as Fig. 3.16 shows – with the exception that the PPM will not contain anyobjects 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 twowindows for navigating between the different elements of the PPM via a menutree 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 maintenancetransaction instead of moving around inside the PPM. Remember to alwaysuse the PPM-internal navigation for such tasks by using the menu tree, thegraphical diagram or the buttons that appear at different locations throughoutthe PPM user interface.

On the initial screen we first name the plan by filling out the Descriptionfield 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 abase quantity of 1000 pieces in the PPM when we define the components andmodes a cost of 25,000 for using the PPM has to be entered in the SingleLevel Costs – Variable field in Fig. 3.16.

In the example we use just one operation that is created by typing in itsname in the Operations sub-window. Double-clicking on the name of the op-eration leads to the operations and activities view shown in Fig. 3.17, alreadywith one activity of type P (for produce) and zero scrap entered. Availableactivity 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 thesetup 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 sideshowing the operation, activity, and the associated mode and components. c© SAPAG

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

on the activity name, leads to the next screen where components and modesare defined.

3.2.5.2 Components

On the component view screen (Fig. 3.18) we define the products that areinvolved in the production process of the activity.

Products consumed are classified as input products (I/O Indicator setto I ) and products in which the production process results are called out-put products (I/O Indicator set to O). Co-products are modeled by enteringmultiple output products.

3.2 Supply Chain Model Master Data 65

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

The Consump. Type field defines when the components are consumed oroutput. Available values are S for consumption at the start, E for consump-tion at the end of the activity, and C for continual consumption. We chooseto assign input products the consumption type S and output products theconsumption type E.

The validity period for the individual component definitions is given bystating the from and to dates which we chose such that no time dependenciesexist in the planning period.

Finally, the component quantities have to be defined which at the sametime define the base unit of the PPM we used for calculating the productioncost. In our example we choose 1000 pieces as the reference quantity. Accordingto the material consumptions in Table 3.4 (p. 45) we enter 1000 for P1, 3000for X1, and 1000 for X2 in the Var. Consumptn field. Please note that theline for X2 is missing in Fig. 3.18 because the SAP APO GUI always displaystwo 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 sectionof the activity, we still need to define the resource consumption and processdurations by selecting the Mode tab in Fig. 3.18.

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

66 3 Model Building in SAP APO Supply Network Planning

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

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

Double-clicking in the mode line continues to the mode view where actualresource capacity consumptions are maintained (Fig. 3.20). Following the datain Table 3.4, we define six hours of R1 capacity to be consumed by makingthe 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 theproduction process defined in Sect. 3.1.2: It takes one calendar day to make1000 pieces of P1, but only six hours production resource capacity.

This step concludes the operation and activity maintenance in our ex-ample. As we only model one operation there is no need to define how theindividual activities are connected. These activity relationships are somewhatsimple in SNP in the sense that only a single chain is allowed resulting in eachactivity (other than the single first and single last activity) having exactly onepredecessor and one successor.5

5 If necessary, the relations can be defined via the Activity Relationshps button onthe 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 productthe PPM is assigned to and a number of other general parameters. Pressingthe 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 betterreadability two parts are pasted together. c© SAP AG

As distinguishing the “Plan” and “PPM” objects is not easy in SAP APO wechoose the same name PPM P1, product P1, a large validity period, planninglocation F1, and a large lot size interval the entry shall be valid for. Bydefining different validity periods or lot size intervals we could model differentproduction processes depending on time or on the quantity of goods to beproduced, respectively. Checking the Discretization box allows optimization-based planning runs that result in integral multiples of the PPM referencequantity; in our case we will produce in integer multiples of 1000 pieces inone scenario. Another optimization-relevant field is Bucket Offset containinga rounding value for determining the availability date of a receipt within atime 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 savingand activating involve a consistency check which reports certain issues aswarnings to the user or error messages preventing activation. Fig. 3.22 showswhich 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 byconfirming the message because PP/DS is not used in our example.

After activating and saving we successfully created a production processmodel 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 linkedPP/DS plan. c© SAP AG

3.2.5.6 PPM Data in the Example Model

Along the lines of the last paragraphs we created the PPM for the productP1, but we need to get two more that define the production process for theremaining products P2 and P3. For each of the PPMs, the following procedureapplies:

1. Create the general PPM data consisting of the header as given in Ta-ble 3.10 and the one operation 0010 Produce and activity 10 Produce oftype P.

FieldPPM Use Description Single Level Costs

PPM P1 S Simple PPM for Product P1 25,000PPM P2 S Simple PPM for Product P2 15,000PPM P3 S Simple PPM for Product P3 15,000

Table 3.10. PPM header data in the example model

2. In the activity, create entries in the components section for the outputproducts P1, P2, or P3, respectively, and the components X1 and X2 aslisted in Table 3.11.

3. In the activity, create a mode 10 with primary resource R1, unit of mea-sure D, and fixed duration 1. In the mode, maintain the variable bucketconsumption as given in Table 3.12.

3.2 Supply Chain Model Master Data 69

FieldVariable

PPM Component I/O Indicator Consumption Type Consumption

PPM P1 P1 O E 1000X1 I S 3000X2 I S 1000

PPM P2 P2 O E 1000X1 I S 2000X2 I S 1000

PPM P3 P3 O E 1000X1 I S 1000X2 I S 1000

Table 3.11. PPM component data in the example model

FieldVariable

PPM Unit of Measure Bucket Consumption

PPM P1 H 6PPM P2 H 4PPM P3 H 4

Table 3.12. PPM resource capacity consumption data in the example model

FieldProduction Planning Maximum

PPM Process Model Location Discretization Lot Size

PPM P1 PPM P1 F1 × 9,999,999PPM P2 PPM P2 F1 × 9,999,999PPM P3 PPM P3 F1 × 9,999,999

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 planmentioned 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 supplychain model created in Sect. 3.2.1. This assignment can be done directly fromthe master data maintenance screens via the Assign model button or menuentry similar to setting the planning version, but then the same procedurehas to be applied to each of the locations, location products, resources, andproduction 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 modelis to use the Supply Chain Engineer. Besides visualizing the master data thistool helps in adding the master data elements to a supply chain model andprovides an easy way to view the model elements all in one place. It is notnecessary to use the Supply Chain Engineer during model setup, but it isessential that all relevant master data is assigned to the supply chain model.

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

Selecting Advanced Planning and Optimization → Master Data → Sup-ply Chain Engineer → Maintain Model (/SAPAPO/SCC07) and entering themodel name and a work area6 on the following screen (see Fig. 3.23) followedby 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 upperpart is displaying a world map which shows the locations and transportationlanes once objects are added to the work area and the lower part displaysthe master data elements of the work area. Objects in the work area that arenot part of the model are displayed differently from members of the model.Context menus offer several functions such as adding and removing objects toand from the work area and model, maintaining the respective master dataelements, maintaining quotas and transportation lanes, etc.

Visualizing the supply chain model in the Supply Chain Engineer is a two-step process: adding the objects to the model and adding the objects to thework area displayed on the screen. We choose to first put the objects into themodel and then adding them all to the work area.

Clicking the Add Objects to Model button denoted in Fig. 3.24 opens adialog for selecting objects to be added to the model looking like Fig. 3.25. Viathe 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 assignedvia the respective Display buttons. Adding the objects to the model shouldfinish with a message such as in Fig. 3.26.

In order to actually display the model objects in the Supply Chain Engi-neer, they have to be added to the work area. The easiest way of doing this6 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 differentwork areas of the same model here.

3.2 Supply Chain Model Master Data 71

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

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

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

72 3 Model Building in SAP APO Supply Network Planning

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

is clicking the Objects in Model button (cf. Fig. 3.24) that opens a windowlisting all model objects which can be added to the work area with the clickof another button such as in Fig. 3.27.

In case anything goes wrong in the process of adding the master dataobjects to the model or the work area please repeat the steps described abovefor the missing objects. The optimization planning process will not work ifany 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 trans-portation lanes defining the detailed properties of cross-location product flowsin the supply chain. As they are always created for a specific supply chainmodel we create them after we have assigned all other elements to the modelin Sect. 3.2.6.

Transportation lanes provide a convenient way to model the assignmentof a supplier to a specific plant, for example. They can be defined specific tothe product and different means of transportation such as air or truck cancoexist. We will use different means of transportation for putting a constrainton the transport quantity of component X1 from supplier S1 to the factoryF1 while transportation of X2 over the same lane remains unconstrained.

The appropriate SAP APO transaction is Advanced Planning and Op-timization → Master Data → Transportation Lane → Transportation Lane(/SAPAPO/SCC TL1). On the entry screen the model name along with thestart and destination locations have to be specified. In Fig. 3.28 we entered thedata for transportation from supplier S1 to the factory F1. Hitting the Createbutton leads to a screen similar to the one shown in Fig. 3.29, but without anyentries in the three sections Product-Specific Transportation Lane, Means ofTransport, 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 trans-portation lanes are model-specific. c© SAP AG

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

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

1. For transportation from supplier S1 to the factory F1 we distinguish be-tween components X1 and X2. For the former there is a constraint onthe maximum transportation quantity, for the latter there is no such con-straint. In the model there is one means of transport Car that consumesthe capacity of a transportation resource and one means of transportTruck 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 sectionssince different products are transported by different means of transport.

2. For all other transportation lanes there are no such constraints so that wecan model them by simply creating a means of transport and assigningall products to it.

As suggested by Fig. 3.29, we will start with the more complicated, butgeneral case. As we just mentioned, transporting the components X1 andX2 is treated differently. Hence, we create entries for these products in theProduct-Specific Transportation Lane section. Hitting the appropriate but-ton (cf. Fig. 3.29) opens a sub window on the right hand side of the screenwhere the components X1 and X2 are entered as well as a sufficiently largetime interval for our planning purposes. All other parameters – includingthe optimizer-relevant ones such as the transportation cost function – remainat their default values as we do not use them in our example. Clicking onCopy and Close adds the data to the according section of the transportationlane screen. The product-specific data can be maintained in one step usingthe Mass Selection functionality in the sub window (upon creation of theproduct-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.

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

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 ofthe screen. For the constrained means of transport data as shown in Fig. 3.30is entered:

• Validity Period : enter an arbitrary means of transportation, in our exampleCar7 and start and end dates covering the time period we want to run theplanning in. For more sophisticated setups transportation lanes can bemaintained in a time-dependent way similar to most other model elements.

• Control Indicator : for our case it is important that Valid for All Products isnot checked and both Aggr. Planning and Fix Trsp. Duration are checked.The latter is needed for fixing the duration of the transport manuallysince we want to precisely control the transportation resource capacityconsumption. Disc. Mns. of Trans. controls whether the optimizer usesthe means of transportation in discrete intervals, which we do not use inour example.

• Parameters: a click on the Generate Proposal button fills the distanceand duration fields with proposed values – the latter only if a speed ismaintained in customizing for the selected means of transport. In anycase, we overwrite the Trsp. Duration field with 6:00 hours for reasons wewill see a bit later. In the Resource field our transportation resource T1is entered. The Bucket Offset determines the availability date of a receiptwithin a time bucket calculated by the optimizer. In our case it is at itsdefault value of 1 which translates into product availability at the start ofthe time bucket containing the transportation end date. The Period Factoris not used by the optimizer and remains at its default value.

Again, a click on the Copy and Close button adds the means of transportto 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 meansof transport Truck with exactly the same properties apart from the resourceassignment – that is, the Resource field is left blank.

The last step in creating this most complicated transportation relationshipin our model is to combine the (product-specific) transportation lane and theappropriate means of transport. The result is a set of entries in the bottompart of the screen defining the parameters of the product-specific means oftransport that exist on the transportation lane, e.g., transport capacity con-sumption. Figure 3.31 shows how the screen looks like after highlighting theX1 line on the top part (Product-Specific Transportation Lane) and clicking7 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 → Customiz-ing → IMG → Execute Project (SPRO), clicking the SAP Reference IMG buttonand executing mySAP SCM - Implementation Guide → Advanced Planning andOptimization → Master Data → Transportation Lane → Maintain Means ofTransport (execute by clicking the green check mark next to the menu entry). Aswe will not use system proposals for the transportation duration for Car there isno need for maintaining speed data.

76 3 Model Building in SAP APO Supply Network Planning

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

on the creation icon for product-specific means of transport. The only neces-sary entries for X1 are in the fields Means of Transport which takes the codefor Car and Consumption which we set to 4 kg. After Copy and Close thesame procedure is repeated for the component X2 which is assigned to themeans 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 S1to 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 of1000 kg per day provide this constraint: four transportation turns fit in oneday (4× 6 h = 24 h) and because transporting one piece X1 consumes 4 kg ofthe available transportation capacity each turn takes 250 pieces X1. Togetherwe arrive at our constraint of a maximum of 1000 pieces of X1 flowing fromS1 to F1 every day. To be precise, this refers only to working days becausewhen defining the resources in Sect. 3.2.4 we chose calendars that considerweekends and holidays.

All the other transportation lanes are much simpler in structure becausethey do not involve constraints. Along the lines of what we did so far onlythe 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 Productsradio button instead of entering product codes when creating the lane) is cre-ated and in the middle section one means of transport is created valid for allproducts. Figure 3.32 shows how the simple transportation lane from the fac-tory F1 to customer C1 looks like. The transportation duration correspondsto the value proposed by SAP APO in this case.

Concluding this section and as a reference we list the data for all fivetransportation lanes in our model in Tables 3.14 to 3.17. According to the

3.2 Supply Chain Model Master Data 77

Fig. 3.32. The product independent transportation lane from F1 to C1. c© SAPAG

Source Destination Product

S1 F1 X1, X2S2 F1 All ProductsF1 C1 All ProductsF1 C2 All ProductsF1 C3 All Products

Table 3.14. Product specific transportation lanes in the example supply chainmodel

sequence we used in this section first the product-specific lanes are given inTable 3.14 followed by defining the means of transport for the constrained andunconstrained lanes in Tables 3.15 and 3.16, respectively. At last the product-specific 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 dateranges presuming they are chosen so that they span the complete planninghorizon.

In the end, the Supply Chain Engineer graphical display of the modelshould look like in Fig. 3.2 on p. 44.

78 3 Model Building in SAP APO Supply Network Planning

Source location S1Destination location F1

Validity PeriodMeans of Trans. Car Truck

Control IndicatorsChecked Aggr. Planning

Detld PlanningFix Trsp. Duration

Unchecked Valid for All ProductsDo Not Build Transit Stock

Fix Trsp. DistanceDisc. Mns of Trans.

ParametersTransptn Distance 220.335Trsp. Duration 6:00Resource T1 –

Table 3.15. Means of transport data for the constrained transportation lane in theexample supply chain model. The field names are spelled like in SAP APO

Source location S2 F1 F1 F1Destination location F1 C1 C2 C3

Validity PeriodMeans of Trans. Truck

Control IndicatorsChecked Valid for All Products

Aggr. PlanningDetld Planning

Unchecked Do Not Build Transit StockFix Trsp. DurationFix Trsp. DistanceDisc. Mns of Trans.

ParametersTransptn Distance 623.128 1,032.892 521.917 579.720Trsp. Duration 12:27 20:39 10:26 11:35Resource –

Table 3.16. Means of transport data for the unconstrained transportation lanes inthe 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 kgX2 Truck –

Table 3.17. Product-specific means of transport in the example supply chain modeland transportation resource capacity consumption (only applicable for the trans-portation 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 start-ing point for optimization-based SNP planning. The example model is firsttreated as a continuous problem (LP) and then as a MILP which is createdby introducing lot size constraints. Together with Chap. 3, which deals withmaintaining master data objects so that they form a supply chain model suit-able for optimization, this chapter serves as a little cookbook for creating anoptimization model in SAP APO. In the same way as it is not feasible to coverall aspects of mathematical optimization in one place it is beyond the scope ofthis book to give a complete description of all aspects of (MI)LP settings andmodeling in SAP APO, some topics are just briefly mentioned, some mightbe missing. This shall encourage the interested reader with access to a SAPAPO system to experiment and “try things out”.

For a consolidated view onto our optimization problem we first give a recapof our supply chain model. This may also be used as a shortcut for the readerwho postponed reading the model building chapter and who wants to see anoptimization run in SAP APO right away.

4.1 Recap of the Supply Chain Model

Our example problem models single-stage production with external sourcingdecisions. In Chap. 3 we were looking at a company selling three main prod-ucts, P1, P2, and P3 to three customers (or customer regions) C1, C2, andC3. Making the products requires two raw materials X1 and X2 that aresourced from two suppliers S1 and S2 delivering to the factory F1. In thefactory there is one production resource R1 the capacity of which is sharedby the production processes making the three end products. Figure 4.1, whichis 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 sellingat different prices. In the model the higher grade products consume more ofthe expensive raw material X1 and making them consumes more resource

80 4 Optimization in SAP APO

P1 P2 P3

F1

C1

C2

C3

X1 X2

S1

X1

S2

R1

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

capacity. On the other hand, failing to satisfy demand for the higher gradeproducts or running late on the delivery results in a higher penalty than it isthe case for the lower grade products. Also, the storage costs are accordinglyhigher in order to reflect more inventory fixed capital.

The objective function of the example model is addressing stock level re-duction, production resource utilization at the same time as fulfilling customerorders, 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 structureand 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 havingoptimization-based planning in mind. Here we go into optimization-specificsettings 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. InSAP APO there is a number of profiles for this purpose, the optimizationprofile being one of them. In our example we create a new optimization pro-file which we explain in some detail and use default data for the other pro-files.1 Nevertheless, we give an overview of these other profiles relevant foroptimization-based SNP in the following sections.

The profiles are accessible via the application menu as well as via SAPAPO customizing. In the instructions below we access them via the applicationmenu 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 takeinto account. In the SAP APO system the list of optimization profiles isreached via transaction Advanced Planning and Optimization → Supply Net-work Planning → Environment → Current Settings → Profiles → Define SNPOptimizer Profiles (S AP9 75000102). A click on the New Entries button letsus define a new profile which we name SIMPLE as suggested by Fig. 4.2.

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

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

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

82 4 Optimization in SAP APO

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

The individual tabs in the optimization profile allow adjusting parametersthat determine the behavior of the optimization planning run such as the typeof constraints to be considered, whether to use the primal or dual simplexalgorithm, whether to use a maximum runtime for the optimization process,etc. The first tab is called General Constraints and its settings determineexactly what its name suggests and what is listed in Table 4.1.

Discrete Constraints, the second tab, controls which discrete elementsare included in the optimization model. The settings are only applicable ifDiscrete 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 productionresources can either be not used at all or used in full (cf. defining thecapacity variants of our example resource R1 in Sect. 3.2.4).

• Lot Sizes determines the relevance of minimum lot sizes and integralityconditions. Minimum lot sizes can occur in PPMs/PDSs and transporta-tion lanes (via the SNP lot size profile for transportation lanes). Integralitycan refer to PPMs/PDSs, transportation lots, and means of transport. Inour example we use it for production of an integer multiple of the PPM

4.2 Optimizer Setup 83

Section Comment

Capacity Constraints Switch capacity constraints on and off: production, trans-portation, handling, storage, and maximum product spe-cific quantity stored (from the location product masterdata)

Lot Sizes Consider maximum lot sizes given in PPM/PDS and/ortransportation lane master data

Safety Stock Safety stock restrictions can be ignored or penalized ac-cording to absolute or relative shortfall. Penalties can beper bucket or per day.

Shelf Life There are three options on how to deal with expired prod-uct: (1) ignore shelf life, (2) continue to use expired productfor a penalty, and (3) dispose of expired product. In (2) and(3) the penalty can be the location-product procurementcost or a fixed value that is not product-dependent and setin 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 wealso activated Discretization in the PPM master data in Sect. 3.2.5.4).

• Fixed Consumptions deals with the optimizer taking into account fixedconsumption 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 transporta-tion lane master data), and procurement quantity of a location productcan be considered by the model.

• Cross-Period Lot Size – if activated – causes the optimizer to take intoaccount setup activities in the previous time bucket if the same PPMis used for production in subsequent buckets (campaign planning). Theresources assigned a fixed capacity consumption in the PPM must havethe (Cross) Period Lot Size indicator set.

All activated constraints in this tab are active for a certain time span. Thistime span can be given either by stating a specific horizon starting from thecurrent date, or by stating a time bucket type for which the correspondingdiscrete constraint shall be valid. The available units for the horizon and thetime bucket types are days, weeks, months, quarters, and years.

Model Params, the third tab, deals with the valuation of stock and theavailability of product within a time bucket. Inventory can be valuated at the2 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 representedby the sum of several linear expressions with a piecewise linear approximation, aconcave cost function in a piecewise linear approximation requires binary variablesto force the pieces to enter the solution in the proper order. The number of binaryvariables 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 aproduct that is produced or transported is available at the beginning of thecurrent or at the start of the next time bucket, rounding limits for productionand shipments can be adjusted.

Solution Methds, the fourth tab, provides the following parameters:

• Stop Criteria determine when to stop the calculation and are particularlyuseful for MILP problems. A maximum optimizer runtime and a maximumnumber of improvements (of the integer solution) can be specified.

• Decomposition allows an automated way of decomposing the problem intosubproblems which are solved sequentially. Decomposition can be doneby time, product, and resource. In the first case a window size in timebuckets is specified. The second case requires a percentage of the productsfor each sub-problem and – optionally – a priority profile (cf. Sect. 4.2.5).This profile helps in segmenting the products which otherwise would bedone via quantity and non-delivery penalty analysis. In the resource casea priority profile can be defined that helps in determining the model split-up which would be done via material flow analysis and other internalcomputations otherwise.

• Priority Decomposition provides a choice between prioritizing demands inthe decision-making process in a cost-based or strict fashion. The formerdetermines the priority of a demand via its penalty cost in the locationproduct master, the latter assigns each demand a fixed priority dependingon its category. The default values are priority 1 (the highest priority)for customer orders, 5 for the corrected demand forecast and 6 for theforecast. The safety stock priority can be set to 1, 5, or 6 in order tomatch 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 integerproblem shall be sought by using heuristics instead of an LP method.

• LP Solution Procedure gives a choice between primal and dual Simplexand whether an interior point method shall be used.

• Aggregation allows planning on a location product group level (called ver-tical aggregation) and planning only a subset of the supply chain modeldefined by certain locations and products (called horizontal aggregation).In vertical aggregated planning location products are aggregated auto-matically into product groups before planning and disaggregated after theplanning run. A prerequisite for this is a set of location, product, and pro-duction process model hierarchies that has to be maintained in the SAPAPO system.

• Optimization Objective gives a choice between cost minimization and profitmaximization. In the case of profit maximization the non-delivery penaltyin the location product master is interpreted as the profit of selling theproduct rather than as the penalty suggested by the field name. This al-lows optimizing the contribution margin, for instance. Note that switching

4.2 Optimizer Setup 85

between cost minimization and profit maximization does not necessarilychange the objective function but could also be implemented by inter-preting the results in post-optimal analysis (cf. the related comment inSect. 8.3.2).

Integration, the fifth tab, deals with integrating the optimizer to certainSNP parameters, former planning runs, and PP/DS:

• Horizons determines whether the SNP production horizon, SNP stocktransfer horizon, and the forecast horizon are considered by the optimizer.The two SNP horizons define periods of time in that SNP does not planproduction or stock transfers, respectively. They are used for organizingthe coexistence and interoperability of medium-term planning (SNP) andshort-term planning (PP/DS). The forecast horizon defines a period oftime in that the forecast is not considered part of total demand. All threehorizons are set in the location product master.

• Incremental Optimization defines how to deal with results from previousplanning runs. If the Do not delete any orders indicator is not set (seebelow) or if fixed orders exist the algorithm might run into infeasibili-ties if the existing orders are considered as hard constraints that needto be fulfilled. To influence this, demand originating from fixed (and ex-isting) orders can be treated either as a hard constraint, a pseudo-hardconstraint (i.e., “infinitely” large penalty cost), prioritized as a customerdemand, corrected forecast, or forecast. This can be set separately for de-pendent demand (e.g., components) and distribution demand. Similarly, itmay happen that a planning run is executed with reduced scope excludingcertain location products. In this case, required input products (compo-nents) not existing in sufficient quantity as production process input orsubject to transportation could cause infeasibilities. Therefore, stock ofnon-selected PPM/PDS input products and stock of non-selected sourcelocation products can either be ignored (i.e., not planned), regarded aspseudo-hard constraint, or regarded as hard constraint.

• Setup Status Handling deals with integrating to PP/DS when productionprocesses with setup operations are involved. If Cross-Period Lot Size isactivated the optimizer can be configured to consider existing PP/DS or-ders with a matching PPM in the current or prior time bucket in orderto determine whether setup operations are necessary for new SNP orders(production campaigns). If Cross-Period Lot Size is not activated the op-timizer can be configured to consider matching PP/DS setup operationsin the current time bucket.

• Existing Orders: by default, all orders that are not fixed are deleted beforeplanning is executed. Optionally, all orders from the previous run can beleft intact by setting the Do not delete any orders indicator; existing ordersare 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 behaviorof 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. Theseconstraints can represent upper bounds for production quantity (at prod-uct PPM level), external procurement (on location product level), inven-tory (on location product level), and transportation quantity (on product-transportation lane level). The bounds are maintained in certain key fig-ures in the standard SNP planning book 9ATSOPT (see Sect. 4.3.1 forgeneral information on SNP planning books) along with the safety stockdata.

• Upper Bounds for Stock set in the SNP planning book (we will not applythis, but SNP planning books are mentioned in Sect. 4.3.1) can optionallybe 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 solutionis found after the configured extended runtime the problem can be eitherignored (the partial problem is ignored and the optimizer tries to finda solution for the whole problem), simplified, or the solution process iscancelled.

4.2.2 Scaling the Costs in the Master Data – the SNP Cost Profileand 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 AdvancedPlanning 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 costprofiles in the system.

Figure 4.4 shows the DEFAULT cost profile with equal weights for all costtypes 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 thesystem (i.e., they do not need to add up to 1.00). SAP does not recommendto use other profiles than one with uniformly distributed weights in order toavoid 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 ac-cessing all optimization-related costs. Two transactions with different appear-ance, but same functionality are reached via transaction Advanced Planningand Optimization → Master Data → Supply Network Planning Master Data→ Maintain Costs (Directory) (/SAPAPO/SNP113) and Advanced Planning

4.2 Optimizer Setup 87

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

and Optimization → Master Data → Supply Network Planning Master Data→ Maintain Costs (Table) (/SAPAPO/CSNP), respectively. Both can be con-veniently used for avoiding many master data screens when it comes to quickchanges of costs in the model. As an example, Fig. 4.5 shows the planningversion-dependent penalty costs for product P2 at customer C1 in the trans-action /SAPAPO/SNP113; cf. the same costs in the location product masterdata in Fig. 3.9 on p. 58.

4.2.3 Working Towards Steady Results – the SNP OptimizationBound Profile

In some cases there is the business objective to increase the stability of theresults from one SNP planning run to the next. This can be accomplished byincluding additional constraints in the model restricting the deviations of thedecision variables from their values after a prior optimization run.

The SNP optimization bound profile – if specified when executing the plan-ning run – defines these permitted deviations as percentages above/below thevalues of a prior optimization result, which is not limited to the one originatingfrom 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 valuesacross all time buckets.

88 4 Optimization in SAP APO

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

allowed deviations can be smaller in the beginning of the planning horizon andcan get bigger or unconstrained towards the future to reduce last-minute planchanges. The SNP optimization bound profile is maintained in the transactionAdvanced Planning and Optimization → Supply Network Planning → Envi-ronment → Current Settings → Profiles → Define SNP Optimization BoundProfiles (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 bespecified in the Lot Size Profile field in the product-specific means of trans-portation in the transportation lane master data (cf. Fig. 3.31 on p. 76). TheSNP lot size profiles are created and maintained in the transaction AdvancedPlanning and Optimization → Supply Network Planning → Environment →Current Settings → Profiles → Define SNP Lot Size Profiles (TransportationLanes) (S AP9 75000095).

Possible entries are minimum and maximum lot sizes for the shipment aswell as rounding values in case shipments are restricted to integer multiplesof a certain lot size.

Naturally, discrete optimization has to be chosen in the SNP optimizationprofile in case the minimum lot size or lot size integrality constraints are tobe 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 thatwould 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 besubdivided – decomposed – into several sub-problems that are solved sequen-tially. There are three decomposition methods in SAP APO: time, product,and resource decomposition. The SNP priority profiles help in decomposingby product and resource.

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

The transaction Advanced Planning and Optimization → Supply NetworkPlanning → Environment → Current Settings → Profiles → Define SNP Pri-ority Profiles (/SAPAPO/OPT PRIOPROF) is the entry to maintaining pri-ority profiles for product and resource decomposition. Figure 4.6 shows anexample profile that assigns product P1 priority one and both products P2and P3 priority two as a suggestion for product decomposition. In our exampleoptimization runs later on we will not use decomposition.

4.2.6 Settings in SAP APO Customizing – the SNP Planning andParallel Processing Profiles

There are two profiles relevant to optimization that are accessible via SAPAPO customizing only: the SNP planning profile and the parallel processingprofile. They hold settings of global SNP planning procedures and of dividingbackground jobs into parallel processes, respectively.

The SNP planning profile defines over 30 parameters determining globalSNP 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 dataor details of planned order integration with mySAP ERP. Describing them allwould go beyond the scope of this section, but we think it is worthwhile tomention the impact of two of them as it may help debugging a model thatdoes not behave as expected:

• Opt.: Transp. Lot Sz determines whether lot size information for trans-portation lanes is taken from the SNP lot size profile specified in thetransportation lane master data or additionally from the location prod-uct master data. In the latter case certain rules of precedence exist incase lot sizes are maintained for both the transportation lane and locationproduct.

• Opt.: Lot Formtn determines the creation of orders depending on lot sizedata maintained for the location product and the PPM: production quan-tities are either (1) split into multiple planned orders representing a fixedlot size or maximum lot size or (2) converted into one planned order rep-resenting the whole quantity ignoring the mentioned lot size settings.

One field in the SNP planning profile links to the parallel processing profilewhich defines how background jobs are organized and distributed among theavailable hardware resources. The parallel processing settings are defined bySNP sub-module and hence contain an optimizer-specific setting. This is whywe 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 onthe upper part of the screen. The SNP planning profile is then accessed viamySAP SCM - Implementation Guide → Advanced Planning and Optimiza-tion → Supply Chain Planning → Supply Network Planning (SNP) → BasicSettings → Maintain Global SNP Settings and the parallel processing profileis accessed via mySAP SCM - Implementation Guide → Advanced Planningand Optimization → Supply Chain Planning → Supply Network Planning(SNP) → Profiles → Define Parallel Processing Profile, respectively. For ex-ecuting a customizing activity, click the green check mark next to the menuentry.

4.2.7 The Time Bucket Profile

Last not least, the time bucket profile defines the number and length of thetime buckets in scope for SNP. Often a higher level of detail is desired at thebeginning of the planning horizon, which results in time buckets being shorterin the beginning and getting longer towards the end. For example, we may useseven daily, three weekly, five monthly, two quarterly, and two yearly bucketsto represent a planning horizon of three years.

In our example we will use a planning horizon of half a year, all in weeklytime buckets. Figure 4.7 shows how a time bucket profile such as the one we

4.3 The Planning Run 91

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

use for our example is defined. It spans a period of 26 weeks (first line ofthe table) which is subdivided into weekly time buckets (second line of thetable). By pressing the Period list button all time buckets in the profile canbe displayed in tabular form for checking the definition. The associated SAPAPO transaction is Advanced Planning and Optimization → Supply NetworkPlanning → Environment → Current Settings → Maintain Time BucketsProfile 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 andthe optimization parameters in the various profiles, we are ready to performan SNP optimization planning run.

In order to execute this optimization planning run in an instructive way wemake use of the planning book concept of SAP APO which is not optimization-specific. For didactic reasons, however, we will give a short introduction intoplanning 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 showprimarily transaction data in a spreadsheet-like layout. As it is well outsidethe scope of this book to explain all issues relevant to the planning bookin 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 thestandard SNP planning book with one view on the displayed data and givean extremely abbreviated introduction into how to use it here. However, weonce more explicitly encourage the reader to explore the SAP APO system4 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 anextremely small portion of the capabilities and flexibility of the SNP planningbooks.

The planning book is invoked via Advanced Planning and Optimization →Supply Network Planning → Planning → Interactive Supply Network Plan-ning (/SAPAPO/SNP94). At first it shows an empty spreadsheet on the rightside of the screen and four sub-windows (so-called selectors) on the left handside. 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 viewof the pre-set standard SNP planning book 9ASNP94. For minimized setupeffort we select the standard view SNP94(1) SNP PLAN by double-clickingon 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 selectall 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 isavailable under the pencil icon in the Selection profile selector window on theleft. In case the planning version is not initialized a pop-up window offers toinitialize it (please do so in that case).

The data is then loaded into the spreadsheet by selecting all location prod-ucts (by holding down shift or ctrl or by clicking the Select all button) andthen clicking the Load data icon. Because we want to plan in weekly time buck-

4.3 The Planning Run 93

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

ets we select the Period Structure Settings button and select a time bucketsprofile with weekly buckets.5

At last the aggregate/disaggregate features have to be enabled in the plan-ning book. This is done by displaying the header data (button Header On/Off )and then selecting APO Location and APO Product as the characteristics fordrilling up and down (button Header Information Settings).

In the same row as the header button are buttons for expanding the dataview by switching the selector windows on and off and the “pencil” buttonthat toggles between display and change mode. The optimizer can only bestarted 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 demandforecast elements as given in Table 4.2. For an easier display of the results weexecute the planning with weekly time buckets.

Demand date Demand week Product Customer Quantity [pieces]

Aug 15 33 P1 C2 15,000Aug 15 33 P2 C2 18,000Sep 1 35 P2 C1 5,000Sep 1 35 P3 C3 10,000Oct 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 ap-plication we use the standard planning book 9ASNP94 and change the timebucket profile to a weekly one like briefly explained above – the situation lookslike displayed in Fig. 4.10. In order to fit more data on the screen we switchedoff the selector windows (via the leftmost button next to the pencil buttonon 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.7for 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 totaldemands 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 De-mand key figure. There are no receipts so far in the empty Total Receiptsline that could be expanded to show the different receipt key figures via adouble-click. The Supply Shortage increases with each added demand item.To get a better overview the planning book offers disaggregation and aggrega-tion functionality as demonstrated in Fig. 4.11 where we restrict the displayto quantities relevant to the customer C1 and disaggregate the quantities byproduct reflecting the appropriate demands in Table 4.2.

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

4.3 The Planning Run 95

Clicking on the Optimizer button in the planning book leads to the ratherempty-looking optimization screen in Fig. 4.12.6 This screen is the entry tostarting the optimization run, input and output log file analysis and inspectionand changing of the optimizer profiles. Underneath the fields for selecting theoptimization, 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 opti-

mization run, sorted by location.

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

After starting the optimization run on this screen a series of status messagesappears informing the user of the progress in three steps along with dateand time information. In the first step master and transaction data is readfor building the model formulation. In our case we get the message that wehave 5 products, 6 locations, 17 location products, 12 transportation lanes,3 PPMs and 5 demands. The next step is a consistency check of the modelalong with the solution process which – in our case – ends with announcingthe finding of the optimal solution and the end of calculations. In the third6 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 modebefore entering the optimization screen.

96 4 Optimization in SAP APO

step the optimization result is written back into the SAP APO applicationdata structures as planned production orders, stock transfers, etc. In our caseit results into creating 30 stock transfers, 25 purchase requisitions, and 9planned orders. More information on these messages, in particular if they arewarnings, 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 optimizationrun has finished. At the first glance a cost distribution gives an idea whether

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

the result is plausible, especially when the calculations are re-done after somefine-tuning the model or when the input data have changed.

A comprehensive overview of what data actually went into the model, theraw results from the optimization run, and technical logs are available in theoptimization log files which are kept for a configurable time span after theplanning run was executed. They can be viewed in SAP APO or downloadedto the client machine in text format. Figures 4.14 and 4.15 show examplesof an input and an output log from our supply chain model. From outsidethe optimization entry screen in interactive SNP the log files are accessiblevia the transaction Advanced Planning and Optimization → Supply NetworkPlanning → Reporting → Optimizer Log Data (/SAPAPO/SNPOPLOG). Inthe output log displaying the planned orders suggested by the optimizer oneeffect of LP optimization is well visible: the suggested production quantitiesare not necessarily integral, but rational numbers according to the balancingof costs performed by the algorithm.

4.3 The Planning Run 97

Fig. 4.14. The optimizer input log: transportation resource availability in the ex-ample supply chain. c© SAP AG

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

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

98 4 Optimization in SAP APO

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

4.3.3 Discrete Variant of the Model

In Fig. 4.15 the suggested order quantities are far from being “round” inthe sense of integral multiples of the PPM reference quantity of 1000 pieces.Looking at the suggested stock transfers from the suppliers to the factory wewould see even fractional numbers because there is no mechanism that favorsinteger quantities in the continuous case. In order to clean this situation up weintroduce integrality constraints for the PPMs. Hence, the optimizer createsorders with quantities that are integer-multiples of the reference output valueof 1000 pieces P1, P2, and P3.

For including these constraints the optimization profile has to allow dis-crete optimization and activate the desired integrality restrictions. Figure 4.17shows a part of the different integer constraint types and a choice of valid-ity periods that can be defined for each type. If, for example, planning takesplace in weekly time buckets followed by monthly and quarterly ones it maybe desirable to consider discrete constraints only for the weekly buckets in thenearer future in order to increase the overall planning performance.

Actually executing the planning run in our case leads to a quick solutionof the very simple MILP – the second integer solution is optimal already. Theinitial conditions are the same as in the continuous case: no orders consistin the supply chain apart from the demand forecast given in Table 4.2. Asexpected the overall costs of 12,801,500.00 are slightly higher than the costs of12,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 IntegralPPMs/PDS constraint is active for the first 26 weeks of planning. c© SAP AG

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

the same since they do not depend on lot sizes and because the demandhappens to be an integer multiple of the production lot sizes so that theintegrality conditions do not force any excess production. Production capacityexpansion (overtime) and storage costs however are increasing in the discretecase. From comparing the suggested production quantities in the two casesin Figs. 4.15 and 4.19 we observe a tendency to produce earlier and in moreproduction runs balancing storage, overtime, and late delivery costs.

100 4 Optimization in SAP APO

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

4.4 Some Observations

From what we described in this first part of the book it should be obviousthat the mathematical and the “business software” approaches differ signif-icantly. Model building in particular is a completely different process in thetwo 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 appro-priate optimization-related training – will translate reality into equations rep-resenting and including all elements relevant for solving the decision-makingproblem. A prerequisite is understanding what the problem actually is, a pre-requisite with professional and social aspects. Talking to business people themathematician will very often be challenged with barriers resulting from alacking common language and a different kind of analytic thinking.7 Once thebarriers are overcome and appropriate knowledge and information transferhas started, the mathematician will start formulating the model.8

This formulation will be custom tailored to the particular problem andwill respect all business objects and constraints deemed to be of relevancefor making the right business decision. Often simplifications and assumptions7 A part of Operations Research (OR) is dealing with bridging those gaps in under-

standing by educating people in applied optimization. Having an OR backgroundcan help in this phase, but care must be taken not to focus on software more thanon understanding the underlying mathematics.

8 It is very important to mention here that the interaction between the individ-uals formulating the optimization model and the client does not stop here andrecommences when the application is delivered. In fact, constant communicationon 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 restric-tions. For example, it might be tolerable in certain cases to model non-linearrelationships in a linear model approximately resembling reality. In other caseswhere a MILP is the appropriate modeling approach it might be tolerable tolift integer constraints that lie outside a certain time horizon because lot sizerestrictions are not that critical for planned production further ahead than,say, six months. Of course these simplifications have to be applied very cau-tiously and it needs quite some experience in optimization and mathematicalmodeling to come up with an efficient and usable result.

Given one or more existing IT systems the client uses, the model is subse-quently implemented and – in principle – ready to be used by the client. De-pending on the development framework of the optimization application somesort of user interface has either to be built or adapted. One of the biggest chal-lenges in implementing such an application is interfacing it with all involvedbusiness software systems and getting the right data out of them for the op-timization process and back into them after the process. Chap. 9 will dealwith such cases, where SAP APO itself is treated as a “legacy system” andown optimization applications are integrated into a planning process involvingSAP APO business processes and other optimizers.

4.4.2 The Standard Business Software View

When it comes to optimization, standard business software products such asSAP APO do not offer LP or MILP modeling per se on an equation level, butprovide a standard MILP formulation suitable for a wide variety of real-worldproblems that is configured by manipulating data objects in the businessapplication. Hardly anywhere terms such as variable or constraint can befound, the model parameters are set by defining supply chain-related objectssuch as products, locations, transportation lanes, lot sizes, resource capacities,etc.

Formulating the model becomes more a task of setting up these masterdata elements and selecting which are to be considered by the optimizationrun. Because of the master data concept originating from ERP systems para-meters for the planning algorithm are often scattered throughout the masterdata screens in the system (as an example of how to improve this it is worth-while to mention the central cost maintenence for the SNP optimizer shownin Fig. 4.5). Additionally, there usually are profile screens for the planningalgorithm containing optimization-specific data and settings that do not fit inthe ERP master data concept.

After appropriate customer demands or demand forecasts are created theoptimization can be started. The results are typically visible in the standardsoftware tool’s user interface immediately after the optimization run has fin-ished, e.g., as planned production orders that are covering the demand. At thesame 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 noneed for actually understanding the applied optimization algorithm any more.

But how to interpret the quality of the calculated plan and how to knowwhether the right algorithm was selected for solving the problem? Typicallysystems like SAP APO offer several algorithms for solving supply chain prob-lems, optimization being one of them. Depending on the individual businessobjectives an algorithm such as a simple heuristic method may be sufficientfor a client with a very simple supply chain structure who is looking at mathe-matical algorithms suspiciously. Domain expertise in mathematical modelingincluding optimization is necessary for choosing the right algorithm, explain-ing the appropriate method to the client and to create trust in the planningsystem as a whole.

Without understanding (at least the basics of) optimization it may be verydifficult to understand and correctly interpret the results of an optimizationrun. Many supply chain projects are delayed and/or seriously jeopardized ata late stage when the first production plans are presented to the planners.The APS software itself might help by providing a built-in explanation toolwhich helps in the interpretation. This is unique to APS because fine-tuningsuch a tool depends on a standard model and would not be practical withtailored mathematical formulations. Again it is trust in the planning systemthat needs to be built and this does not work when there are open questionsand no one on the project team can adequately explain the behavior of theplanning algorithm.9

These two examples underline the need for individuals experienced in op-timization accompanying implementation projects of APS software wheneverplanning 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 orless sophisticated methodology for interfacing with ERP systems. Some are sotightly integrated that part of the model can be built automatically based ondata transferred from ERP; SAP APO and its integration with mySAP ERPis an example for this. The first steps of building an optimization appliction isvery easy then as no thoughts need to be spent on mathematical basics such asappropriately defining variables and data mappings between the ERP softwareand the planning engine (keeping in mind that interpreting the results later onneeds quite some optimization knowledge). Additionally, the standard modelbuilt in an APS makes supporting the application much easier than in anenvironment 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 mathematicaloptimization model formulation, explanations of issues concerning the planningalgorithm 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-techindustry. In order to understand the typical business challenges it is vital tohave a look at how the actual transformation of raw silicon into microchips isperformed. 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 meth-ods play an important role: the production equipment is very expensive, lifecy-cles of the products are very short, and customer demand varies very quicklycompared to the production lead times. This is why the majority of the lead-ing semiconductor manufacturers use one or the other kind of optimizationand/or constraint propagation algorithms for planning; sometimes a custom-developed application based on optimization engines such as ILOG’s CPLEX isused, sometimes APS such as SAP APO or i2 R© are deployed.

Because of confidentiality issues in the industry we do not describe a spe-cific SAP customer case where the SNP optimizer is used, but explain thekey business drivers in the semiconductor business and give an example of asuccessful SAP APO implementation using the constraint propagation-basedCTM algorithm.

5.1 Semiconductor Manufacturing

Figure 5.1 states the four phases characteristic for manufacturing semicon-ductor devices from a raw silicon wafer together with depicting the schematicinput and output products of each step. Here we do not discuss producingwafers from raw silicon, a crystal-growing and slicing process, but look intohow a microchip is made starting from a silicon wafer. The four steps weare looking at are called fabrication (or short fab), sort (also called probe),assembly, and (final) test. After going through these steps a silicon wafer istransformed 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

WaferFabrication

WaferSort

Assembly Test

Front-end Back-end

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

Often the four steps are grouped into the front-end and back-end processesconsisting of fab and sort (front-end) and assembly and test (back-end), re-spectively.

In the following we will very briefly characterize the four principal stepsof semiconductor production sufficient for the subsequent discussion of theplanning processes in our case study. Solid state physicists and experts insemiconductor 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 itcreates a pattern of integrated circuits while going through a series of upto several thousand production activities taking up to several weeks totalprocessing time, depending on the complexity of the microchip to be produced.Operations performed on the wafer include modifying the surface by addinglayers of new material or diffusing ions into the surface, etching patterns intoa layer, implanting ions, photo lithography, etc.

At a German chip manufacturer, for instance, fabrication of memory andlogic 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) andmetal which takes about 10 days of “wiring” (deposit, etch, photo, clean).

In principle fabrication happens on few different pieces of equipment, butthe wafer visits each of them multiple times during the fab step. Today mostwaferfab facilities use wafers 200 mm or 300 mm in diameter holding a rangefrom about a dozen to several hundreds of chips each, depending on chip sizeand 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 termsof 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 onthe wafer and performing electrical tests. Results from these tests are usedto continually improve the fab yield of good die by evaluating patterns ofmalfunctioning chips on the wafer and other process parameters. Optionalproduction steps in the sort process include backgrinding to reduce waferthickness and power consumption and applying gold to the back of the waferfor better package adhesion.

During the assembly process the wafer is cut up into the die. The gooddie are then attached to a package base, lead wires are bonded to the die andthe lead frame and finally the package is sealed with a lid.

The last step in our mini-description of semiconductor manufacturing isthe final test process which consists of the last quality control before a chip isactually shipped to the customer: During the burn in the device is put underworking conditions for a while; this is because most of the malfunctions ofa semiconductor device will happen during the first minutes of its operationand become obvious in this electrical test. Depending on the purpose of thespecific device a series of additional tests are performed, e.g., environmentaltests (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 bydeterministic chaos” – said an executive of a large semiconductor manufac-turer.1 He referred to the effects of large lead times on the one hand (the fabprocess can take many weeks) and high market volatility on the other hand.

To complicate the market behavior, technological advances happen veryfast and at the same time cyclic market up- and downturns are a characteristicof the semiconductor market since its formation after the Second World War.Avoiding the negative side effects of these up- and downturns by moving thebusiness to other regions in the world is no option because the semiconductorbusiness operates globally. Partly this is because of transportation cost beingnot significant compared to the value of the goods. So it is common prac-tice to have the front-end processes and in many instances the test processat the company headquarters (e.g., in Europe or the US) and the assemblyoutsourced to low-wage countries in the Far East. The sorted wafers and as-sembled chips are then transported via air freight to minimize delays and leadtimes.

Moore’s Law predicts doubling the complexity on an integrated circuit ofa 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 dynamicsystem 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 semiconduc-tor technology is still observed, which translates into accordingly high marketvelocity.

Consequently, proper inventory management is one key factor for successin the semiconductor market. The effects of rapidly advancing technologycause goods in inventory to depreciate very fast, which may lead to consid-erable losses in case of a steep market downturn. Too little inventory of theright product, on the other hand, can cause significant losses in terms of op-portunity costs if high customer demand cannot be satisfied due to the longmanufacturing lead times of up to one quarter.

Finally, the vast majority of fixed assets is the very expensive front-endequipment which translates into high costs for wasted capacity (e.g., idling,making the wrong product) in fab and sort. As a consequence, maximizedfront-end capacity utilization is an important constraint in semiconductorplanning. Again, the striking imbalance in the processing times of the foursteps described above have to be taken into account: fabrication takes up tomany weeks, all the remaining steps have cycle times in the range of somedays.

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 manage-ment, capacity planning, master planning, production planning, and orderfulfillment. Obviously, these five processes are tightly integrated with eachother and hence cannot be seen as completely independent. On the otherhand, typical software and/or algorithmic functionality required for coveringthe processes with an IT system varies. Several successful implementations ofSAP in the semiconductor industry (cf. http://www.sap.com/) suggest thatSAP meets the planning requirements for the industry on the whole.

While demand management (including demand planning) and order fulfill-ment are dominated by functionality like statistical forecasting, general trans-action processing like data exchange with other in-house and external IT sys-tems, and implementing business rules of transactional nature, the remainingareas provide room for optimization. Capacity planning and master planningare addressed by SAP APO Supply Network Planning (SNP) and productionplanning by Production Planning and Detailed Scheduling (PP/DS). Follow-ing the focus of this book, we set the PP/DS part aside and concentrate onSNP applications for semiconductor dealing with typical processes and busi-ness 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 wasdeveloped for planning at semiconductor manufacturers in the late 1990’s andhas 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 processesoften encountered at large semiconductor manufacturers. As a complete de-scription of supply chain practices in the semiconductor business would easilyfill a book on its own we will only briefly discuss the according issues listingthe key planning requirements in the industry. We call the processes capacityplanning and master planning ; depending on the semiconductor manufacturertheir naming may vary. After that we will state some aspects to keep in mindwhen modeling a semiconductor supply chain and impacts on modeling inSAP APO.

5.2.1 Semiconductor Capacity and Master Planning

Based on demand forecast data, the first step in mid-term planning is typi-cally capacity requirements planning which starts with an assembled demandforecast2 followed by a rough-cut capacity plan resulting in a production tar-get for the individual business lines of the semiconductor company. Capacityplanning is based on models containing the relevant and current supply chainconstraints, probably on a somewhat aggregated level. Even though capacityplanning is technically very similar to master planning and sometimes is basedon the same supply chain model, it is usually kept separate due to (politicaland 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 strategiclevel, driven by demand, current fabrication load, and business rules such ascustomer or product group priorities.

Typically, global capacity planning is run every week and the planninghorizon is 18months with decreasing granularity in time – starting with dailytime buckets, followed by weekly, monthly, and quarterly ones, for instance.

Very similar to capacity planning, the objective of semiconductor masterplanning is to find the best match between supply and demand. The drivingfactor is again the customer demand, the limiting factor the constraints thatexist in the supply chain. Master planning is usually run on the businessline level using the capacities allocated before. A typical planning horizonis again 18 months, but in contrast to capacity planning master planning isgenerally run daily to achieve an appropriate response time in customer orderconfirmation (Available-to-Promise, ATP).

In case not all demands can be fulfilled in time there is a set of businesspreference rules. The highest priority business rule is based on demand andcustomer. A possible ranking of customers might be partner → strategic ac-count → key account → first-come-first-serve, for example. Similarly, thereis a product or product group ranking. Confirmed orders always have thehighest 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, sourc-ing strategies, and resource utilization. Such a rule might translate into a softconstraint 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 foreach production stage and transfer orders for material transportation betweenlocations.

Master planning is typically concluded by a review by the planner andprobably some manual plan changes. When the planner is satisfied, the planis published and released.

5.2.2 Semiconductor Supply Chain Modeling

A semiconductor supply chain model is a series of operations from fab to finaltest separated by inventory points and move operations between facilities, andlimited by constraints. Inventory buffers consist of raw wafer inventory, diebank, 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 supplychain are: material stock, metal bank, die bank, and finished products. Mate-rial stock is the raw wafers purchased from wafer suppliers. Wafers are slicedfrom ingots, cleaned, polished and sent to fabrication sites for wafer process-ing. Metal bank is inventory of wafers that have gone through a certain numberof masking steps, and die bank is an inventory control point of finished wafersready for dicing and packaging. Finished products are built from either metalbank or die bank.

The three typical supply chain strategies for semiconductor include build-to-order, assemble-to-order, and make-to-forecast depending on which inven-tory point the orders draw the associated material. While build-to-order de-mands include fabrication operations consuming supply from the metal bank,assemble-to-order demands use up inventory at the die bank level. Often, someproducts operate within all three models. For example, the assemble-to-orderstrategy for most customer orders draws material from die bank, while specificcustomer 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. Priorto this point, manufacturing is making to forecast, after this point it is make-to-order. A forecast later than this point is expired due to insufficient time tomanufacture determined by the manufacturing lead time.

Raw material procurement, metal bank, and die stock inventory levelsare planning driven, while production to customer programs, finished goodsregional stock, assemble-to-order from die stock, production from metal bankto 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 back-end sites control the goods from die bank through the assembly and test stepsto the finished goods warehouse. Warehousing and distribution controls thedelivery 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 bettermanaging global accounts, global forecasting, order entry, product distribu-tion, and customer service. Reduction in customer order cycle time is accom-plished through daily order release to manufacturing centers, direct shipmentfrom back-end sites, and quickly reacting to changes in demand by runningdemand and capacity planning more often. Forward integration focuses oncustomers throughout the supply chain by extending the supply chain controlpoints to include JIT deliveries, VMI programs, and expand the utilization ofEDI and E-Commerce. Integrated supply chain modeling and planning has toreflect this global structure.

Separating the planning and order driven key processes in the supply chainresults 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 chainplanning requirements of semiconductor manufacturers as they are discussedin the preceding sections. The presence of complex business rules in plan-ning requires advanced planning algorithms such as optimization and con-straint propagation; a simple heuristics-based method like the one describedin Sect. 1.4.1 is not sufficient.

Below we describe the Capable-to-Match (CTM) constraint propagationalgorithm that was originally developed for the semiconductor industry andaspects 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 algo-rithm was originally developed for semiconductor manufacturers. The objec-tive was to implement the typical semiconductor business rules in a marketenvironment that is characterized by demand exceeding supply, which at thattime automatically provided for fully utilized fab capacities. Therefore, focuswas laid on implementing demand prioritization rules rather than looking atmaximized waferfab utilization at the same time.

In CTM, demands are put in a sequence based on their priorities andthe 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 ex-amples are prioritization according to order date, product groups, customers,etc. Whenever the algorithm has to choose between sourcing alternatives pre-set priorities and quotas are used. These priorities and quotas are defined onthe transportation lane and production process model level.

CTM considers limited production capacities, transportation capabilitiesbetween locations, safety stock levels based on absolute quantities or targetdays of supply, and deals with time-dependent process parameters in orderto respect yield learning curves essential in semiconductor manufacturing.Transportation capacity restrictions are not included in CTM planning asthis is not seen as an important constraint in semiconductor planning. CTMplanning always results in a feasible plan in terms of capacity and materialrestrictions.

Different planning strategies help CTM in fulfilling constraints such ashigh fab utilization. Using forward scheduling (instead of backward schedul-ing) in conjunction with early demand fulfillment set at an appropriate valuewill plan fab operations as early as possible to ensure fab capacity is utilized.Unwanted inventory points between processes (PPMs/PDSs) are modeled bydefining a maximum pegging length for the two adjacent processes: e.g., zerostock of unsorted wafers is modeled such that the sort process has to beginimmediately after the fab process is finished by setting the maximum pegginglength between fab and sort to zero. As CTM does not consider stock level re-strictions directly, the overall inventory level is controlled by an order creationframe parameter that defines the maximum total time span from a demandback to the first planned production order created by the planning run. Thislimits the time a product is stored in inventory and lowers the overall stocklevels.

The priority and order based sequential planning approach is congruentwith the mindset of semiconductor planners because it ensures that high-priority customers and demands are processed first and forecast is matched tothe available capacity after customer order fulfillment. Due to the sequentialplanning and the tracked pegging relationships connecting supply and demandelements, it is transparent to the planner which planned production or trans-portation order was created for which demand element. In certain situationsit may be desirable to sell a higher-grade product for fulfilling a demand for alower-grade product. In the CTM planning run this down-binning process canbe modeled as substitution rules or a PPM/PDS converting the higher-gradeinto the lower-grade product via operations like re-marking or “burning fuses”to avoid overclocking of a lower-grade CPU, for instance. A graphical flow-oriented view of these relationships for individual demand elements supportsthe evaluation.

The downside of this sequential approach is of course the lack of a globalview 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 thatcan be manufactured on a variety of such resources. If, for instance, CTMassigns an operation for fulfilling a high-priority “multi chain” demand tothis resource the operation will not be shifted to an alternative resource whenduring the same planning run CTM encounters a low-priority “single chain”demand requiring processing on the same resource. The “single chain” demandmay then be fulfilled late or not at all even though a global algorithm (such asoptimization) would shift the “multi chain” demand to an alternative resourcefulfilling both demands without violating the constraints. If the supply chainstructure is such that these conflicts can occur, a common workaround is toplan “single” and “multi” chain products in consecutive planning runs, butthen care must be taken regarding demand prioritization.

In case a new customer demand is to be confirmed net change planningallows executing a planning run with all already created planned orders fixedresembling order promising functionality. This results in a relatively quickplanning run because only the new customer order is planned using the avail-able capacity – of course the new demand is implicitly assigned the lowestpossible priority in this case. The next complete planning run will considerthe “right” priority of the demand.

The algorithm has been continuously enhanced since it was added to theSAP SCM portfolio. Descriptive characteristics for demands, for instance, areavailable as of SAP APO release 3.1 and allow more flexible prioritization rulesand configurable forecast consumption of existing sales orders. Forecast con-sumption is vital for semiconductor manufacturers as it controls how customerorders are set against forecast quantities. Product substitution and superses-sion functionality, which is available as of SAP SCM release 4.0, supportsproduct lifecycle planning which is another characteristic of the semiconduc-tor business.

5.2.3.2 Optimization for Semiconductor

By its nature, optimization does not operate in a sequential way like constraintpropagation does in CTM planning. It rather treats the supply chain planningproblem as a whole and results in a globally optimal plan in terms of thespecified costs given the variables and constraints defined in the model.

By including the right constraints in the model and appropriately adjust-ing the cost structure and the profile settings relevant to the SNP optimizer,the business rules explicitly included into CTM can be adhered to by opti-mization based planning. This gets evident by comparing the functionalityof CTM for semiconductor described in Sect. 5.2.3.1 with the description ofhow to build and run a model for optimization in Chapters 3 and 4, includingexecuting a planning run that leaves all existing orders untouched and onlyplans fulfillment of new demands. An overview of the costs considered by theoptimizer is given in Table 1.1 on p. 19. Demand prioritization, for instance, isaccomplished 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 convertingone product grade into another. In this context it is important to understandthat designing the cost structure leading to the desired planning results re-quires considerable expertise in mathematical optimization and project teammembers who are sufficiently educated and experienced in optimization areessential for a successful implementation.

Other strategies like the single chain/multi chain product problem or for-ward/backward scheduling leading to features explicitly implemented in CTMare automatically supported by optimization due to the global character of thealgorithm. Naturally, the underlying issues of minimum fab utilization and re-source assignments are solved by observing the model constraints. The sameholds for inventory issues because the SNP optimizer includes constraintsrestraining inventory levels. With limited effort constraints such as smoothcapacity utilization across facilities and over time can be implemented withsupport from SAP, smooth capacity utilization over time can additionally beaddressed by the optimization bound profile (cf. Sect. 4.2.3).

One reason why the optimizer has not been chosen in some cases of SAPAPO implementations at semiconductor manufacturers may be because theresults of a purely rules-based algorithm like CTM are easier to explain toplanners and business people who are used to priority and strictly rules basedplanning. This match with the way the users are used to work and think isa very strong asset difficult to overcome with an algorithm that is seen as ablack box and hence is not trusted.

Frequently, a strong reason in favor of CTM is the consequence of thealgorithm being order driven rather than quantity driven: the pegging rela-tionships that are created by the planning run connect demand elements andrelated supply elements. In connection with pre-set quotas and priorities itis easier to explain why a particular planned order has been created for acertain quantity, on a certain resource, and at a certain time. The optimizer –working quantity based – creates a network of orders fulfilling the demand inan optimal way (given the constraints and costs), but does not provide a toolfor easily explaining why a certain order has been created in a certain wayor why a particular demand is fulfilled late whilst others are not. Only suffi-cient knowledge of mathematical optimization can create trust in the results,which requires thorough understanding of optimization based planning andeducation of the planners. This, again, underlines the need for optimizationexperts closely involved in any optimizer implementation.

On the other hand, large semiconductor companies often have highly ed-ucated operations research groups who develop optimization logic in-housedirectly based on engines like ILOG CPLEX or Xpress-MP. Mostly, those spe-cialists are convinced that supply chain planning implies significant potentialfor competitive advantage and often management at such high-tech companiesis of the same opinion. As a result there is often quite some internal pressureto 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 (orERP) 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 implementationat a manufacturer of application-specific integrated circuits (ASICs) that wentlive with SAP APO release 3.0 mid-2001 planning the worldwide productionnetwork and subcontracting partners. The SAP APO implementation waspart of a larger supply chain project including SAP R/3, SAP APO, andSAP R© BW (the SAP Business Information Warehouse, a data warehousesolution) extending an existing SAP R/3 installation. It took approximatelysix months.

Mid-2002 the company completed the SAP SCM ramp-up program up-grading the existing SAP APO system to the 3.1 release implementing en-hanced planning functionality.

5.3.1 The Business Objectives and Project Scope

As just mentioned, the SAP APO supply network planning implementation isto be seen as part of a bigger-scale supply chain project. The overall projectobjectives read quite general on the top level, but when looked at in detailthey link well to the business challenges we mentioned earlier in this chapter:

• Optimization of the supply chain planning process on both tactical andoperational level

• Integration with the SAP R/3 system and extending SAP R/3 whereneeded

• Improve the sales and distribution process between production locationsand the final customer by optimized inventory management of final prod-uct and intermediate stocks and establishing a consistent production plan-ning 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 man-agement and forecasting. The business scope is planning and sales orderpromising, both in SAP APO, and logistics execution in SAP R/3 whichincludes transaction processing with the numerous subcontractors used for allfour processes fab, sort, assembly, and test. Here we will focus on the planningpart that additionally has some impact on sales order promising.

Supply chain planning is seen as a combination of two processes which cor-respond to capacity and master planning we mentioned in Sect. 5.2.1: businessplanning with a longer and customer order fulfillment with a shorter time hori-zon. 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 situationsand triggering solutions such as suggesting investments in certain classes ofequipment and results in allocating products to possible production locations.This allocation is then used by the operational customer order fulfillment plan-ning, which operates on a shorter time horizon than business planning and isresponsible for on time delivery of customer orders. The customer order ful-fillment planning results are triggers for production starts in the productionunits.

For implementing the planning processes in SAP APO the CTM algorithmfor SNP was chosen, mainly due to the positive result of an analysis matchingbusiness rules and functionality and the understandability and explainabilityof the algorithm for the end users (production planners).

5.3.2 The Supply Chain Structure

The structure of the modeled supply chain follows the flow of semiconduc-tor manufacturing with an added mechanical finish step that converts testeddevices (T products) into finished goods (G products). Figure 5.2 gives aschematic view of the different product types in the supply chain model.

SFab

FSort

W/KAssy

ATest

TM.F.

G

Start

wafer

s

Unsor

ted

wafer

s

Sorte

d waf

ers (

W) /

dies

(D)

Assem

bled

devic

es

Teste

d de

vices

Finish

ed go

ods

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 supplychain and hence the outsourcing partners are included in the supply chainmodel in order to get accurate planning results. In total the supply chainmodel consists of about 15 locations that are connected by product-specifictransportation lanes, over 200 resources, over 2000 products, and over 2000PPMs.

While fab is usually done in-house at one of the internal facilities, theremaining steps sort, assembly, and final test are typically performed in Asia.The assembly process is always outsourced.

5.3 The Semiconductor Case Study 117

WaferFabrication

Wafer Sort AssemblyTest &MechanicalFinish

internal / external internal / externalexternal onlyinternal / 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 basedon the same supply chain definition and essentially differ only in their planninghorizons they are both based on the same SNP supply chain model. Basedon the different objectives of these two processes they are used by differentdepartments and are run at different times: the longer-term business planningis executed every month whereas the operationally oriented customer orderfulfillment is run on a weekly basis.

Both business planning and customer order fulfillment integrate to thelegacy demand management tool in the sense that the planning processescheck the feasibility of the forecast data in terms of available capacity. Theresulting so-called constrained forecast is then written back into the demandmanagement system which thus reflects the most up to date demand picture.

Sales order promising uses the planning process in case the Available-to-Promise (ATP) functionality cannot confirm a customer order. In this case, anet change planning run is executed with the objective to get an approximateconfirmation date. As the demands in the system are prioritized and the newdemand is put at “the end of the list” this date will be more pessimistic thanthe one after the next complete planning run. If net change planning does notfind a suitable confirmation date for the customer order the order is confirmedafter the next complete customer order fulfillment planning run.

The implementation of SAP APO met the planning requirements on thewhole successfully modeling the business planning and customer order ful-fillment processes with SAP APO. Implementing SAP APO and SAP R/3at the same time enables taking full advantage of the very tight integrationbetween 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 bothsystems than in cases where one system is productive already and the otherneeds to be adapted to its configuration.

During and after the project the choice of the algorithm was revisitedoccasionally, with the result that while optimization might provide direct so-lutions 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 therules of the constraint propagation-based algorithm and the fixed pegging asa “natural” outcome explicitly connecting demands and supplies.

Key benefits from the implementation project address the objectives whichwere set beforehand. Clear indications for adding business value were seen inthe areas of achieving integrated supply chain planning and execution, im-plementing automated and streamlined business processes with a minimumof manual entry, improved tracking of inventory, increased information accu-racy, and readiness for further integration (focusing on business-to-businessprocesses based on the high-tech standard RosettaNet).

6

Consumer Products

The consumer products industries span a rather wide range of business typesincluding apparel & footwear, beverage, food, home appliances, etc. Never-theless there are common characteristics and business challenges they have tocope with. As the consumer market is saturated in large parts of the world,opening new market segments is very difficult and the pressure for increasedcompetitiveness in the whole supply chain is accordingly high.

6.1 Supply Chain Challenges Characterizing theConsumer Products Industry

Competing with other market players companies are frequently introducingnew products for stimulating the consumers’ buying behavior, in many casesalong with a promotion campaign for the new or intermittently available prod-uct. Relating to this, most retailers keep very little inventory in order to beready for quickly changing customer demand patterns. For the manufacturerthese volatile demands translate into the need for efficient demand planningand delivery processes.

Another reason for typically low inventory levels at retailers is productexpiration. 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 tothe manufacturer.

Seasonal demand variations will put substantial stress on supply chainplanning, especially if we consider constraints such as shelf-life and quickproduct changes. In the particularly hot summer in 2003, for example, it wasalmost impossible to get air conditioners in Germany. They were sold out afterfew hot weeks. By 2005, two years later, the prices have dropped by almosthalf, suggesting excess production after 2003 that still filled the warehouses.

All of the above mentioned characteristics make supply chain planningparticularly important for the consumer goods industry.

120 6 Consumer Products

Accurate forecasting, for instance, targets reduced finished goods inven-tory allowing a quicker response to changed customer buying behavior. Ideally,this happens in the framework of a collaborative demand planning process in-volving forecasts of key resellers that are fed into the planning logic of themanufacturer. Similarly, sophisticated production planning can help in bet-ter utilizing available capacity and in avoiding bottlenecks in the productionprocess and thus increase on-time deliveries from the manufacturer.

Scheckenbach and Zeier (2003, [84]) list various characteristic SCM re-quirements for the consumer products industry, among them those listed inTable 6.1. In the following section we describe how problems related to con-sumer products can be solved with SAP APO based upon a successful SAPAPO optimizer implementation in the beverage industry.

Industry Characteristic SCM System Requirement

frequent promotions 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, minimizewastage (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 lifeconstraints

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

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

6.2 The Carlsberg Case

Carlsberg A/S Denmark is Scandinavia’s biggest and the world’s 6th largestbeer 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. Thesupply chain optimization project, conducted by team members from a Scan-dinavian consulting company and SAP, went operational end of 2002. Thecase 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 mentionin Sect. 6.1 the project was focused on increasing the overall “speed” andcustomer service in the supply chain. High inventory levels at the distributioncenters in conjunction with sub-optimal transportation and manufacturingstrategies made it difficult to adequately react to quick market changes. Thecompany was limited in its ability to satisfy short-term customer demandchanges and depended on the quality of demand forecasting. A more general,but competing objective was to increase the customer service level, a goalintrinsically 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 SCM-project was spanning the whole range from long term planning, medium term(master) planning for the whole supply chain, and short term productionscheduling. In SAP APO, the tool chosen by Carlsberg, the involved modulesare Demand Planning (DP), Supply Network Planning (SNP) & Deployment(this is where SAP APO’s SNP optimizer is used), and Production Plan-ning/Detailed Scheduling (PP/DS).

Because of our focus on (MI)LP we will concentrate on the SNP opti-mizer piece in SNP & Deployment and refer to Kreipl and Pinedo (2004,[61]) and Pinedo (2005, [77]) for a more detailed description of the completeSCM process and its implementation in SAP APO. The references also in-clude some details of additional topics such as advanced safety stock methodsfor 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 coin-ciding with one of the plants, and a number of local warehouses/DCs. Trans-portation 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 possibletransportation paths, such as not all local DCs can be serviced from the firstplant. Figure 6.1 sketches this structure.

In the plants there are three principal production steps: brewing includingfermentation of the beer, filtering and filling into trading units. All three stepsare capacity constrained, but the bottleneck is usually the filling process. Atthe two plants there are two and four filling lines, respectively, with differentcosts and processing times. Integer variables are introduced into the modelby lot size constraints on the brewing and filling steps. Due to the fixed sizeof the brewing tanks orders of less than the size of the tank are rounded upto one full tank and larger orders are rounded up or down to represent aninteger multiple of the tank size. With the filling lines representing a capacitybottleneck, the filling quantities are to be chosen such that the filling resourcesare utilized to 100% capacity.

Typical process durations in industrial beer production are about 15–20days for brewing, 3–4 days for filtering, and one day for filling. Figure 6.2shows a diagram of the production process.

The products are segmented into categories A, B, and C according to theirsales volumes allowing different business processes to apply for the differentsegments. A is made up of the fast moving mass-products (Carlsberg Pilsand Tuborg Green) representing more than two thirds of the total businessvolume, B and C consist of the slow moving and more expensive seasonalproducts.

After the actual production processes the beer is transported from theplants to the regional distribution centers – either via the central DC ordirectly from the plant depending on the transportation quantity and theindividual product. Here, again, lot size constraints occur and of course lane-specific 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 8weeks in weekly time buckets. Discrete constraints (lot sizes) caused formu-lating the problem as a MILP problem. Several hundred products and severalthousand location products result in a MILP problem with several hundredthousand variables, over a hundred thousand constraints and many tens ofthousands 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 straight-forward way, other cost types in the model represent Carlsberg’s prioritiesand are much more complicated to compute. For instance, large efforts were1 The safety stock levels are calculated in a separate process taking into account

the desired service level, replenishment lead time, lot size, forecast error (forecasthistory 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 warehousesin order to resemble Carlsberg’s desired strategies for transportation and re-plenishment minimizing the effects of late deliveries in conjunction with safetystock violations in the different types of warehouses. Typical for a (MI)LP,the cost types are strongly interconnected and require good understanding ofthe whole cost structure to avoid unwanted results. While this may not bea surprise to a mathematician, it required much effort to explain this to thebusiness people during the implementation project.

The medium-term SNP optimization run results in a production plan forthe next 12 weeks giving details on planned production quantities in the threeproduction steps down to the level of bottles filled at each filling line and onthe planned transportation quantities between the locations. Planned stockquantities at each location are a direct result of this plan. The next step isdetailed scheduling including sequencing on the bottleneck resources which isdone 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 theMILP problem the project team applied product decomposition techniques. Atfirst, manual decomposition results in three runs for the Carlsberg products,taking into account that slow movers can typically be filled in certain fillinglines only and hence planning these first, then the B products and at lastthe two A products. Each of these three optimization runs itself – havingbetween 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 besolved for each MILP problem. The exact numbers depend on initial conditionslike number of customer demands to be planned and on the exact number oftime buckets (a planning run on Monday has more daily buckets than one onFriday because the first four full weeks are planned daily).

Given all sorts of consequences of decomposition per se an acceptable run-time of about 10 hours for an optimization process was achieved allowing adaily SNP optimization run. Effects like occasional huge gaps of up to 400%between the LP relaxation and the MILP solution have still to be explainedto the users very carefully (usually the gap is 0.2% – 10%; cf. Kreipl andPinedo, 2004, [61]), especially because Operations Research and/or optimiza-tion knowledge very often is missing in the customer teams when implement-ing business software like SAP products. Huge gaps like this often result froma demand that can be fulfilled by the LP relaxation, but not by the MILPproblem due to lot size constraints, for instance. Excess production resultingfrom discrete lot size constraints is one typical example requiring “OR coach-ing” – under certain circumstances the optimizer would suggest to round upproduction to the next full lot avoiding late demand penalties rather thanfalling short in supply avoiding excessive inventory cost... All in all, it is veryimportant to explain techniques like discretization (MILP) and decompositionalong with how they might effect the planning result very carefully.

7

Customized Optimization Solutions for theAutomotive and Chemical Industries

This chapter1 describes two case studies: a planning problem in the automo-tive industry and a scheduling problem in the chemical industry. Both areexamples of external optimization applications integrated into a SAP systemlandscape that supplement the standard SAP APO functionality.

Almost all projects in the area of Supply Chain Management at axentivbegin with a Supply Chain Assessment, or SCA. Within a four to eight weektime frame, axentiv consultants work closely with customers to identify ar-eas of the supply chain in which the most benefit can be achieved. The SCAincludes a feasibility study in which actual customer data are imported intothe axentiv Supply Chain Lab and several scenarios are evaluated. Throughthe Supply Chain Assessment it may become clear that the standard planningprocesses in SAP APO do not meet a customer’s needs. In this case, axentivis one of few companies able to integrate customized optimization solutionsinto an SAP landscape. Although the majority of SCM projects at axentivsuccessfully use standard SAP APO, the areas of optimization and integra-tion are also considered core competencies within the company. The two casestudies described below are examples of successful implementations involvingintegrated 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 followingplanning tasks: order-driven planning as well as forecast-driven areas of budgetplanning and master production planning. In order to get the best fit to theirplanning situation, the company became interested in an integrated optimizer1 Ruth Wassermann, Matthias Lautenschlager, Boris Reuter & Christian Steiner,

axentiv AG, Darmstadt, Germany, e-mail: {ruth.wassermann, matthias.lautenschlaeger, 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 initialfeasibility study with axentiv was performed in order to build an optimizerand prove its effectiveness. In the implementation phase of the projects, againcarried out by axentiv, ILOG’s cartridge technology described in Sect. 9.2was chosen to connect the custom optimizer to the standard software. In allcases, the CPLEX solver was called from ILOG’s OPL Studio, which was usedto model the underlying linear and mixed integer linear programming models.

In this section, we give an overview of two integrated optimization solutionsbuilt for a German automobile company. For each of these solutions, theplanning scenario is first discussed in general terms. Next, the correspondingmathematical model is described. Finally, we elaborate upon the user interfaceand 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 automobileindustry. In Fig. 7.1, rectangles identify planning tasks and arrows illustratethe flow of information. We will concentrate on optimization extensions in thefollowing areas: long-term, strategic planning and mid-term production andsales planning. In addition, an optimization extension was developed for thearea of order-driven planning, which is depicted in Fig. 7.2, as it is no longerbased on forecasts and uses real order information.

First, we describe the planning tasks of budget planning, master produc-tion planning and allocation planning, as classified in Meyr. At our particularcustomer, these planning tasks were partially rearranged and took place at adifferent level. We identify the differences to the Meyr classification system.

Budget Planning : an annual plan identifying production and sales quanti-ties of car models for the next year on a monthly basis.

Master Production Planning : plan with a rolling horizon providing a higherlevel of detail (i.e., weekly, rather than monthly) than a budget plan.

Allocation Planning : plan in which the aggregated quotas are assigned toa more detailed level.

7.1.2 Strategic Planning

The goal of this planning task is to create a long-range plan for up to fouryears in the future. The plan does not include the current fiscal year and findsgood feasible solutions for the following three fiscal years. Inputs to the planare projected monthly sales figures for various demand regions, provided bythe marketing department. On the production side, capacity is identified ata monthly, weekly and daily level. In addition, ramp-up information as wellas various sales constraints are taken into account. The plan includes desiredregional 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 127

procurement production distribution sales

pro-duction sales

Budget planning

pro-duction sales

Master production pl.

suppliersplants

(weekly)production

plansovertime

volume goals,earning goals,

annualworking time

(monthly)production& salesplans

MRP

retailers

demandplanning

allocationplanning

requestsof regions

requests formodels

detailedquotas

(weekly)aggregate quotas

productionplans

supplyplans

forecasts,take rates

take rates

(monthly)aggregate

quotas

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

procurement production distribution sales

plantassignment

Line assignment &model mix planning

promiseddates

(weekly)production ordersper plant

MRP &lot-sizing

allocationplanning

order promising

cars

daily bucketscustomerorders

JIT-calls

specificationchanges

distributionsequencingMRPsuppliersSILS

finalcustomerscar

sequence

procurementlot-sizes

daily buckets

specified orders

with due dates

customer &retailer orders

datailedquotas

(weekly)production plans,

overtime

aggregate quotas

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

the model takes into account country-specific requirements and model yearchanges.

Results of this plan are used to identify necessary personnel and equipmentchanges. For example, a planner may look into the costs and benefits of closinga plant during a given floating holiday in order to make an informed decisionon 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, themathematical model used for budget planning was kept as similar as possibleto the model used for master production planning. The model for masterproduction 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 currentfiscal year. In our example, the goal of this planning step is to develop a singleplan which encompasses the goals of both Sales/Distribution and Production.Inputs to this plan include information from both areas. Once a year, dis-tributors are asked to forecast their sales volumes for the next fiscal year ona monthly basis. These values are then updated once a month. This infor-mation is at the model level, with additional information such as motor andspecific features. After some negotiation, the distributors are provided withguaranteed volumes of automobiles per month for the next year. These vol-umes are referred to as “quotas”. Quotas are used to distribute the vehiclesfairly among the markets – both in the case where the market demand ishigher than production capacity as well as when the production capabilitiesare higher than the volumes demanded.

In addition to the quota values, Sales/Distribution is also able to giveinput on specific planning constraints. For example, one such constraint mightbe that 40% of all right-hand driven automobiles in a given month shouldbe shipped to Great Britain. The Production department provides detailson ramp-up activities for new production areas, as well constraints due toresource capacity and supply of components. These constraints include model-mix constraints, such as at most 35% of all automobiles produced in a givenweek may have a 6-cylinder motor or maximum 25% are allowed to be five-door models.

A plan is created using this information as well as various weights to penal-ize undesired outcomes. From this plan, we know the number of automobilesof each model / motor type as well as various attributes to be produced ineach 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 eachgroup member has the same penalty weights. After the optimal plan has beenfound, the automobiles are proportionally divided among the group membersbased on the originally requested amounts. The plan also identifies whichdistributors have shortages and surpluses per month and per fiscal year.

The developed optimizer creates a single mid-range plan which encom-passes 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 oftwo categories: production-oriented goals and sales-oriented goals. Both areasprovide inputs into the optimization problems, creating solutions acceptableto both parties.

The overall business goal is to create a plan in which total profit is maxi-mized, taking into account the various resource and other constraints. Avail-able capacities should be so well put to use that the vehicles and markets areemphasized, which have the highest profit margins or the highest chance ofsale. The profit maximization objective is not modeled directly. Instead, thedifferences to market demand and desired resource utilization are evaluatedand penalized. Penalty values are calculated based on priorities among thevarious vehicles and markets.

Secondary goals are the balanced and high level of resource use as well asdelivery within the month demanded.

Goals of the mid-range planning include the following:

• All distributor demands should be met as far as possible, while takingproduction 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 distributorsand vehicles of similar type

• Accommodate the distributors’ monthly demands with as little early andlate 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 distributorcombinations with lower priorities.

7.1.3.2 Constraints

The model contains the following constraints.

• Evaluation of the difference to meeting the required demand, both permonth and per year

• Evaluation of the differences in demand fulfillment among various distrib-utors 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 inthe 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 productionresources nor have the same planning constraints.

A second decomposition takes place in finding a good integer solutionquickly. First, the linear programming problem (LP) is solved. This solutionsolves the mid-range planning problem, except that the number of vehiclesproduced and provided to a given market must be an integer. The mixedinteger problem (MIP) is used as a sophisticated rounding mechanism, wherethe appropriate variables are integer and the solution meets all constraints.

In the next step, solution to the LP problem is used to restrict the valuesof the integer solution. Values in the LP solution which are already integerare fixed at this integer value. Non-integer values in the linear programmingsolution are used to form upper and lower bounds for the non-integer variables.For the case where an infeasibility occurs, these bounds are broadened andthe 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 strengthsand weaknesses of a plan using several key figures. The following Key Per-formance Indicators (KPI) are calculated in the cartridge based on the opti-mization results:

• total yearly quota / total yearly demand for each fiscal year and modelyear 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 re-source:

• information on each resource and planning constraint: utilization, upperand lower bounds on utilization

After running the checker, the planner decides whether to save or discard theplan 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 op-timization model, transferring data to the optimization server as well as theactual optimization process itself remain hidden from the user and happen“behind-the-scenes”. The custom optimizer used in the strategic and mid-range planning is completely represented inside a shared SAP user interface.Master and transactional data as well as optimization parameters are main-tained here. Where data for the mid-range and strategic planning were notavailable as standard SAP planning objects, the required user interfaces fordata input were developed.

Master data maintenance includes information on resources, validity datesand dates for the model year change. In order to influence the optimizationresults, profiles can be created containing sets of weights. These profiles canbe saved and reused for future optimization runs.

Each optimization run is started from the optimization cockpit, whichenables the selection of master data, weights and optimization parameters suchas time allocated for the optimization. After starting the optimizer, all relevantdata are read and a data validation takes place. Depending on their severity,resulting validation errors cause a warning to be issued or the optimization tobe stopped. A log is created, allowing the user to see all warnings and errors. Inaddition, the checker is fully integrated into the optimization cockpit, enablingthe user to evaluate the results directly after the optimization is completed. Ifdesired, the user can begin a new optimization with another set of parametersand compare results.

Once the planner has decided a given plan should be used, these results aresent back to the Business Warehouse (BW) system. These saved results areused in creating next month’s plan, in order to avoid unnecessary turbulencewhen new plans are created. Both quota and resource capacity informationresulting from the mid-range planning are considered in the order-driven plan-ning. The quotas are used as guidelines for the number of orders a distributorcan and must place. All orders within the quota values are taken into accountin the order-driven planning. On the production side, the resulting mid-rangeproduction values as well as supplier quantities are also considered in theorder-driven planning. These values are used in negotiations with suppliersand are binding for both parties.

7.1.4 Order-driven Planning

Meyr classifies various planning tasks of order-driven planning below. SeeFig. 7.2. Here, the planning tasks are triggered by actual orders, either fromindividual customers or retailers.

Plant Assignment : a plan in which the production orders have been as-signed to the plants.

132 Customized Optimization Solutions

Line Assignment and Model-Mix Planning: a plan in which the produc-tion orders are distributed among the assembly lines and then assigned to aproduction day.

Sequencing: a plan is created where the actual sequence of cars to beproduced on the assembly line is determined.

In our example, the goal of this planning task is to identify which orderwill be produced in which plant on which day. This single plan encompassesthe tasks of plant assignment and line assignment and model-mix planningdescribed above. The actual sequencing of the automobiles was not withinthe scope of the project. Side constraints are taken into account allowing forresource capacities as well as other planning restrictions.

7.1.4.1 Decomposition

In order to substantially decrease solution time, the main problem was de-composed into smaller problems. First, a linear program problem was solvedwhich found a plan using weekly time buckets. Next, a mixed integer programproblem was solved using weekly time buckets, where the solution space is re-duced by using the solution of the weekly linear program. Finally, daily mixedinteger programs are solved successively in order to place orders in a specificday.

In all models, the production period determined is a day. In the weeklymodel, the resource capacity is considered only at the aggregated weekly level,but an initial production day is calculated. In the daily models, the differenceto this day is evaluated and the model penalizes changing the planned pro-duction day.

7.1.4.2 Goals

Plan objectives are dependent on the time frame involved. In the short-termplanning horizon (next several days), it is important that the available pro-duction capacity be used. Gaps in the production line should be avoided, asthen the daily production capacity is not used. In the following weeks, the ob-jective is balanced production, which enables incoming orders to be producedon many different days. Bottleneck situations should be avoided to ensure thata specific order requiring a given feature or combination of features does notneed to wait weeks to be produced. The mid-range planning results provideassigned planning months for the individual orders. This distribution of ordersleads automatically to smooth production.

Goals include the following:

• minimize the difference to a given desired utilization value of the produc-tion 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 differencesto desired utilization take place on lower priority resources and differences tothe customer’s desired delivery date involve lower-priority orders. In addition,weights may be time-dependent, so that certain restrictions can be especiallyweighted 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 aplanner to quickly identify strengths and weaknesses of a plan. The followingKey Performance Indicators (KPI) are calculated in the cartridge based onthe 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 desireddelivery 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 theplan 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 theSAP user interface. This user interface includes standard screens for therelevant master and transformational data and customized screens for theoptimizer-specific parameters and control mechanisms, similar to those usedin the strategic and mid-range planning. The customized screens were createdin such a way that users do not notice a difference between the standard andcustomized screens.

From the user interface, acceptable results can be sent to SAP APO. Afterthe order-driven planning step is completed, SAP APO performs any necessarychanges to the customer order, such as changes to the production date, statusor location. In addition, internal tables containing resource usage are updatedaccording to the replanned orders.

7.1.5 Conclusion

The implementation of the Order-Driven Planning project was completedwithin six months. The Mid-Range Planning project was also completedwithin six months, after an extensive two-month blueprint phase in whichaxentiv was heavily involved. A project manager, an integration specialist, anoptimization specialist as well as user-interface development were required forboth projects.

As a result of the two projects, the time required to create feasible plans inthe areas of Order-Driven Planning and Mid-Range Planning was significantlyreduced. Previously, much time was spent by the planners creating feasibleplans which were not nearly as detailed as the plans currently created by theoptimizer. Much of the tedious work has been eliminated and planners spendmore 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 com-panies, which has divisions in the following areas: agricultural products andnutrition, oil and gas, performance products, chemicals, and plastics. Thiscase study focuses on the short-term detailed scheduling of a product in oneof the European divisions of the chemical company.

Approximately 500 products including commodities and specialized itemsare sold by the division. The products are wrapped in different packagingleading to a total of 1,500 saleable items. From the logistic point of view theproducts can be combined into product groups by considering characteristicsrelating to the production process.

In this case study, we will first define the overall planning scenario in whichthe 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, aswell as discuss the approximation methods used in the SAP APO ProductionPlanning/Detailed Scheduling (PP/DS) module. Finally, we will elaborate onthe actual cartridge and optimization problem, providing details on the flowof data, the user interface, and the objective function and constraints of theformulated optimization models.

7.2.1 The Architecture of the Complete Planning System

The detailed scheduling of the cartridge is part of a planning system im-plemented using SAP APO. The overall planning process is made up of thefollowing 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 calculatedby statistical models. The planning horizon is twelve months with a bucketsize of one month.

136 Customized Optimization Solutions

The demands are the basis for mid-term planning in Supply Network plan-ning (SNP), where resource capacity and material availability are taken intoaccount. The planning horizon here is also twelve months with a bucket sizeof one month. The results of this planning step are SNP planned orders whichgive the amount of product to be produced per month in each location as wellas 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 somespecial planning requirements described below, an extension with ILOG Car-tridge Technology was implemented for the three-month horizon. The resultsof this planning level are PP/DS planned orders, which give the exact pro-duction times of each product on each resource (machine). A further result isthe 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 ordersin 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 minimumand maximum throughput and changes to the melts on the smelter result insetup times, as well as a certain amount of associated waste product. To keepproduction running smoothly, the number of smelter setups as well as changesto 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 wellas possible additives. Each extruder has a minimum and a maximum allowedthroughput and changes to the throughput are allowed within this range. Thenumber of these throughput changes should also be minimized although thesechanges are able to be made more frequently than those to the smelters, asthey are less costly and time-consuming.

It is important to note that this is a continuous process. If the smelterthroughputs remain constant and the throughput on one extruder changes,the throughput on another extruder must be adjusted as well. All productwhich leaves the smelters must go through the extruders.

For example, assume the current smelter campaign sets the throughput ofsmelter 1 at three tons per hour and of smelter 2 at two tons per hour. Forsimplification purposes, assume we have only three extruders attached to thesmelters and that four end products are produced. Product 1 is made up of70% 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 ismade up of 40% Melt 1 and 60% Melt 2. Initially we produce Products 1, 2 and3 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. Thethree alternatives shown increase the throughput on the first extruder to 2.0tons per hour. This increase must be offset by another extruder (Alternatives1 and 2) or by an adjustment to one of the smelters (Alternative 3). This small

Ex Product t/h Melt 1 Melt 21 Prod 1 1.5 1.05 0.452 Prod 2 2.0 1.20 0.803 Prod 3 1.5 0.75 0.75

a) Initial Production

Ex Product t/h Melt 1 Melt 21 Prod 1 2.0 1.40 0.602 Prod 2 1.0 0.60 0.403 Prod 3 2.0 1.00 1.00

b) Alternative 1

Ex Product t/h Melt 1 Melt 21 Prod 1 2.0 1.40 0.602 Prod 2 2.0 1.20 0.803 Prod 4 1.0 0.40 0.60

c) Alternative 2

Ex Product t/h Melt 1 Melt 21 Prod 1 2.0 1.40 0.602 Prod 2 2.0 1.20 0.803 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 entriesin the “Melt 1” and “Melt 2” columns are specified in t/h.

example shows the complexity involved in adjusting extruders and smeltersto 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 Plan-ning / Detailed Scheduling (PP/DS) module. A general, “out-of-the-box” ex-act model would often have required extremely long solutions times, makingapproximation models the better choice. In the PP/DS module in SAP APOrelease 3.0 which is the release this case is based on, two approximation op-timization techniques are available: evolutionary algorithms and constraint-based programming. In general, the evolutionary algorithms work well onplanning problems where there is little difficulty finding a feasible solution.Here, the difficulty lies in finding very good solutions. Constraint-based pro-gramming works well on complex planning problems in which numerous de-pendencies 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. De-pending on the type of solution desired, each of the following can be weighted:total throughput time, total setup time, total setup cost, maximum cost oflateness, total late costs and sum of the costs for machine use.

In addition to selecting the approximation method and defining the penaltyweights for the objective function, the planner enters a time allotted for findinga solution.

7.2.3.2 Constraints

Here, we differentiate between hard constraints (which absolutely must bemet) and soft constraints (which may be violated, provided a penalty cost ispaid). 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 SAPAPO PP/DS (release 3.0) could be used to carry out the short-term detailedscheduling. The results of the study indicated that some important desiredfeatures 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 maxi-mum value. In order to model this in SAP APO, each allowable value wouldbe assigned a PPM mode. Further, the PPM identifies the length of produc-tion. These two factors lead to an explosion in the number of PPMs to bemaintained: for each of the 500 products, a separate PPM is required for eachsmelter or extruder with over 100 modi. Further, using the standard PP/DSheuristic would not be possible, since the heuristic would simply choose thefastest mode.

A further modeling issue was that the setup times for the smelters weredependent on the throughput before the setup takes place. That is, there areconstant volumes of product which are lost as waste in a setup, and thusthe setup time depends on the throughput. In SAP APO PP/DS, the setupmatrix only allows for constant times.

7.2.4.1 Cartridge Planning Scenario

Inputs to the problem include the monthly SNP planned orders, which providethe amount of each product per month to be produced as well as the locationto be produced. Other information includes master data found in SAP APOsuch as product and location descriptions as well as calendar information.

Finally, custom tables in SAP APO are used to store optimizer-specificinformation. The plan for the current month is used as input and consideredfixed.

Using the input data, the cartridge performs some preprocessing and datavalidation, prepares the database for the optimizer and calls the optimizer.The optimizer results are used to define the PP/DS process orders as well ascreate a corresponding PPM mode. These process orders are then transferredinto SAP R/3.

7.2.4.2 Optimization Problem (Overview)

A mixed integer program (MIP) was written in ILOG’s OPL Studio with theCPLEX solver to solve the optimization problem.

The optimization problem should deliver a schedule for the smelters andextruders for the next three months. That is, the product sequence, through-put and length of production on each smelter and extruder will be specified.This schedule takes into account resource constraints. In addition, raw mate-rial demands can be derived from the plan.

7.2.4.3 Decomposition

In order to substantially decrease solution time, the main problem was de-composed into smaller problems. First, the melt products are assigned tothe 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 at-tached smelters. The assignment of the complex extruders is time-consuming.By simplifying the problem and first assigning the melts for the complex ex-truders, 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 wellas the desired throughput is determined. The smelter throughput specifieshow many tons of product go through the smelter per hour. In addition,the extruder assignment for all extruders connected to only one smelter isoptimized.

For this model, several penalties multiplied by their corresponding vari-ables are minimized in the objective function. These penalty values are setby trained users. Several profiles were developed, enabling a user to choose aprofile depending on which penalties he or she would like to emphasize. Forexample, the user can choose a profile with high penalty cost for not fulfillingdemand or a profile in which smooth production is the most important goal.

Because adjustments to the smelters are costly (both in terms of changingmelts and throughput adjustments), the number of smelter setups as well asthe number and absolute volume of smelter throughput changes are penalized.There is a target value for the smelter production and the difference to thisvalue is penalized. Further, a penalty exists for going below a target campaignlength of a product on a melter or extruder.

Products can often be produced on more than one extruder. There is usu-ally a desired extruder for production, which is given priority 1. Less favorableextruders are given priority 2 or 3 and production of the product on these ex-truders will incur a penalty cost. In addition, penalty values exist for thenumber of days an extruder remains idle as well as early production leadingto storage costs.

The objective function includes the number of smelter setups, the num-ber of smelter throughput changes and the number of production days usingless favorable machines. Initial conditions must be considered to ensure thecorrect setups and throughput adjustments of the smelters and extruders atthe beginning of the planning horizon. Here, the previous planned values forthe time frame directly before the new plan begins are used. If productiondoes not follow plan, the actual values are used. Calendar information is alsoconsidered. No production should take place on a smelter during a day de-fined to be “idle” and smelter setups may only take place on specially definedsetup days. Further, smelter and extruder throughputs must lie within theirupper and lower bounds. Logical constraints to be met are, for example, theamount of melt used by the extruders must equal the amount produced bythe smelters and at most one melt can be produced per smelter and day. Asetup takes place each time a new product is produced on the smelter andproduct 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 ex-truders and reoptimizes the throughput of the attached smelters. From thesolution we know which products will be produced on which of the complexextruders on which days using which throughput. In addition, the solutioncontains optimized melt information for the attached smelters.

The objective function of the optimization problem contains several com-ponents to be minimized. In addition to the penalty values listed above forthe Smelter/Simple Extruder model, some penalty values are required for thisspecific model. Here, there is a penalty for the number of extruder setups andthroughput changes as well as the total absolute volume of extruder through-put changes.

The Extruder Model has constraints analogous to the Smelter/Simple Ex-truder Model. In addition, the mix relationships of the products must be takeninto account, since these products are formed using more than one melt. Thereare also constraints which ensure that products are allowed to be producedonly 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 bothplans to identify strengths and weaknesses of the plans.

Checker results are displayed as key figures in tabular form. These can besaved 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 theplan 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 in-terface greatly increases end-user acceptance. The user interface in this caseprovides 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 makessense for the problem. The planner chooses the location for which he or shewould like to see results. In the top half of the screen, the smelter results aredisplayed. Below these the extruder results are displayed. Zooming capabilitiesallow the planner to view results over a one week, one month or three monthtimeframe. The planner has the ability to modify a solution, run the checkeron the modified solution and save the results if desired.

Several of the desired GUI features were not possible using the standardPP/DS planning table. These include viewing the melt information in the tophalf of the planning table and the corresponding extruder information in thebottom half. In addition, starting the checker and viewing results would notbe possible using standard SAP APO PP/DS.

7.2.5 Conclusion

The implementation of this project was completed in November 2003 and theplanning process has been in use since that time. In addition to the overallproject manager, an optimization specialist, a user-interface developer and anintegration specialist were involved in the cartridge portion of the project.In June 2005, another area went live with a slightly modified version of thiscartridge using the overall planning scenario.

User acceptance is high. One reason for this is the specially developed userinterface and Checker, which enable users to modify an optimized plan in theGUI and to validate this modified plan as well as compare it to the originaloptimized plan.

7.3 The Future

These case studies provide examples of successful implementations of opti-mization extensions which are fully integrated into a standard software envi-ronment. Through the development of a customer-specific optimizer, the bestpossible fit to the customer’s requirements can be achieved. Further, the op-timizer can be fully integrated into the customer’s planning process. Throughthe judicious choice of optimization extensions and standard planning func-tionality, the advantages of both areas can be exploited and a more efficientoverall planning scenario can be achieved.

8

Operative Planning in the Process Industry

In this chapter we discuss a multi-location, multi-period planning problem ofderiving production plans for a network of multi-purpose chemical reactors.The full problem included finding optimal strategies in time and capacityfor opening or closing down reactor facilities; however, as this a beyond thecapabilities of SAP APO we do not consider this feature here but refer thereader to Kallrath (2002, [50]). Although this production planning case studyfocusses strongly on the MILP model it describes a typical case in which acomplete optimization solution has been implemented in industry prior to theintroduction of SAP APO. The questions then arises whether it is possibleto replace the system by SAP APO or to interface it as a tailored model. Inorder to do so, we add appropriate SAP APO related comments at the variousparts of the model. In addition, this case provides a good example of what isneeded in terms of documentation if a model external to SAP APO is to bedeveloped or maintained.

8.1 Problem Description

A company produces six products at four production sites. The productionuses five different raw materials. At two of the sites it runs a multi-purposereactor which can produce in three different modes. The finished products aresold from seven sales points.

Years ago, in the time when SAP and SAP APO where not yet so popularthe company developed a MILP based optimization model. The model wasimplemented in Dash’s modeling language mp-model and using the associatedsolver mp-opt – both are part of Dash’s optimization package Xpress-MP1.The optimization model enabled the planner to create production, distribu-tion, logistics and inventory plans based on user defined customer and market1 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, in-ventory and customer constraints. Demand usually means aggregated demandover a product for several customers; in some cases a demand can representa single customer. The overall objective was to maximize the companies totalrevenue for a one years planning horizon. In addition, the following objectiveswere considered:

1. Maximize contribution margin for the fixed design. No reactors will beopened or closed.

2. Maximize the contribution margin while guaranteeing a minimum per-centage of demand to be met.

3. Minimize costs while satisfying full demand. In order to avoid feasibilityproblems 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 de-

scribed 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 pur-chase, transport and inventory.

The optimization model enabled the human planner to create production,distribution, logistics and inventory plans based on user defined customer andmarket information while observing all relevant supplier, production, distrib-ution, inventory and customer constraints.

The problem was modeled based on 12 time slices (each one had a lengthof one month). In Section 8.2 the MILP model and its solution approach isdescribed. Using this model, the following solution was obtained, for instance.

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

Name of this scenario NiceCompany

TURNOVER (REVENUE) 174727273

Objective Function Scenario 9

Objective Function Value 174727273

COSTS

8.1 Problem Description 145

Variable Production 97192020

Purchase of raw materials 24827824

linear cost 23825324

nonlinear cost 0

fix and penalty cost 0

global, across period 1002500

start-up/cancellation 0

Transport: between demand points 0

Transport: sites to demand points 231732

Transport: between sites 75953

Change-over cost 575000

Inventory: demand points 3514

Inventory: sites 261704

Inventory: rented (in/out) 0

Inventory: throughput cost 0

Inventory: working capital transit 0

Inventory: one time cost 0

Inventory: disposal cost 0

Product purchase 11429720

Unbalanced Product Swap Cost 0

Delay cost 0

TOTAL COSTS (excl. design cost) 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 0

Total use of raw materials 41146

Total charged between reactors 51425

Total charged to tanks 66115

Total used from tanks 19909

Total net operative flow -> tanks 46206

Total net logistic flow -> tanks 0

Total net product flow -> tanks 46206

PLANT SYSTEM (days)

146 8 Operative Planning in the Process Industry

Days available during horizon 1260

Days mode reactors were active 414

Days needed for change-overs 50

Number of change-overs 50

change-overs at SITE 1 0

Plant system utilization rate 1.55

TRANSPORT RESULTS (mass unit)

total amount shipped (mass unit) 61537

INVENTORY STATUS (mass unit)

total initial stock 2250

total at the end of the horizon 2250

total initial stock (raw mater.) 1950

total end stock (raw material) 450

DEMAND STATUS (mass unit)

Total demands requested 55858

Total demands satisfied 46346

Total demands unsatisfied 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 productsand salable products

2. modes m: the reactors of the multi-stage production scheme may operatein several modes, also called production modes, described by a generalproduct-mode relation. The reactors are subject to sequence-dependentmode changes; one-to-one relations between products and modes aretreated 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 andstorage is possible and from which products are sold

5. reactors r: have attributes such as capacities (tons/day), minimum uti-lization rate, they obey topological relations

6. inventories i: site inventories and demand point inventories; demand pointinventories may be dedicated tanks, variables tanks or containers. Inven-tories 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 conceptof production site. This is needed for the interface to handle the possibil-ity of creating a location that only contains a group of tanks (or storageentities) that is connected to production sites and demand points by trans-port. This could be a tank terminal or an off site warehouse for examplethat receives rail and ship shipments from production sites and ships outtrucks 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 ob-serve that only one mode change per period is permitted. This assump-tions seems not to be a very serious restriction since a period has a lengthof a month and typically only one setup-change per month occurs.

2. Transport times are treated exactly if the time for transport correspondsto the discretization chosen for time or is smaller than the length of timeslices. If this is not the case shipment amounts are treated probabilistically(Kallrath 2002c, [50, Section 4.3]). In even longer-term scenarios transporttime should be neglected.

3. Only variable inventory costs are considered. They are based on capitalbound and interest rates, or operating costs.

4. Production utilization rates and associated constraints refer to utilizationper production time slices.

5. In order to support net present value considerations all cost related dataare discounted over time with a discount rate of p%. Discounting is onlyapplied in the design scenario.

6. Multi-mode inventory entities are modeled on the assumption that onlyone product can be stored; the change to another product be stored hap-pens in zero time; cost for changing products in a tank are only consideredin 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 ∈ B := {1, . . . , NB} : break points (nonlinear price structure)c ∈ C := {1, . . . , NC} : sales categoriesd ∈ D : demand pointsh ∈ Hsrpm := {1, . . . , NH

srpm} : remaining shelf-life timei ∈ I := {1, . . . , N I} : inventory entities or tanksk ∈ K := {1, . . . , NK} : production periods

148 8 Operative Planning in the Process Industry

m ∈ Msr := {1, . . . , Msr} : modes (depend on site and reactor)o ∈ O : origins, Odpcw feasible origins for a demandp ∈ P : productsr ∈ R : reactorss ∈ S : production sites / plantst ∈ T := {1, . . . , NT } : commercial periods (sales periods)v ∈ V : vendor (supplier)w ∈ W : packing or wrapping typesy ∈ Y : 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 ofreactors products at site s. Ps can be realized by the indicator table

ISRPsrp :=

{1, if product p is produced on reactor r at site s0, else

}

which also gives the scheme for how all indicator symbols are named; similarly,Rs is represented by ISR

sr . ISRPsrp is derived from the production rates RP

srmp

as

ISRPsrp := sign

(−1 +

∑m∈Msr

RPsrmp

)with sign(x) :=

⎧⎨⎩

+1 , x > 00 , x = 0

−1 , x < 0

⎫⎬⎭ .

Another indicator table we use is

IMCRsr :=

{1, if reactor r at site s is subject to mode-changes0, else

}.

If we would use IMCRsr as an input table it would tell us whether a reactor

is subject to mode changes. Alternatively, we might derive IMCRsr from the

production rate table RPsrmp as

IMCRsr := sign

⎛⎜⎝−1 +

Msr∑m=2

∑p∈P|RP

srmp>0

RPsrmp

⎞⎟⎠ ;

note that the sum covers m = 2 and higher, because any reactor has at leastmode m = 1. The production table RP

srmp also helps us to define the set Msr

Msr :=

⎧⎨⎩m

∣∣∣∣∣∣∑p∈P

RPsrmp > 0

⎫⎬⎭ =

{m

∣∣(∃p ∈ P∣∣RP

srmp > 0)}

.

However, we still keep numerical indices for m, i.e., Msr := {1, . . . , Msr}.

8.2 A Tailored MILP Model 149

The indicator table IRMsp tells us whether product p is a raw material. The

indicator table IPipisrpi

IPipisrpi :=

{1, if at site s reactor r can extract product p from inventory i0, else

}

establishes the topology. Similarly, we introduce an indicator table IPiposrpo

IPiposr :=

{1, if at site s reactor r can charge product p to inventory i0, else

}

Finally, we define the reactor-pre product table

IPPsrp′ = sign

⎛⎝Msr∑

m=1

∑p∈P |p�=p′

Rsrmp′p

⎞⎠

indicating whether reactor r at site s uses the product p′ as a pre-product atall; IPP

srp′ is derived from the product-recipe table Rsrmp′p.The table IEINV

dp indicates whether there exist any inventory entity atdemand point d which could store product p. IEINV

dp follows from

IEINVdp = sign

(∑i∈I

SCCdip

)

The indicator tables allow us to define further subsets

Ssdk :={sd ∈ S

∣∣sd �= s ∈ S ∧ k + T ssssd

< NK}

,

Ssk :={sd ∈ S

∣∣sd �= s ∈ S ∧ k > T ssssd

},

Dsdk :={d ∈ D

∣∣k + T sdsd < NK

},

Ddk :={dd ∈ D

∣∣dd �= d ∈ D ∧ t + T ddddd

< NT}

.

Another useful set is the set Odpcw of feasible origins associated with a speci-fied 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:

SPdpt salesp sales prices in $/ton

Ddpcwt demand demands in tonsPED

dpt extplims external purchase limits (tons)PES

spk extplimd external purchase limits (tons)

150 8 Operative Planning in the Process Industry

CEDdpt cstprchd cost for external purchase in $/ton

CESspk cstprchs cost for external purchase in $/ton

CBs cstbuy total cost for buying a plant

CBAs cstbuya annual cost for buying a plant

CFIXsr cstfix fix cost to operate a reactor

COsr cstopen total cost for opening a reactor

CSDsr cstsd total cost for shutting down a reactor

CSDAsr cstsda annual cost for shutting down a reactor

DAdp dmndattr demand attribute

DPt timedpp days per commercial period

Ddpcwt demforce force demand to be satisfied∆srm prodstrt initial state of all reactors of all plants∆F

srmk planfix fixed states of all reactors (derived from previous run)MC

sr chngmax max. number of mode changes on reactor r at site sMF

sr chngnot forbid mode changes on reactor r at site s in period kMsr nummodes number of possible modes on reactor r at site sMT

srm1m2chngtime time needed for mode changes on reactor r at site s

PMsp minprc s-c minimum production requirement of products

PSs minpri minimum production requirement for each site

PSCsp minpric minimum production requirement per site & product

PSPspk minprick min. production requirement per site, product & period

PSPsk minprik min. production requirement per site & period

RPsrp prodrate production capacity of reactor r at site s for product p

RPMCRsrmp prodratM prod. cap.: reactor r, site s in mode m for product p

RP minsrp prdminr min. production requirement for reactor r at site s

RU minsrp produtil min. % production utilization for reactor r & product p

SCRspk invrmax capacity of additional product stock

SCEsp invrend minimum requirement of product stock at end

SCCsp invsmax capacity of stock of products

SCMsp invsmin safety stock at site inventories

SCTsspk trpastss transport originating before first period

SCSsp invdini initial stock of site inventories

SPEdp invdend minimum requirement of product stock at end

SPCdp invdmax capacity of demand point inventories

SPMdp invdmin safety stock of demand point inventories

SPTsdpk trpastsd transport originating before first period

SPSdp invdini initial stock of demand point inventories

TPdd trtmdd transport times between demand points

TPsd trtmsd transport times between sites and demand points

TCss trtmss transport times between sites

TPMdd trmindd minimum transport requirements of products

TPMsd trminsd minimum transport requirements of products

TCMss trminss minimum transport requirements of products

TPDdpt trpastd transport from past

8.2 A Tailored MILP Model 151

TPSspk trpasts transport from past

TFdp cifprice specifies who pays freight

Ust timeslic number of production time slices in period t

In addition the problem is characterized by the following control parameters:

DPt : days per commercial period

IFKTO : flag: keep track of originsND : number of demand or sales pointsNK, NK

s : number of production time periods, at site sNM, NM

s : maximum number of modes occurring at any site, at sites sNP : number of productsNS : number of productions sitesOBJTY PE : type of objective function

Most of these control parameters are fixed once. Some others are computedautomatically 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 itsresolution to his or her needs. There are only a few input steps to be followed:

1. The planning horizon is divided into NT (commercial) time slices. Notethat NT does not depend on location.

2. The next step is to assign a number of dates to each time slice. In thesimplest case this number is the same for all locations.

3. To model sequence-dependent mode changes for each site separately, thecommercial time slice can be divided into any number of production timeslices. This allows for different numbers of production periods for each NT

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 NT time slices. Typ-ical we consider 12 months planning periods which equate to a year plus, ora 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 bechosen by the user using calendar dates or Julian dates. Each commercial timeslice t is supposed to have a length of DP

t days. For each site and commercialtime slice we define Ust production time slices with equal length. We dividethe entire planning horizon into NK

s production time slices of DPt /Ust days,

where Ust is the number of production time slices embedded in that com-mercial period. Regarding delivery or sale, usually a commercial time scale of12 periods (months) is chosen. Note that there is not a hard-wired structurewhich 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 lengthof about 30 days, and four additional ones with length of 120 days. Thus theproduction plan would cover a total time of two years.

In most cases, the production schedule has a finer resolution than the com-mercial plans for sales and shipping. Using two time scales, the resolution ischosen adequately for the purpose of both production planners and marketingpeople. The function

ks(s, t) :={

0 , if t = 1ks(s, t − 1) + Ust−1 , if t > 1

gives the number (minus one) of the production time slice starting at the be-ginning of commercial period t at site s, and, with ks referring to a productiontime 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 theproduction time scale referenced by t and r at plant s, and connects bothtime scales. For abbreviation, if sums cover the whole planning horizon, weuse k rather than k(s, t, u). Note that NK

s = k(s, NT, UsNT) for all s. If theproduction time scale and the commercial time scale are identical, we haveUst = 1, and k := k(s, t, u) = t. The different time scales embedded allow usto have smallest time slices relevant to production which may be of the orderof 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 theproduction time slice k at site s belongs to. It can be expressed in terms ofthe function ks(s, t) defined above:

tk(s, k) = the smallest t with ks(s, t) < k ≤ ks(s, t) + Ust

= arg mint

{t|ks(s, t) < k ≤ ks(s, t) + Ust} .

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

NT = 5; DPt = 360 ∀t; Ust = 12 ∀{st}

In a second example focussing more on asset evaluation the time horizoncovers 10 years with 2 production time slices per year which leads to

NT = 10; DPt = 360 ∀t; Ust = 2 ∀{st}

Note that the production rates should be entered as tons/day, times for modechanges and period reduction times in days. Let us summarize all the changesin 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 needsto be defined for all t

2. the sales price and demand table need to be adjusted and defined accord-ing to NT

3. the transport table for transport between demand points needs to beadjusted and defined according to NT

4. the transport table for transport between sites or from sites to demandpoints need to be adjusted and defined according to NK

s

5. the availability table for external product purchase needs to be rescaled,i.e., the amount of externally purchased product available must reallymatch what you can get in DP

t /Ust days6. all tables including data depending on production time slice k need to be

complete, or at least specified for k = 17. the first-opening possibility table for reactors has to be adjusted to account

for that k might have a different meaning for this time discretization8. 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 pro-duction time slice)

In order to support net present value considerations all cost related data arediscounted over time with a discount rate of p%., i.e., if C1 denotes the costapplicable to the first time slice, then the cost, Ck and Ct, for the productionand commercial time slices are given by

Ck = C1/(1 +

p

1200

)k−1

; ∀k ≥ 2

andCt = C1/

(1 +

p

100

)t−1

; ∀t ≥ 2 .

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 theproduction of multi-purpose plants frequently used in the food or chemicalprocess industry, or to model strategic design decisions of opening or clos-ing units as described in Kallrath (2002, [50]). In each mode such a reactorcan produce several products according to free or fixed recipes (joint produc-tion, co-production) leading to a general mode-product relation described bya set of yield coefficients: in a certain mode several products are produced(with different maximum daily production rates), and vice-versa, a productcan be produced in different modes. Mode changes correspond physically, forinstance, to a change of the temperature or pressure of a reactor, put thereactor 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 propor-tional 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- ormode-change per period; see also Kuik et al. (1994, [63]) for a survey on lotsizing 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 threeproducts to illustrate the flexibility of the concept of modes. The relevantinput quantity associated with the modes is the mode-dependent productionrate, RP

srmp, also called yield coefficient and usually specified in tons/day.Note that (8.16) allows to produce at rates smaller than RP

srmp.

reactor R1 R1 R1 R2 R2 R2 R2 R2mode 1 2 2 1 2 3 3 4product P1 P1 P2 P1 P2 P1 P2 P2RP

srmp 90 80 15 85 70 60 22 55

P1 and P2 are produced on several reactors. P1 is produced on R1 and R2in two modes. Mode 1 on R1 corresponds to exactly one product, P1, whilemode 3 on R3 allows two products to be produced. Note that mode 1 and 2on R1 are different from mode 1 and 2 on R2. For modes allowing more thanone product produced at a time, one needs to check whether the permissibleproducts are produced in fixed-ratio co-production or at independent variableor free rates.

8.2.2.6 The Variables

Here we give an overview on the variables. For convenience, some of the defi-nitions will be repeated when we discuss the constraints.

A group of non-negative (continuous) variables describes the production

pAsp : aggregated production (in tons) of product p at site s

pDsrr′pk : amount of product p charged from reactor r to r′ in period k

pPsrpk : production (in tons) of products p on reactor r in period k

pPMsrpmk : production (in tons) of products p on reactor r in mode m

pTsrpk : amount of product p charged from reactor r to local tank

pUsrpk : amount of product p used (converted) on reactor r in period k

uSsrpk : amount of product p reactor r takes from storage in period k

For mode-changing reactors (MCRs) we need to know how many days wespent in a mode m during the period k. This quantity is described by thenon-negative continuous mode-duration variables

mDsrmk : 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 conditionIMCRsr = 1) are traced by the state variables δsrmk ∈ {0, 1},

δsrmk :={

1 , if reactor r at plant s is in mode m at the end of period k0 , otherwise .

In order to describe sequence-dependent mode changes we introduce addi-tional binary variables with the following meaning

ξsrkm1m2 ={

1 , if δsrm1k−1 = δsrm2k = 10 , otherwise ; ∀

{sr

∣∣IMCRsr = 1

}∀m1, m2 ∈ Msr , ∀k

αsrmk :={

1, if reactor r is in mode m for some time in period k0, otherwise (8.1)

βsrmk :={

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

γsrmk :={

1, if mode m is terminated at the MCR-reactor r in period k0, otherwise

(8.3)and finally the binary variable χsrk

χsrk :={

1, if a mode-changed occurred on reactor r in period k0, otherwise

indicating whether a mode change occurred on reactor r at site s in period kor 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

sDdpt : stock (in tons) of product p at demand point d at the end of period t

sRdpt : additional or rented stock capacity of product p at demand point d

The stock variables are generated only if a maximum capacity entry exists forthe index combination sp.

In addition we have the dimensionless, non-negative semi-continuous trans-port variables

σdddd′pt : amount of product p shipped between demand points d and d′

σsdsdpk : amount of product p shipped from site s to demand point d

σssss′pk : amount of product p shipped from site s to site s′

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

156 8 Operative Planning in the Process Industry

sLdpcwot : sales of product p from origin o at demand point d

pESspvk : external purchase of product p from vendor v in period k at site s

pEDdpvt : purchase of product p from vendor v in period t at demand point d

(8.4)In addition, we might want to use the sales variables sLS

dpicwot where the ad-ditional index i indicate from which storage entities the amount of productp is extracted. Note that the sales variables are only generated for consistentcombinations of the indices d, p, and o.

The external purchase variables are subject to an upper limit. If in additiona lower limit is specified they are interpreted as semi-continuous variables, i.e.,

pEp = 0 or pELL

p ≤ pEp ≤ pEUL

p

This allows us to model the situation in which a vendor or competitor iswilling to provide support but asks for a minimum quantity to take if supportis offered.

Note that most of the variables are not needed for all combinations ofindices but rather for a few combinations indicated by some logical qualifiers;therefore we refer to these variables as sparse variables. Let us assume that themodeling language keeps track automatically of sparse variables appearing inconstraints. Thus, we give the logical qualifiers only at the first instance thevariable occurs in this report and we do not repeat them in the formulationof 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, jointproduction (co-production) and mode-changes. Note that all reactors have anindex for mode changing. If a reactor cannot undergo mode-changes then ithas just the index m = 1 in the list; the table IMCR

sr indicates whether reactorr at site s is a mode-changing reactor, i.e., has more than one mode. In anycase, for production, the following data are needed:

DPt timedpp days per commercial period

Hsrk number of days available for production and possiblymode changes on reactor r at site s in period k

HRsrm1m2k prodrdcp 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 kMT1

srm chngtim1 time for a mode change to mode mMT

srm1m2chngtime time for a mode change from mode m1to mode m2

RPsrmp prodrate production rates in tons per day, the amount of

product p which could be produced in mode m inone day on reactor r at site s

8.2 A Tailored MILP Model 157

RP minsrp prdminr min. production requirement of reactor r at site s

RU minsrp produtil min. production utilization of reactor r in percent

RRCsrmp′p prdrecip recipe coefficient to convert p′ → p

RFRsrmp1p2

prdfixrc fixed ratio for joint production of p1 and p2

Notice that Hsrk depends on k which gives us the opportunity to model tem-porary shutdowns (maintenance, test runs, etc.). The production rates RP

srmp

will also be used to indicate whether product p can be produced on reactor rat site s at all. If RP

srmp = 0 this is not possible. It is possible that a certainproduct can be produced in several modes.

For mode-changing reactors we set

HRsrm1m2k = max

{0, Hsrk − MT

srm1m2

}; ∀

{sr

∣∣IMCRsr = 1

}∀m1, m2 ∈ Msr , ∀k

(8.5)

where by definition

MTsrmm = 0 , ∀

{sr

∣∣IMCRsr = 1

}; ∀m ∈ Msr . (8.6)

Note that Hsrk or HRsrm1m2k is not required to be an integer quantity.

We will now first describe the mechanism of mode-changes, and in a latersub-section multi-stage production scheme.

8.2.3.2 Modeling Mode-changing Reactors

Reactors subject to sequence-dependent mode-changes are characterized bythe state variables δsrmk ∈ {0, 1},

δsrmk : ={

1, if reactor r is in mode m at the end of period k0, otherwise, i.e., in any other mode (8.7)

∀s ∈ S , ∀r ∈ Rs

∣∣IMCRsr = 1 , ∀m ∈ Msr , ∀k ∈ K .

These variables can be used to guarantee that at the end of time interval kreactor r at site s is in a unique mode, e.g., by equations of the form

Msr∑m=1

δsrmk = 1 ;∀s ∈ S∀r ∈ Rs

∣∣IMCRsr = 1

∀k ∈ K. (8.8)

However, as will become obvious below, it is not necessary to add the equationsexplicitly to the systems of constraints.

Note that some initial data ∆srm = δsrm0 have to be provided to definethe known status of reactor r at plant s before we start planning. Of course,these initial data must satisfy the condition

Msr∑m=1

∆srm = 1 ; ∀{sr

∣∣IMCRsr = 1

}. (8.9)

158 8 Operative Planning in the Process Industry

Exploiting Fixed Setup Plans Sometimes the state of all plants may be givenin advance, and one may want to fix the states of all plants to the states knownfrom another optimization run. Therefore, the model provides the option touse the states of all plants according to the bounds

δsrmk = ∆Fsrmk ; ∀

{sr

∣∣IMCRsr = 1 ∧ I∆ = 1

}, ∀m ∈ Msr , ∀k

where ∆Fsrmk 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 fixingthe setup while all other variables can be optimized with respect to the fixedmodes.

Keeping Track of Mode Changes It is one of the most fundamental assump-tions in this model that we can have at most one mode change per period. Ifthe states variables take the values δsrm1k−1 = δsrm2k = 1 we have a modechange from mode m1 to m2 in time interval k.

Both the continuity of modes and mode changes are traced by the binaryvariables

ξsrm1m2k ={

1 , if δsrm1k−1 = δsrm2k = 10 , otherwise ; ∀{s ∈ S , r ∈ Rs

∣∣IMCRsr = 1}

∀m ∈ Msr , ∀k ∈ K

This variable is unity if at the end of period k − 1 reactor r of plant s is inmode m1 and at the end of period k it is in mode m2. ξsrkm1m2 is a variablenot only describing whether a change-over occurs or not but it tells us whetherproduction continues. If the reactor is in mode m both at the end of periodk − 1 and k then we have ξsrkmm = 1.

The state variables and the mode-changes variables will now be coupledby some additional binary variables:

αsrmk :={

1, if reactor r is in mode m for some time in period k0, otherwise (8.10)

βsrmk :={

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

and finally

γsrmk :={

1, if mode m is terminated on reactor r at site i in period k0, otherwise .

These binary variables are related to the mode changing variables by theconstraints

βsrmk =∑

m1∈Msr|m1 �=m

ξsrkm1m ; ∀{sr

∣∣IMCRsr = 1

}, ∀m ∈ Msr, ∀k

8.2 A Tailored MILP Model 159

and

γsrmk =∑

m1∈Msr|m1 �=m

ξskmm1 ; ∀{sr

∣∣IMCRsr = 1

}, ∀m ∈ Msr, ∀k .

To express whether mode m is used at all in period k we have

αsrmk = δsmk−1 + δsrmk − ξskmm ; ∀{sr

∣∣IMCRsr = 1

}∀m ∈ Msr, k = 2, . . . , NT ,

and

αsrm1 = ∆srm + δsm1 − ξs1mm ; ∀{sr

∣∣IMCRsr = 1

}, ∀m ∈ Msr ,

(8.11)where ∆srm = δsrm0 denotes the known status of reactor r at plant s beforewe start planning.

Note that it is not necessary to declare ξ, β and γ as binary variables if wehave declared δ and α as binary variables.

Finally we have the following block of constraints:

γsrmk = δsrmk−1 − ξsrkmm ; ∀{sr

∣∣IMCRsr = 1

},

∀m ∈ Msr

k = 2, . . . , NT ,

or

γsrm1 = ∆srm − ξsr1mm ; ∀{sr

∣∣IMCRsr = 1

}, ∀m ∈ Msr ,

and

βsrmk = δsrmk − ξsrkmm ; ∀{sr

∣∣IMCRsr = 1

},

∀m ∈ Msr

k = 2, . . . , NT .

The constraints above complete our description of mode changes as far as thebinary variables are concerned.

Now we can also see why (8.8) is not required any longer. This followsfrom (8.9) and inspection of (8.11)∑m∈Msr

αsrm1 = 1 +∑

m∈Msr

δsrm1 −∑

m∈Msr

ξsr1mm ; ∀{sr

∣∣IMCRsr = 1

}.

If in the first period a setup-change takes place then∑

m∈Msrξsr1mm = 0 but∑

m∈Msrαsrm1 = 2 since production is possible in exactly two modes. Thus

we have∑

m∈Msrδsrm1 = 1. If no setup-change occurred then production was

possible in only one mode which gives∑

m∈Msrαsrm1 =

∑m∈Msr

ξsr1mm = 1which again leads to

∑m∈Msr

δsrm1 = 1.For convenience we also introduce the variables

∀{sr

∣∣IMCRsr = 1

}, ∀k | MC

sr < NK ∨ MFsr = 1

χsrk : ={

1, if a mode change occurred at s in k0, otherwise

160 8 Operative Planning in the Process Industry

indicating whether a mode change occurred on reactor r at site s in periodk or not. Note that the variables are only generated for those reactors r atsites s for which MC

sr < NK, i.e., the maximum number of mode changes onreactor r at site s is smaller than the number of periods, or mode changes areforbidden completely in period k, i.e., MF

sr = 1. The binary variables χsrk arerelated to ξsrm1m2k by

χsrk =∑

m1∈Msr

∑m2∈Msr,m2 �=m1

ξsrm1m2k ;

∀{srk

∣∣IMCRsr = 1 ∧

(MC

sr < NK ∨ MFsr = 1

)}.

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

NK∑k=1

χsrk ≤ MCsr ; ∀

{sr

∣∣IMCRsr = 1 ∧ MC

sr < NK}

. (8.12)

It is also possible to forbid mode changes on reactor r at plant s in period kby adding the lower bound

χsrk ≤ 1 − MFsr ; ∀

{sr

∣∣IMCRsr = 1 ∧ MF

sr = 1}

∀k .

Mode Capacity Constraints The mode-duration variables

mDsrmk ≥ 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 reactoris in mode m during period k.

Let us now start to formulate the mode capacity constraints as a functionof the change-over variables restricting the number of days the plant is in acertain mode. We first note that (8.13)

mDsrmk < HR

srmmkαsrmk ; ∀{sr

∣∣IMCRsr = 1

}, m ∈ Msr, ∀k (8.13)

is a valid upper bound. Remember that αsrmk carries the information whethermode m is used in period k or not. If the plant is never in mode m duringperiod 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 reducesto mD

srmk < Hsrk due to (8.6). Fractional values of αsrmk during the LPrelaxation or within the tree reduce the time the plant can be in mode mleading to smaller amounts of the products being produced in this mode.

Next, we want to compute the available capacities subject to modechanges. These constraints read

mDsrmk ≤

Msr∑m2=1

HRsrm2mk ξsrkm2m +

Msr∑m2=1|m2 �=m

HRsrmm2k ξsrkmm2

∀{sr

∣∣IMCRsr = 1

}, ∀m ∈ Msr, ∀k (8.14)

8.2 A Tailored MILP Model 161

and for ∀{srk}

Msr∑m1=1|Hsk �=0

mDsrmk ≤ Hsrk −

Msr∑m1=1|Hsk �=0

Msr∑m2=1|m2 �=m1

∆srm1m2ξsrkm1m2 .

(8.15)Constraint (8.14) defines the upper limit on the number of days of productionof product p on reactor r at site s in period k as a function of the modechanging variables. Days for mode m become available in period k only ifeither the reactor status switches to mode m in period k [first term in theright 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 reactoris m at the end of period k − 1 and k (i.e., ξsrkmm = 1 and no changeoveroccurs in period k), the value of the available capacity HR

srkmm is countedonce in the first terms. In any integer solution, by constraint (8.14), at mosttwo 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 beequal to the number of days available minus the number of days used for modechange. The second term can only be applied if ∆srm1m2 ≤ Hsrk. Otherwise,we should fix ξsrkm1m2 = 0 because there is not enough capacity in period kto perform the mode change from mode m1 to mode m2.

Inspecting the variables and constraints depending on the index m, we seethat we have, so far, 5M + M(M − 1) = M(M + 4) variables per reactor andper time slice; 2M of them are binary variables. There are 5M constraints.

Coupling Modes and Production The mode-duration variables mDsrmk are con-

nected to the variable pPsrpk,

pPsrpk ≥ 0 , tons of product p produced on reactor r at site s in period k

by the production rates RPsrmp. The indicator table

ISRPsrp := RP

srp +∑

m∈Msr|∃RPsrmp

RPsrmp ; ∀ {srp}

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

pPMsrmpk ≤ RP

srmpmDsrmk ; ∀

{srm

∣∣IMCRsr = 1

}∀p ∈ PE ; ∀k

(8.16)

and

pPsrpk =

∑m∈Msr|IsF

srp>0

pPMsrmpk ; ∀

{srm

∣∣IMCRsr = 1

}∀p ∈ PE ,∀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 inwhich a certain product could be produced there is no need to produce atfull capacity. For reactors subject to design decisions (ID

sr = 1) we require inaddition

pPsrpk ≤

Msr∑m=1|RP

srmp>0

HsrkRPsrmpθsr ; ∀

{srpk

∣∣ISRPsrp = IMCR

sr = IDsr = 1

}

8.2.3.3 Multi-stage Production

A certain reactor r is connected in a just-in-time fashion to one (or possiblymore) preceding reactors r′. This topology is described by the indicator tableIToposr′r which takes the value 1 if reactor r′ can charge to reactor r. Reactor 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 timefrom the reactor r′ or from an intermediate storage space. The total amountof product p′ reactor r uses to produce p is therefore

pUsrp′k = uS

srp′k +∑

r′|IT opo

srr′ >0∧ISRPsr′p′=1

pDsr′rp′k ; (8.18)

∀{srp′

∣∣IPPsrp′ = 1 ∧ IPipi

sr = 1}

, ∀k ,

where IPPsr′p′ indicates whether reactor r uses p′ as a pre-product at all, the

indicator table ISRPsrp 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

(if IPipisr = 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

pUsrP1k = uS

srP1k ; ∀{sr

∣∣IPPsrP1

= 1 ∧ IPipisr = 1

}, ∀k , (8.19)

because P1 is not produced on any reactor, and therefore

ISRPsrP1

= 0 ; ∀{sr} .

To model raw material availability it has to be ensured in the input data thatuS

srP1k 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∑m∈Msr

∑p∈P|ISRP

srp >0

RRCsrmp′pp

PMsrmpk = pU

srp′k ; ∀{srp′k

∣∣IPPsrp′ > 0

}.

(8.20)It is a matter of taste whether we apply the recipe coefficient to p′ or p. Inthe 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 givenmode m may produce several products p simultaneously and that the recipecoefficients depend on modes.

In addition to the multi-stage concept we also have to consider joint pro-duction. If the conversion of product p′ produces two products p1 and p2 in afixed ratio, we have

pPMsrmp1k = RFR

srp1p2mpPMsrmp2k ; ∀

{srmp1p2

∣∣∃RFRsrp1p2m > 0

}, ∀k ,

where RFRsrp1p2m defines the mode-dependent fixed ratio between the produc-

tion of product p1 and product p2. Modeling co-products or joint productioncan cover several real world situations: fixed recipe situation such as describedin Kallrath and Wilson (1997, Sec. 5.1), situations in which the co-product isseen, 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 ofco-products have to be specified.

If a co-product is produced and the co-product is a waste product, theconversion cost are interpreted as the cost of disposal. The solver will evaluatethe sum of the costs of the primary out and the co-products to determine ifit is worth while to produce the primary product.

The concepts described so far apply for all reactors, especially also for theMCR-reactor. The equations also hold for separated chains of reactors at onesite. Note that the reactor topology is completely described by ITopo

sr′r .The amount of products producible on reactor r at site s in period k is

limited by the capacity RPsrp specified in tons/day, i.e.,

pPsrpk ≤ Pmax

srpk ; ∀{srp

∣∣ISRPsrp = 1 ∧ IMCR

sr �= 1}

, ∀k , (8.21)

where Pmaxsrpk 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 separatedfrom the production of other products.

2. The discretization is appropriate to model the just-in-time requirements.

There may be also a minimum requirement on pPsrpk. Therefore, pP

srpk is asemi-continuous variable or subject to the disjunctive constraints, resp.

pPsrpk = 0 ∨ Pmin

srp ≤ pPsrpk ≤ Pmax

srp ; ∀{srp

∣∣∃RPsrp

}, ∀k

with

Pminsrpk := HsrkRP min

srp = HsrkRU minsrp RP

srp , Pmaxsrpk := HsrkRP

srp . (8.22)

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

164 8 Operative Planning in the Process Industry

pPsrpk = 0 ∨ Pmin

srpkθsr ≤ pPsrpk ≤ Pmax

srpkθsr ; (8.23)

∀{srp

∣∣∃RPsrp ∧ ∃ID

sr

}, ∀k .

The amount pPsrpk of produced product p is charged to a local tank (site

inventory) or charged to subsequent reactors. The distribution of products isdescribed by the distribution equation

pPsrpk =

∑i∈I|IP ipo

srpi=1

pTsrpik +

∑r′∈R|IT opo

srr′ >0

pUsr′pk; ∀

{srpk

∣∣ISRPsrp = 1 �= ISLP

srp

}

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 inven-

tories) couples multi-stage production, intermediate storage space and trans-port (between sites, and between sites and demand points), i.e., ∀{spk}

sSspk = sS

spk−1 + SSspk −

∑r∈R|IP ipi

sr =1

uSsrpk +

∑r∈R|(ISRP

srp =1∧IP iposr =1)

pTsrpk

−∑

s∈Ssdk

Tmssssd

σssssdpk −

∑d∈Dsdk

Tmsdsd σsd

sdpt−T sdsd

−∑

d∈Ddk

Tmddsd σdd

sdpt−T dddd

+∑

ss∈S(1 − ωsssk) Tmss

ssdσss

ssspk−(1−π)T ssssd

+∑

ss∈SωssskTmss

ssdσss

ssspk−π−(1−π)T ssssd

+∑

v∈VpES

spvk

(8.24)∑v∈V pES

spvk describes external purchase opportunity at site inventories. Notethat (8.24) supports a soft coupling of both reactor chains. Of course, if no in-termediate storage capacity is available the minimum and maximum inventorylimits are set to zero and (8.24) reduces ∀{spk} to

0 =∑

v∈VpES

spvk + SSspk −

∑r∈R|IP ipi

sr =1

uSsrpk +

∑r∈R|(ISRP

srp =1∧IP iposr =1)

pTsrpk

−∑

s∈Ssdk

Tmssssd

σssssdpk −

∑d∈Dsdk

Tmsdsd σsd

sdpt−T sdsd

−∑

d∈Ddk

Tmddsd σdd

sdpt−T dddd

+∑

ss∈S(1 − ωsssk) Tmss

ssdσss

ssspk−(1−π)T ssssd

+∑

ss∈SωssskTmss

ssdσss

ssspk−π−(1−π)T ssssd

(8.25)

8.2.3.4 Minimum Production Requirements

A typical constraint in production is the requirement that a certain productionutilization rate is achieved in each time period, e.g., RU min

srp = 0.8 or 80% of acertain theoretical capacity Pmax

srpk should be achieved. For constant Pmaxsrpk and

Pminsrpk = 0.8Pmax

srpk this leads to

pPsrpk = 0 or Pmin

srpk ≤ pPsrpk = Pmax

srpk ; ∀{sr

∣∣IMCRsr �= 1

}∀{pk}

∣∣∣∣Pminsrpk > 0 .

8.2 A Tailored MILP Model 165

If the branch Pminsrpk ≤ pP

srpk = Pmaxsrpk becomes active, we are sure that at least

Pminsrpk tons of product p are produced on reactor r at site s in period k, or

equivalently that a utilization of RU minsrp := Pmin

srpk/Pmaxsrpk is reached. However,

this approach for declaring pPsrpk 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 al-

ternative approaches: in approach A for minimum production utilization weget

Pminsrpmk := RP min

srp mDsrmk = RU min

srpm RPsrpm

Dsrmk , Pmax

srpmk := RPsrpm

Dsrmk

i.e., Pminsrpk and Pmax

srpk become depended on mode and on the variables mDsrmk.

Therefore, our first approach, in which semi-continuous variables and a con-stant were multiplied would lead to a product of a semi-continuous and acontinuous variable. In the second approach we would get

pPMsrpmk = 0 or Pmin

srpmk ≤ pPMsrpmk ≤ Pmax

srpmk ;∀{srpmk

∣∣IMCRsr = 1

}∣∣Pminsrpk > 0 .

(8.26)

The relation pPMsrpmk = Pmax

srpmk is already covered by (8.16). Let us now focuson the zero-production branch in (8.26). If we exploit (8.13) we note thatαsrmk = 0 implies mD

srmk = 0, and thus also pPMsrpmk = 0. Production is only

possible if mDsrmk > 0. The zero-production branch in the semi-continuous

condition (8.26) applied to pPMsrpmk does not make too much sense in this

context because the model has no incentive for the case mDsrmk > 0 and

pPMsrpmk = 0; even if mode m is active there is no implication that mD

srmk hasto be greater than zero (however, so far, the cases of very small numbers ofmD

srmk are not yet excluded; if those occur then the batch & campaign featureon mD

srmk should be applied). Therefore, we can replace (8.26) (without anyloss) by the simple constraint

RP minsrpm mD

srmk ≤ pPMsrpmk ; ∀

{srpmk

∣∣IMCRsr = 1 ∧ RU min

srpm > 0}

. (8.27)

The existence of (8.27) in the model file is controlled by setting the controlparameter DOUTMCR to DOUTMCR= 1. If mD

srmk > 0, then pPMsrpmk observes the

utilization rate RU minsrpm > 0; if mD

srmk = 0 then (8.16) implies pPMsrpmk = 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-changingreactors, again we need (8.27) for m ∈ Msr. Note that this approach will havea tendency to lead to small values of the variables mD

srmk if the utilizationconstraints cannot be satisfied otherwise. So, the results might often show a100% utilization rate with the reactors being idle for a time larger than thetime required for a mode change.

Alternatively, in approach B for minimum production utilization on modechanging reactors we could proceed with the following definition for the uti-lization rate of a reactor in a given period:

166 8 Operative Planning in the Process Industry

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

(8.28)

If we introduce the total production on reactor r

pRsrk :=

∑p∈P

pPsrpk ; ∀srk} ,

and if we define

rCAPsrk :=

∑p∈P

∑m∈Msr|RP

srmpmDsrmk

>0

RPsrmpm

Dsrmk ; ∀srk} (8.29)

to be the theoretical capacity of a mode-changing or design reactor we get theutilization rate

uRTsrk :=

pRsrk

rCAPsrk

; ∀{srk} (8.30)

The critical term is the denominator. The variable mDsrmk tells us how many

days reactor r spent in mode m. If we use the definition (8.28) we get

∑p∈P

Msr∑m=1|RP

srmp>0

pPMsrpmk ≥

∑p∈P

Msr∑m=1|RP

srmp>0

RU minsrp RP

srmpmDsrmk ; ∀{srk}

(8.31)or ∑

p∈P

Msr∑m=1|RP

srmp>0

pPMsrpmk = 0 ; ∀{srk} . (8.32)

Note that this approach is less restrictive than approach A because it puts aconstraint only onto the total production in a time slice. In addition it has anice 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 semi-continuous variables, have to be taken into account over the entire productionschedule, i.e., ∑

r∈R|ISRsr =1

NKs∑

k=1

pPsrpk ≥ Csp ; ∀{sp} .

As in the prior case of bounding the number of change-overs, these condi-tions (NDNPNK coefficients) are also replaced by the equivalent system ofequations with (1 + NK) coefficients

ptotsp :=

∑r∈R|ISR

sr =1

NKs∑

k=1

pPsrpk ; ∀{sp}

8.2 A Tailored MILP Model 167

and boundsptot

sp ≥ Csp ; ∀{sp} .

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

NP∑p=1

ptotsp ≥ Cs ; ∀s .

Finally, monthly minimum requirements Cspt

∑r∈R|ISR

sr =1

NKs∑

k=1

pPsrpk ≥ Cspt ; ∀{spt}

remain to be fulfilled.If CTRLSB = 1 the constraint∑

s∈S

∑p∈P

tPsp > Q1 (8.33)

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 sce-nario but not in the design scenario (OBJTYPE=5). The model formulation isbased on the concept of adding time-continuity to discrete-time models firstdeveloped by Kallrath (1999, [49]).

Batch production in the process industry operates in integer multiplesof batches where a batchis the smallest unit to be produced, e.g., 200 tons.Several batches following each other immediately establish a campaign. Theproduction may be subject to certain restrictions, e.g., campaigns are built upby a discrete number of batches, or that only campaigns of a minimal size canbe produced. It is also possible to model the requirement that a certain time-lag between successive mode-changes is observed. Within a fixed planninghorizon, 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 batchor campaign restrictions if the batch or minimal campaign size is larger thanthe capacity per period. Assume that production is performed in batches of200 tons, and that our time intervals have a length of ten days with a dailyproduction rate of 10 tons/day. The minimum time to produce the batch wouldcover 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 thirdonly partial) to produce exactly 200 tons, and thus provides more degrees offreedom.

168 8 Operative Planning in the Process Industry

Modeling Contiguity

To model contiguous quantities, e.g., the amount of production in a certaincampaign extending over several time slices, in the framework of discrete-timeformulations 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 start-ups of production in the time-slices, and the start-ups of the contiguousquantities);

2. we add the values of all contributing quantities belonging to a certaincontiguous quantity (we use indication variables which tell us whether acertain 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 continuityto discrete-time models has been developed recently by Suerie (2005, [93]).However, it seems that this formulation yet needs to be extended to supportmulti-stage production.Continuous Production Variables and State Variables An important interme-diate goal is to compute the amount, pC

srpnk, of product p ∈ P produced for acertain campaign n in period k ∈ T , and the total amount pC

srpn produced inthat campaign. Thus, our idea is to relate the production psrpk to a certaincampaign and then to add all contributions establishing this campaign.

The mathematical model, for this class of production planning problemsin the process industries, is assumed to be, for a certain site, unit, or reactorr ∈ R, based on some binary state variables δP

srpk indicating whether productp is produced on r in period t, and binary start-up variables δS

srpk indicatingwhether the production of p is started in period t on reactor r at site s. LetP−

rpk and P+rpk be bounds on psrpk if psrpk > 0. Once pC

srpn is available it ispossible 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,

pCrpn = Brp ; ∀{rpn ∈ N1} .

Alternatively, campaigns may be built up by a discrete number of batchesfollowing each other immediately, i.e.,

pCrpn = Brpβrpn ; ∀{rpn ∈ N1} , (8.34)

where the integer variable βrpn indicates the number of batches of size Brp

within campaign n. Finally, pCrpn, may behave like a semi-continuous variables,

i.e.,pC

rpn = 0 or C−rp ≤ pC

rpn ≤ C+rp ; ∀{rpn ∈ N1} , (8.35)

where C−rp and C+

rp 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 andstock of products associated with demand points. Concerning stock at demandpoints it is possible to lease some additional stock capacity.

At demand points products can be stored in dedicated product-origintanks, 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 storagetanks are dedicated tanks reserved for certain products, others can be usedfor several products each at one time. There is a set of rules when to fill atank or container with a product. The check tanks have only small capacitiesand are used to test the product quality. Variable tanks are filled and emptiedwhen sold up to a minimum level, and filled with the new product again. Thesafety stock of products in variable tanks needs to be discussed (or possibly:aggregated over all tanks). Multi-mode inventory entities are modeled on thebasis, that only one product can be stored; the change to another product bestored happens in zero time; cost for changing products in a tank are onlyconsidered 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 sitethen we talk about a dedicated product tank with no restriction on origin.Such inventory entities are called fixed-product variable-origin tanks and aredescribed by the balance equation

sSsipok = sS

sipok−1 +∑

v∈VpE

spvk + tISlspyk − tOS

lspyk −∑

r|IP ipisr =1

uSsrpk

+∑

r∈R|(ISRPsrp =1∧IP ipi

sr =1)pT

srpok ; ∀{sipok|o = “free”} (8.36)

with the source, sSsipok, from the previous period

sSsipok :=

{S0

sipo , k = 1sS

sipok−1 , 2 ≤ k ≤ NKs

(8.37)

with the initial product stock, S0sipo, and tIS

lspyk (tOSlspyk) denoting all incoming

(outgoing) transport at site s. The incoming transport tISlspyk at site s from

other sites l can be shipment in transit

SSspk :=

∑l∈S|∃SSS

lspk

SSSlspk

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

170 8 Operative Planning in the Process Industry

tISlspyk := SS

spk +∑l∈S

(1 − ωlsk) tLLlspk−(1−π)T ss

ssd

+∑l∈S

ωlsktLLlspk−π−(1−π)T ss

ssd

(8.38)where the specific amount of transport is given by

tLLlspt = t(l, s, p, t) := TMF

lspy TMINlspy σLL

lspyt (8.39)

including the factor TMFlspy , 0 < TMF

lspy ≤ 1, describing mass loss during trans-port and the sets are defined as

Ssdk :={sd ∈ S

∣∣sd �= s ∈ S ∧ k + T ssssd

< NK}

,

Ssk :={sd ∈ S

∣∣sd �= s ∈ S ∧ k > T ssssd

},

Dsdk :={d ∈ D

∣∣k + T sdsd < NK

},

Ddk :={dd ∈ D

∣∣dd �= d ∈ D ∧ t + T ddddd

< NT}

.

The outgoing transport at site s is established by shipments to other sites andto the demand points, i.e.,

tOSlspyk :=

∑sd∈Ssdk

∑y∈Y

tLLssdpk +

∑d∈Dsdk

∑y∈Y

tLLsdpk−T sd

sd+

∑d∈Ddk

∑y∈Y

tLLsdpyk−T dd

dd

The capacity bounds for product stock read

sSsipok ≤ SSC

sipo ; ∀k , ∀{ip

∣∣∃SSCsp

}.

The product stock should never fall below the safety stock

sSsipok ≥ SMIN

sipo ; ∀{spk} ,

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

sSsipok ≥ SCE

sipo ; ∀{sp} , k = NK .

The constraints applied to the inventory at the final period are selected bythe parameter INVRULE according to the following scheme:

INVRULE description0 no condition at all1 total inventory in final period = total initial inventory2 stock at the end = INV*INI3 stock at the end = INV*END4 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 end-product p the stock balance equation reads (otherwise we use the formulationin Sect. 8.2.3.7)

sDdpt = sD

dpt−1 + SDTdpt +

∑v∈V

pEDdpvt −

NC∑c=1

∑w∈W

∑o∈O

sLdpcwot −

∑s∈S

Tmdddd σdd

dd

+∑s∈S

Ks∑k=1|k+t1(s,d)≤Ks,t(k+t1(s,d))=t

(1 − ωsdk) Tmsdsd σsd

sdpk

+∑s∈S

Ks∑k=1|k+t2(s,d)≤Ks,∧t(k+t2(s,d))=t

ωsdkTmsdsd σsd

sdpk

+∑

d∈D|t>t1(d,dd)

(1 − ωdddt) Tmdddd σdd

ddpt−t1(d,dd)

+∑

d∈D|t>t2(d,dd)

ωdddtTmdddd σdd

ddpt−t2(d,dd) ; ∀{dp|∃SSCdp }, t = 2, . . . , NT

witht2(x, y) := t1(x, y) + π , t1(x, y) = (1 − π)T xy

xy

and π = 1 for short term planning (in that case times for transportation mustcorrespond to the time discretization) and π = 0 for long term planning (inthis case transport arriving are treated probabilistically). where T sd

sd denotesthe minimum transport amount and the time TP

sd needed to ship productsfrom site s to demand point d. Note that because TP

sd is used in the index itis required that TP

sd is measured in units of the period and that it is integral.For the first period, t = 1, sD

dp0 is replaced by SDSdp . where SDS

dp denotesthe initial stock of product p at demand point d and

SDTdpt :=

NS∑s=1|∃SP T

sdpt

SDTsdpt

denotes transport arriving in period t from shipment not originating withinthe current planning horizon.

If no inventory is available and there exists a demand Ddpcwt, i.e., ∃Ddpcwt∧.not.∃SPC

dp , then the sales variable sLdpcwot is immediately coupled to the trans-

port terms.Stock must never exceed the stock capacity, i.e.,

sDdpt − sR

dpt ≤ SCSdp ; ∀{dpt} ,

where sRdpt gives the current additional stock in a rented inventory. The addi-

tional stock is usually bounded by

sRdpt ≤ SCR

dp ; ∀{dpt} ,

172 8 Operative Planning in the Process Industry

and the safety stock bounds are

sDdpt ≥ SDM

dp ; ∀t , ∀{dp

∣∣∃SDMdp

},

and the bounds for the last period are

sDdpt ≥ SDE

dp ; ∀t , ∀{dp

∣∣∃SDEdp

}.

Note that these bounds are only considered if the corresponding stock capac-ities or safety stocks exist.

Variable Inventory Entities at Demand Points

To follow the stock we first have to compute the maximum number of tanksat a given sales point that can store the same product from the same origin

NTPdop :=

{1 , if ∃SPC

dpo

0 , else

NTAd := max

{i ∈ N|∃SCA

dn

}NTO

do := max{i ∈ N|∃SOC

don

}NTS

d := max{i ∈ N|∃SSC

dn

}NTP

dop is 1 if at demand point d a dedicated tank exists which stores productp from origin o. NTO

do , NTSd and NTA

d 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 wehave dedicated tanks, product variable and product-and-origin variable tanks.Additional (rented) tanks are treated like product-and-origin variable tanksin every respect. The four functions defined above give the number of tanks ofeach of this types. Note that per sales point, origin and product there existsat most one dedicated tank. If there exist more than one real-world dedicatedtank than the dedicated model tank has a capacity which is the total capacityof all of them.

The maximum number of tanks at demand point d to store product pcoming from origin o is given by

NTIdop :=

{NTS

d + NTAd + NTO

do + NTPdop | o �= “X”

NTSd | o = “X”

Note that the origin o = “X” refers to unknown origin, and that our tanks arelisted in this sequence: product-origin variable tanks, product variable tanks(can store several product coming from a fixed origin), and, last, the dedicatedtank (here, product and origin is fixed) if it exists. Products with unknownorigin 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 areempty in the case that the corresponding type of tank does not exist):

N Tdop :=

{i∣∣∣1 ≤ i ≤ NTI

dop

}

N TPOd :=

{i∣∣1 ≤ i ≤ NTS

d

}N TPA

d :={i∣∣1 ≤ i ≤ NTS

d + NTAd

}N TP

do :={i∣∣NTS

d < i ≤ NTSd + NTA

d + NTOdo

}N TV

do := N TPOd ∪N TPA

d ∪N TPdo =

{i∣∣1 ≤ i ≤ NTS

d + NTAd + NTO

do

}N T

dop, N TPOd , N TPA

d , N TPdo and N TV

do are the sets of tanks which can storeproduct p from origin o, product-origin variable tanks, product-origin andadditional tanks, product variable tanks and, finally, all variables tanks.

We then define the non-negative continuous stock variables

sDVTdipot ≥ 0 ; ∀{dpot} ∀i ∈ N T

dop

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 definethe stock in a rented variable product-origin tank

sDVRTdipot ≥ 0 ; ∀{dpot} ∀i ∈ N TPA

d

and the total amount of stock of product p produced at origin o of stock (tons)stored in containers

sDCdpot ≥ 0 ; ∀{dpot} .

Note that products can always be stored in containers. We can trace downinventories to the level of trace individual containers, or we treat the containersas aggregated stock capacities.

Instead of stock variables with names indicating its type we define genericstock variables sdipot and associate appropriate indication tables IDT

dipot, IVPTdipot,

IVPOTdipot , IDC

dipot, IRdipot indicating whether storage entity i is a dedicated, a

variable product or a variable product-origin tank, a container or a rentedinventory.

To keep track which product is in tank i, we define the binary variablesλdipot for variable tanks

λdipot :={

1, if tank i at d is filled with p0, otherwise ; ∀{dipot|i ∈ N TV

do } .

At demand points the model provides two inventory entities: tanks and con-tainers. 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 differentorigins. Tanks can either be dedicated or variable. Variable tanks can storedifferent products from different origins, dedicated tanks are assigned to oneproduct from a specified site or origin, resp. Furthermore, it is possible toconsider a strategic minimal stock amount for each product.

The stock situation is modeled by material balance equations. These con-nect incoming and outgoing flow over adjacent (commercial) periods. Pre-cisely, the balance equations connect the ends of the periods by consideringthe sum of inflow and outflow. This discretization scheme in time is based onthe assumption that incoming and outgoing flows in a given period take placein such an order, that the tanks (and containers) neither overflow nor runbelow zero. This assumption seems not to be critical, since in reality there arecertain small “check” tanks, that are not modeled and which can be used asbuffers for the rare products which usually have only smaller demands.

There are two different approaches to model the balance equations intanks, or storage entities in general. The first approach based on (8.40) allowsin instantaneous flow of material between appropriate storage entities. Thatway, for a given product, only the sum over all storage entities appears in theinventory balance equations (8.40). The amounts used for sales are extractedfrom these aggregated inventory balance equation.

Alternatively, we might apply inventory balance equations for each storageentity 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 amountof product p is extracted. If Idpcw denotes the set of all feasible storage entitieswhich might be used to satisfy a demand Ddpcwt then the more detailed salesvariables and the original sales variables are coupled by

sLdpcwot =

∑i∈Idpcw

sLSdpicwot

Note that this approach may add many continuous variables to the model.

Detailed Tank Modeling

For specified “known” origin o the balance equation reads

∑i∈NT

dop

sdipot + sCdpot =

∑i∈NT

dop

sdipot−1 + sCspot−1 − TSM

ss σddddpot −

NC∑c=1

sLdpoct

ND∑ds=1|ds �=d

TDDdsdpot + TSD

sdpt +R(s,t)∑

r=1|t>T Ssd

T IMsd σsd

sdpk(s,t−T Isd

,r)

−ND∑

dd=1|dd �=d∧t+T Dddd

≤NT

TSMddd

σdddddpot +

ND∑ds=1|t>T D

dsd

TSMdsd σdd

dsdpot−T Sdsd

;

∀{dpo} , t = 2, . . . , NT ,(8.40)

8.2 A Tailored MILP Model 175

where TSMsd and T IM

dd denote the minimum transport amount and TSsd the time

needed to ship products from site s to demand point d. Note that becauseT I

os is used in the index it is required that T Isd is measured in units of the

period and that it is integral; we could use the simplified transport scheme forvariable tanks as well but avoid it here for the sake of simplicity. The sum onthe left-hand side of the equation is the total storage of product p from plant sin any available tank. Note that the sum over all tanks on the right-hand sideimplies 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 initialproduct stock

NT Idop∑

i=NT Sd

+1

sdipot−1 −→NT I

dop∑i=NT D

d+1

SPDdipo , sC

dpot −→ sCodpo

leading to

∑i∈NT

dop

sdipot + sCdpot =

∑i∈NT

dop

SPSdipo + sCo

dpo −NC∑c=1

sLdpoct

−TSMss σss

sspot + T ISospt +

R(i,t)∑r=1|t>T I

os

T IMos σss

ospk(o,t−T Ios,r)

+NS∑

ss=1|ss �=s

TSSssspot −

NS∑sd=1|sd �=s∧t+T S

ssd≤NT

TSMssd

σssssdpot

+NS∑

ss=1|t>T Ssss

TSMsss σss

ssspot−T Ssss

∀{dpot} | ∃SPCdpo ∧ t = 1 (8.41)

Stock has never to exceed the stock capacity, i.e.,

sdNT Idop

pot ≤ SPCdpo ; ∀{dpot} | ∃SPC

dpo (8.42)

The product stock is further subject to safety level∑i∈NT

dop

sdpoti + sCdpot ≥ SM

dpo ; ∀{dpot} | ∃SMdpo . (8.43)

Note that these bounds are only considered if the corresponding stock capac-ities or security levels exist.

Additional or rented tanks i ∈ N TPAd , more expensive than regular ones,

are described by

sd,i+NTS(d),pot − sd,i+NTS(s),pot−1, ≤ sRdipot ; (8.44)

∀{dpo}, t = 2, ..., NT, ∀i ∈ N TPAd ,

176 8 Operative Planning in the Process Industry

where sRdipot denotes the rented capacity. Finally, we have to ensure that the

variable tanks contain only one product at a time. This is done by couplingthe binary variables λdipot to the inventory variables sdipot and later addingthe convexity constraints (8.47) and (8.48):

sdipot ≤ SOCdoi λdipot ; ∀{dpot} ∀i ∈ N TP

do (8.45)

for product variable tanks,

sdipot ≤ SCAsn λdipot ; ∀{dpot} ∀i ∈ N TPA

d

for additional tanks and

sdipot ≤ SSCdn λdipot ; ∀{dpot} ∀i ∈ N TPO

d (8.46)

for product-origin variable tanks. Note that (8.45) and (8.46) also serve as thecapacity constraints for the variable tanks.

The unique occupation of a tank is realized by the convexity constraints∑p∈P

λdipot ≤ 1 ; ∀{dot} ∀i ∈ N TPdo (8.47)

or ∑p∈P

∑o∈O

λdipot ≤ 1 ; ∀{dt} ∀i ∈ N TPOd ∪N TPA

d . (8.48)

guaranteeing that at most one of the binary variables is unity. If a tank isempty 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 boundedby ∑

p∈P

∑o∈O

sCdpot ≤ SCM

d ; ∀{dt} (8.49)

with upper bound or site-dependent container capacity SCMd .

8.2.3.8 Modeling Transport

The models considers three types of transport: transport of products betweenproduction sites and from production sites to demand points; in some rarecases there is also transport between demand points. The transport is de-scribed by transport cost depending on source, destination, product, andtransport means and is subject to minimal quantities to be observed andtransport times (typically a few days).

Regarding the length of the planning horizon and the discretization of timewe 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 quarterwith a time resolution of one week in which transport times can be approxi-mated by 0 or 1 week. In a years planning scenario (π = 1) with time slicesof one month and transport times of two or three weeks we would use π = 1and the following probabilistic approach. Let DPK

k be the length of the timeperiod k, ∆ be the time needed for transport and let us assume that

∆ ≤ DPKk , ∆ ≤ DPK

k+1 .

If we assume that shipments during production period k leave the site withuniform probability in period k the product will arrive at the destination sitewith probability

ωk :=∆

DPKk

=∆

DPt

U (8.50)

in period k + 1 and with probability 1 − ωk in period k. Therefore, in theone year planning scenario, we suggest the following heuristic approach toconsider transport in the inventory balance equations. If pT is the amount tobe shipped (appears as a loss term in at the site where transport origins) weconsider (at the destination of shipment)

(1 − ωk)pT

in the balance equation of period k and ωkpT in period k+1 as gain terms. Theprobabilistic approach (π = 1) is not recommend if the planning tool is usedoperationally. But for longer term planning is should be suitable, especially, ifthere exists some minimum inventory level. To test the probabilistic transportfeature, the probabilities could be set to ωk = 0 which should give identicalresults to the π = 0 scenarios.

Transport subject to product-specific capacities, Tmaxsdp , and conditional

minimum bounds, Tmsdsdp , is described by non-negative semi-continuous trans-

port variables

σdddd′pt : amount of product p shipped between demand points d and d′

σsdsdpk : amount of product p shipped from site s to demand point d

σssss′pk : amount of product p shipped from site s to site s′

The semi-continuous variables, for instance σsdsdpk, obey the definition

σsdsdpk = 0 ∨ Tmsd

sdp ≤ σsdsdpk ≤ Tmax

p ; ∀{sdpk} (8.51)

They are only generated if all the following conditions hold in the sense of alogical 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 orinventory 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.,

0 ≤ σsdsdpk ≤ S+ ; ∀{sdpk} .

A tricky feature to model is originating from site s in production period karriving at demand point d in commercial period t. The time associated withthis transport ∆sd, the length of the period is DPK

sk and thus ωsdk followsfrom (8.50).

Let us first consider the case π = 0; in this case ∆sd is an integer multipleof DPK

sk , i.e.,

Tsd =∆sd

DPKsk

.

Then a shipment originating in period k arrives in period k + Tsd. If thecommercial period t consists of Ust production time periods then all shipmentsoriginating in periods{

k = 1, . . . , NKs |t(s, k + Tsd) = t

}.

In the probabilistic approach (π = 1) transport is modeled as occurring prob-abilistically, 1 − ωsdk arrives in period k, i.e.,

1 − ωsdk ;{k = 1, . . . , NK

s |t(s, k) = t}

, σsdpk ,

and ωsdk arrives in period k + 1, i.e.,

ωsdk ;{k = 1, . . . , NK

s |t(s, k + 1) = t}

, σsdsdpk .

Note that there are two terms containing the variable σsdsdpk which leads to

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 withinthe planning horizon, i.e., if

π = 0: k + ∆sd ≤ NKs

π = 1: k + ∆sd ≤ NKs − 1

or, equivalently, if

NKs − [k + π + (1 − π)∆sd] ≥ 0 .

8.2 A Tailored MILP Model 179

Transports adds two types of variable costs to the objective function: costs fortransport and duty. Duty, CD

sd, ($/mass) must be paid when importing prod-ucts from another location. Transport costs and duty can be charged to themanufacturer or to the customer. We have neglected the index y for transportmean so far. To get the full model we need to replace σsd

sdpk by∑

y∈Y σsdsdpyk;

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 wishto get a product from a certain plant only, or they do not want to get it froma particular one, or that shipment should come from one plant only withoutspecifying this plant explicitly. Thus the model incorporates two sparse tablesDA1

dpcwo and DA2dpcw with the following meaning: if DA1

dpcwo is specified for acombination of demand point d, product p, sales category c, packing type w,and origin o then it is interpreted as follows:

DA1dpcwo =

{1 : shipment of p is allowed to come from origin o2 : shipment of p must not come from origin o

.

If DA2dpcw is specified, i.e., it exists, and has one of the following value

DA2dpcw =

{1 : at least one constraint is specified in DA1

dpcwo

2 : shipment of p always come from same origin.

If DA2dpcw 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:

Odpcw ={∪o|DA1

dpcwo = 1}

or, alternatively,

Odpcw = O∖{

∪o|DA1dpcwo = 2

}Note that in both cases we exploit full complementarity, i.e., the demandattributes for a certain order or demand should, for several origins o, onlyhave DA1

dpcwo = 1 or DA1dpcwo = 2 values.

In the case DA2dpcw = 2 the sales variables sL

dpcwot are coupled to the binaryvariables δT

dpocw generated if DA2dpcw = 2 exists. Note that there must be at least

one possible origin for the demand, defined in table DA1dpcwo, and that these

binary variables do not depend on time, i.e., they once enable a connectionfrom an origin o to sales category c at demand point d for product p, or theyforbid it for the whole planning horizon. This is ensured by the equations∑

o∈Odpcw

δTdpocw = 1 ; ∀{spcw} . (8.52)

180 8 Operative Planning in the Process Industry

Let us now couple δTdpocw and sL

dpocwt. The inequalities

sLdpcwot ≤ MδT

dpocw ; ∀{dpocwt} (8.53)

ensure that no sale of product p in category c from origin o at demand pointd is possible if δT

dpocw = 0. If δTdopcw = 1 then the inequalities (8.53) produce

the redundant bounds sLdpcwot ≤ M . Here, M is a sufficiently large upper

bound. The best choice [see Kallrath and Wilson (1997, [55, Sect. 9.1])] isM = 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”), ifDA2

dpcw is specified.

8.2.3.10 Including Demands and Demand Constraints

No more must be sold than is required by the demand, i.e.,∑o∈Odpcw

sLdpcwot ≤ Ddpcwt ; ∀ {dpcwt |∃Ddpcwt } , (8.54)

where Ddpcwt indicates how many tons of product p at time t are requestedat 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,in all objective function scenarios we enforce that a certain fraction, DF

dpcwt,of a particular demand has to be satisfied∑

o∈Odpcw

sLdpcwot ≥ DF

dpcwtDdpcwt ; ∀{dpcwt

∣∣∃Ddpcwt ∧ ∃DFdpcwt

}(8.55)

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 classA customer, then one might set DF

dpcwt = 1.If CTRLSB= 1, in the objective function scenarios 1,2 and 3 the total de-

mand, DT,

DT :=∑d∈S

∑p∈P

∑c∈C

∑w∈W

NT∑t=1

Ddpcwt . (8.56)

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

∑d∈S

∑p∈P

∑c∈C

∑w∈W

∑o∈O

NT∑t=1

sLdpcwot ≥ DT − Q2 ; (8.57)

is fulfilled. The minimum unsatisfied demand, Q2, can be computed by run-ning the “maximize sales” scenario. The inequality (8.57) is generated if thecontrol 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 besatisfied exactly, i.e.,∑

o∈Odpcw

sLdpcwot = Ddpcwt ; ∀ {dpcwt |∃Ddpcwt } . (8.58)

Due to lack of capacity it may happen that not all of the demand can becovered by own production. Therefore, it is very important to provide theoption to consider external purchase of products.

8.2.4 Defining the Objective Functions

The model covers several objective functions:

1. “maximize contribution margin”2. “maximize contribution margin while guaranteeing minimum demand”3. “minimize cost while satisfying full demand”4. “maximize total sales neglecting cost”5. “maximize net profit for design problems”6. “multi-criteria objectives” (max profit & min transport)7. “maximize total production” (for fixed design)8. “maximize total production of products for which demand exists”9. ”maximize total revenue” (for fixed design)

10. “multi-criteria objectives” (max sales volume & min cost)

The first one maximizes the contribution margin and includes the yield com-puted on the bases of production and the associated sales prices and the cost.The second one minimizes the cost while satisfying demand. In both casesthe following cost are involved: variable production cost, change-over cost,transport between sites, between sites and demand points, and between de-mand points, inventory cost for product and products, and cost for externalpurchase of products.

The objective functions depend on the following data:

SPdpcwt salesp sales price for p (category c) at d in t

CCsrm1m2

cstchang cost for mode changes on reactor r at site sCD

dpcwt cstdelay delay cost after t periods of delay for order {dpcw}CV

srp cstvprdc variable production cost (conversion cost)Ctrdd

ddpp csttrdd cost for transport between demand pointsCtrss

ssdp csttrss cost for transport of products between sitesCtrsd

sd csttrsd cost for transport for sites to demand pointsCRM

srpk cstrawmt cost for one ton of raw material p

CSDsp cstinvd cost for stock of products at demand points

CSSdp cstinvs cost for stock of products at sites

CSRdpt cstinva cost for rented inventories of products

CEDdpvt cstprchd cost for external purchase at demand points

CESspvk 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

y =∑d∈D

∑p∈P

∑c∈C

∑w∈W

∑o∈O

NT∑t=1

SPdpcwts

Ldpcwot (8.59)

based on the specific sales prices SPdpcwt.

Further more, the following cost are involved: variable mode-dependentproduction cost

cV :=∑s∈S

∑r∈R|IsR

sr =1

Msr∑m=1

∑p∈P

NKs∑

k=1

CVsrmpkpPM

srpmk . (8.60)

Note that the variable cost to produce products include the cost for the pro-duction 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 todistinguish different cases. If IPRDE

lpv = 1 we simply have

cLP :=∑s∈S

∑p∈P|∃CRM

spk

∑v∈V

NKs∑

k=1

CLPspvkpES

spvk . (8.61)

If IPRDElpv = 2 the situation becomes more complicated. Fix cost

∑s∈S

∑p∈P

NT∑t=1

RPENspt +

∑s∈S

∑p∈P

NT∑t=1

(RFIX

spt − RPENspt

)ωspt

have to be paid if the raw material is used (ωspt = 1), and penalty cost haveto be paid if it is not used (ωspt = 0). And, the specific price per ton of rawmaterial purchased is segment dependent. Let RBPC

spbk be the cost to be paidper ton of raw material between RBPV

spb−1k and RBPVspbk . The accumulated cost

at the breakpoint b are given by

RACCspbk := RACC

spb−1k + RBPCspbk

(RBPV

spbk − RBPVspb−1k

)with RACC

sp1k = 0. If RBPVspb−1k ≤ uR

spk ≤ RBPVspbk , i.e., µspbk = 1, then the total

raw material cost for purchase are

cRM : =∑s∈S

∑p∈P

NBs∑

b=2|∃RACCspbk

NKs∑

k=1

(RACC

spb−1k − RBPCspbk RRBV

spb−1k

)µspbk

+∑s∈S

∑p∈P

NBs∑

b=2|∃RBP Cspbk

NKs∑

k=1

RBPCspbk uRB

spbk

8.2 A Tailored MILP Model 183

or, if a alternative raw material formulation is used,

cRM : =∑s∈S

∑p∈P

NBs∑

b=2|∃RACCspbk

NKs∑

k=1

RACCspb−1kµspbk

+∑s∈S

∑p∈P

NBs∑

b=2|∃RBP Cspbk

NKs∑

k=1

RBPCspbk uRB

spbk .

Next we have the mode changing cost

cM :=∑s∈S

∑r∈R|ISR

sr =1

NT∑t=1

U∑u=1

Msr∑m1=1

Msr∑m2=1m2 �=m1

CMsrm1m2

ξsrm1m2k(t,u) , (8.62)

transport cost for products between demand points

cTdd :=∑d∈D

∑d∈Sdd �=d

NP∑p=1

NT∑t=1

CTdddddpT

MCddd

σdddddpt , (8.63)

transport cost for products between sites and demand points

cTsd :=∑s∈S

∑d∈D

∑p∈P

NT∑t=1

U∑u=1

CTsdsdp TMP

sd σsdsdpk(t,u) , (8.64)

transport cost for products between sites

cTss :=∑s∈S

∑s∈Ssd �=s

∑p∈P

NT∑t=1

U∑u=1

CTssssdpT

MCssd

σssssdck(t,u) , (8.65)

inventory cost for stock of products at demand points

cSD :=∑d∈D

∑i∈I

∑p∈P

∑o∈O

NT∑t=1

CSPdpitsdipot , (8.66)

inventory cost for stock of products at sites

cSS :=∑d∈D

∑i∈I

∑p∈P

∑o∈O

NT∑t=1

U∑u=1

CSCspiksS

spiok(t,u) , (8.67)

inventory cost for rented inventory of products at demand points

cSR :=∑d∈S

∑s∈Ssd �=s

∑i∈I

∑p∈P

∑o∈O

NT∑t=1

(CSR

dp − CSDdp

)sR

dipot , (8.68)

184 8 Operative Planning in the Process Industry

delay cost [the specific delay cost CDdpcwt after t periods of delay could be

constructed as CDdpcwt = f(t)CD

dpcw and f(t) could be any function of time,e.g., f(t) = t + 1 − CP

dpcw; we skip the details of computing dUdpcwt]

cDL :=∑d∈D

∑p∈P

∑c∈C

∑w∈W

NT∑t=1

CDdpcwtd

Udpcwt , (8.69)

and, cost for external purchase at demand points

cED =∑d∈D

∑p∈P

∑v∈V

NT∑t=1

CEDdpvtp

EDdpvt , (8.70)

and, finally, cost for external purchase at sites

cES =∑s∈S

∑p∈P

∑v∈V

NT∑t=1

U∑u=1

CESspvkpES

spvk . (8.71)

The total variable cost are then given by

c = cV + cRM + cM + cTdd + cTsd + cTss + 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 mostoften. A frequent question associated with interpreting the output of thisscenario is why certain demands are not satisfied. If in this scenario certaindemand 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) andoptimality is not yet proven.

It is hard to tell (unless the third reason applies) which reason caused unfilleddemands but the objective function scenario “maximize contribution marginwhile guaranteeing minimum demand” may give an indication. In order tocheck out the third reason it is recommended to search for the next feasibleinteger solution.

Note that in the “maximize contribution margin” scenario the total de-mand has to be satisfied up to a maximum amount Q2, i.e., in addition to theinequality (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 isrecommended to run the “maximize contribution margin” and to check atwhich percentage level P the demand is satisfied. Then the same objectivefunction (8.72) is used but needs to satisfy the additional inequality

∑d∈S

∑p∈P

∑c∈C

∑w∈W

∑o∈O

NT∑t=1

sLdpcwot ≥ S + ∆S (8.73)

where the left-hand side of (8.73) describes the total sales and ∆S is of theorder of a few percents. If ∆S is chosen too large the problem might turn outto 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 combinationwith (8.58). Infeasibilities due to lack of production capacity are excluded byallowing sufficient external purchase of products.

8.2.4.4 Maximizing Total Sales

In this scenario the objective function is

max∑d∈D

∑p∈P

∑c∈C

∑w∈W

∑o∈O

NT∑t=1

sLdpcwot . (8.75)

This scenario may be used to find out the total capacity of the productionnetwork with respect to a given demand mix. Note that no cost or salesprices are involved. Therefore, the solution may turn out to be financially notattractive. It can be used to check whether the total production of the modelroughly can reproduce the total sales in the business process. Note that itis not recommend to use objective function for differential testing in whichresults are compared to other optimization software. The reason is the highdegree of degeneracy in the objective function.

The motivation for this scenario is to handle cases in which the capacityis not sufficient to satisfy all demands but to sell as much as possible with theavailable production capacities.

We assumed that production capacity is not sufficient. So we certainlycannot 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 theproducts according to highest production capacities and avoids mode changescompletely. That is not what we want.

Including the yield and cost structure into the problem would in fact leadto the “maximize contribution scenario” and is not compatible with what weassociate with “maximize sales” because some production is neglected becauseis not attractive from the economic point of view.

The only consistent approach is the following interpretation: costs are ne-glected (almost) completely, and yields for all demands are set to an equalvalue, say, 1 $, or any realistic average yield. So we maximize sales, and therebytotal production, by trying to satisfy as much of the demand as possible. Thusthe objective function is simply

max∑d∈D

∑p∈P

∑c∈C

∑w∈W

∑o∈O

NT∑t=1

sLdpcwot

−∑l∈L

∑p∈P

∑v∈V

Tl∑k=1

0.9pElpvk −

∑s∈S

∑r∈R

Msr∑m=1

Msr∑m′=1∧m′ �=m

Tl∑k=1

ξsrmm′k .

The only cost that we consider are cost for external purchase, otherwise themodel will just satisfy demands by externally purchased products, because itgets them for free. In addition we put a soft penalty on mode changes. Thereis one consequence of this simple objective function which might produce so-lutions which might appear as “strange”. It is observed that much transportwill occur. However, first experiments showed that the solution achieved in“maximize sales” scenario can be improved in the “maximizing contributionmargin” or “minimize cost” scenario. This approach is supported by two ad-ditional output data produced in the “maximize sales” scenario: the totalproduction, Q1,

Q1 :=

∑s∈S

∑r∈R

∑p∈P

NKs∑

k=1

pPsrpk , (8.76)

and the total unmet demand volume, Q2,

Q2 :=

∑d∈S

∑p∈P

∑c∈C

∑w∈W

∑o∈O

NT∑t=1

(Ddpcwt − sL

dpcwot

). (8.77)

These numbers, Q1 and Q2, are provided to be fed in into the objective func-tion scenarios 1, 2 and 3 as additional constraints. This is controlled by thecontrol parameter CTRLSB to CTRLSB = 1.

Note that if initial and final stock are forced to be identical maximizingsales is equivalent to maximizing production. So, this scenario can tell us thetotal production capacity of the whole production network with respect to agiven 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 deci-sions and reads

max Z5 , Z5 = y − c − cD , (8.78)

where contains all cost related to the purchase of whole plants, the openingor the shut-down of reactors.

8.2.4.6 Multi-criteria Objectives

The current version of the software supports two special scenarios involvingmulti-criteria objectives which we solve by a preemptive (lexicographic) goalprogramming approach using objective functions ordered according to priori-ties [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 minimizeto the total amount of transport

tT :=∑s∈L

∑d∈Ls �=d

∑p∈P

∑y∈Y

NKs∑

k=1

TLLsdpyσLL

sdpyk . (8.79)

The idea of goal programming is to maximize the first objective (8.72), i.e.,

G1 := maxZ1

then derive a target (lower bound) on the first goal which, in the exampleshown below is 97% of G1, and minimize with respect to the second goal, i.e.,

min tT subject to Z1 ≥ 100 − 3100

G1 .

This approach can also be interpreted as follows. We optimize with respectto 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 belowshow the input to be provided by the user. The first P selects the preemptiveapproach, O indicates we wish to use objectives instead of constraints, the nextP’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 littledifferent 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 firstobjective function in the solution coincidences with the value of the targetderived 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

max∑s∈S

∑r∈R

∑p∈P

NKs∑

k=1

pPsrpk = max

∑s∈S

∑p∈P

tPsp . (8.80)

This scenario is primarily used for network testing or to find out the total pro-duction capacity of the production network. Note that no cost or sales pricesare involved, i.e., this scenario neglects all commercial aspects. Therefore, thesolution may turn out to be financially not attractive. In this scenario it ispossible 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 parame-ter DOSalesB which is set to DOSalesB= 0 if OBJTYPE= 7. Due to this featureit may happen that the sum of satisfied and unsatisfied demand is not equalto the requested demand (because, for individual demands more can be soldthan is requested).

This scenario is rather used for development and testing purposes. It can beused to check whether the total production of the model roughly can reproducethe production in the business process. Note that it is not recommend to useobjective function for differential testing in which results are compared toother optimization software. The reason is the high degree of degeneracy inthe objective function.

8.2.4.8 Maximizing Production of Requested Products

In this scenario the objective function is

max∑s∈S

∑r∈R

∑p∈PD

NKs∑

k=1

pPsrpk = max

∑s∈S

∑p∈PD

tPsp . (8.81)

This scenario may be used to find out the total production capacity of theproduction network with respect to a given demand mix. It is very similar tothe “maximize total production” scenario (OBJTYPE=7) but is a little closerto the economy because it considers only those products in the objectivefunction for which demand exists, and it also considers constraints on salesas specified by the control parameter DOSalesB. One should not be confusedthat the amount of total production shown in keyres.sum differs from theobjective function value. There might be more produced than contributes tothe objective function.

8.2.5 Implementation of the Model

The mathematical model is fed by data provided either as ASCII files or workareas 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 matrix PLAN1908 rows3012 structural columns9575 matrix elements142 rhs elements2591 bound elements

0 general integer variables50 binary variables824 semi-continuous variables0 partial integer variables12 directives

density is 0.166612 percent

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

The first (or second) feasible mixed integer solution is accepted as the solu-tion. This heuristic is justified because our trials indicate that its associatedcontribution margin deviates by only a few percent from that of the con-tinuous problem (well within the error associated with the input data) andbecause it eliminates the need for the time consuming complete search forthe absolute optimal solution via a B&B algorithm. Using the first objectivefunction the first feasible integer solution is usually found within 2 minutesusing 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 lowerbounds derived by the B&B algorithm before reaching optimality. In a maxi-mization problem the upper bound, zU, is provided by the LP relaxations zLP

while the lower bound, zL, corresponds to the best integer solution zIP found.The bounds zL ≤ z∗ ≤ zU on the objective function value z∗ of the (unknown)optimal solution lead to the integrality gap zU − z∗ or relative integrality

p := 100zU − zL

zL= 100

zLP − zIP

zIP

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 considerthe following intuitive approach to solve an MILP problem by solving theLP problem neglecting the integrality on the variables and then fixing thosevariables 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 tolarge integrality gaps. Consider

max x1 + x2 subject to−x1 + x2 ≥ 0.5

−0.8x1 + x2 ≤ 1.3 , 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 integralityconditions the solution of the LP relaxation follows as

x1 = 4 , x2 = 4.5 , ZLP = 8.5 .

In this example, the best integer feasible solution is

x1 = 1 , x2 = 2 , ZIP = 3

and thus the gap is about p = 183%. This example shows that the best integersolution may differ significantly from the solution of the LP relaxation. Itdemonstrates that simple rounding techniques are not sufficient and that theintegrality gap can be large. However, the situation could be improved bytightening 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 thesum or difference of two integer numbers – if it has to be greater or equal to0.5 – also has to be greater or equal to 1. Similarly, we decrease the bound ofthe 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 analyzedifferent “what happen if ...” scenarios. Typically, one might relax certainconstraints (e.g., increase the inventory capacity), or tighten other constraints(e.g., increasing the minimum batch size). If S and SR refer to a certainscenario and its relaxation, then we should observe the following relations fora maximization problem:

zU (S) ≤ zU (SR) , z∗(S) ≤ z∗(SR) . (8.82)

However, the solver may stop premature before reaching the maxima z∗(S) orz∗(SR) just returning the lower bounds zL(S) and zL(SR). Unfortunately, due

8.2 A Tailored MILP Model 191

to the mathematics of the Branch&Bound algorithm there exists no inequal-ities such as (8.82) relating zL(S) and zL(SR). Thus, for comparing integersolution of different scenarios one has to compute the optimal solution provid-ing z∗(S) or z∗(SR), or one just compares the relaxation zU (S) and zU (SR).Comparing zL(S) and zL(SR) is only recommended when at least two or threefeasible 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 con-tribution to cost characterized by demand point, product, sales category,packing type, origin, period, tons

4. Inventory Plans: location, inventory, product, origin, period, tons5. Transportation Plan: Production site, product, period, tons6. Transportation Plan: Demand point, product, period, tons7. External Purchase Summary : Demand point, product, period, tons8. Unmet Demand Summary : Demand point, product, period, tons9. Cost Summary: The cost summary involves the following information:

Production of products by production site, periodInventory of products by production site, periodInventory of products by sales, site, periodTransport of products by production site to production siteTransport of products by production siteExternal purchases by products, production site, period

An example of the financial summary looks like

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

TURNOVER 636682156

Objective Function Scenario 5

Variable Production 130935514Purchase of raw materials 39602003Transport: between demand points 0Transport: sites to demand points 22122065Transport: between sites 6593234Change-over cost 40000Inventory: demand points 8260095

192 8 Operative Planning in the Process Industry

Inventory: sites 55493321Inventory: rented (in/out) 0External purchases: demand points 5045417External purchases: sites 0TOTAL COSTS 268091647

CONTRIBUTIONContribution Margin 368590509

PRODUCTION (tons)production at LOCAT1 96881production at LOCAT2 54343production at LOCAT3 8814production at LOCAT4 46123production at LOCAT5 54750

Total production over all sites 260910Total external purchase demand p. 5045Total external purchase sites 0

Total flow of raw materials 160560Total use of raw materials 64105

Total charged between reactors 70021Total charged to tanks 190889Total used from tanks 128873Total net operative flow -> tanks 62016Total net logistic flow -> tanks 500Total net product flow -> tanks 62516

PLANT SYSTEM (days)Days available during horizon 6205Days mode reactors were active 290Days needed for change-overs 8Number of change-overs 2

change-overs at LOCAT1 2change-overs at LOCAT2 0change-overs at LOCAT3 0change-overs at LOCAT4 0change-overs at LOCAT5 0

TRANSPORT RESULTS (tons)total amount shipped (tons) 171894

INVENTORY STATUS (tons)total initial stock 56200

8.2 A Tailored MILP Model 193

total at the end of the horizon 8461

total initial stock (raw material) 7000total end stock (raw material) 103455

DEMAND STATUS (tons)Total demands requested 161049Total demands satisfied 115300Total demands unsatisfied 45749

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

8.2.6 Real Life Issues

8.2.6.1 Diagnosing Infeasibilities

Diagnosing infeasibilities is probably the hardest part of modeling and opti-mization, especially when new data are entered and first optimization runsare performed. Tracking down infeasibility in a large problem can be difficult.Users often ask “which constraint is wrong?” and are surprised when told thatthis is an ill-posed question. To see why, consider a small shop producing andselling bolts and screws. If the variables b and s denote the numbers of boltsand screws, we might have the constraints

b + s ≥ 62b + 3s ≤ 7 (8.83)

The first constraint might be a marketing constraint asking for a minimumdemand to be satisfied, while the second one might refer to some labor avail-ability. Neither of these constraints is wrong, they are just inconsistent whentaken with the non-negativity constraints of the variables b and s. Thus, wehave to have in mind that infeasibilities are related to the fact that certainconstraints have to be observed simultaneously. Removing a certain type ofconstraint may help to retain feasibility again. Infeasiblity can arise from anyor 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.00being mistakenly typed as 100. Some defensive data checks should be builtinto the user interface. Displaying data graphically often helps to catch sucherrors, and is a good reason for holding data in spreadsheets whose graphicalfacilities are advanced and easy to use.

Unfortunately, it is possible that the problem really is infeasible b) for thedata specified, and often there is no clear indication what causes the infeasibil-ities. 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 prac-tice. An IIS is a set of constraints with the property that if any one constraintis removed from the IIS set then the other constraints are consistent. In asense, an IIS is the smallest set of “nasty” constraints. Sometimes an IIS canhave a few members, and inspection of these gives a good guess as to wherethe problem is; but if an IIS has many members, the search for inconsistenciesmay still be hard work.

Diagnosing infeasibilities may be supported by listing infeasibilities whichoccurred previously. Infeasibilities have been resolved by:

1. Data Flow : Check whether the data are passed correctly from the spread-sheet or database to the modeling language.

2. Matrix Generation: Check the logfile produced by the modeling languagefor any problems or warnings.

3. Finite transport times: Since the model includes finite transport times itmay happen in the first time periods that some production requirementsor inventory constraints cannot be satisfied. This problems becomes severewhen modeling only a few time periods. This problem has been relaxedby considering incoming transport which originates before the first pe-riod within the planning horizon. However, it has happened that thoseamounts specified in transport-in-transit data exceeded the capacity ofthe 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 limitis chosen too optimistically the model becomes infeasible. The only thingto do about that is to decrease the lower limit.

5. Inventory Problems: Inventories have attributes attached to them whichdescribes the initial inventory, a target inventory at the end of the planninghorizon, safety level and their capacity. The initial stock level must observethe safety level and capacity as lower and upper bounds. The INVRULE flagdescribed on page 170 controls how the target inventory level is interpretedand coded into the model. It is recommend to set it to 0 for initial testruns. Otherwise, the target inventory needs to be consistent with the safetylevel and capacity.

6. Reactor Topology : There might be problems with newly defined reactorspositioning them into the network. During the matrix generation phasetwo files named indpipei.xpn and indpipeo.xpn are produced in the DATAdirectory. Use these files to check whether all reactors have access to ap-propriate raw materials and whether they are capable to charge theirproducts to the local site tanks.

7. Nonlinear Pricing Structure: Nonlinear pricing or the global discountingscheme has been invoked by INDPRDE = 2 or INDPRDE = 3 but the corre-sponding break point data have not been provided consistently.

If none of these cases applies and does not cure the problem we recommendthe 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 situationlook very strange and not plausible. Usually that is caused by similar reasonswhich lead to infeasibilities [see Section 8.2.6.1 on page 193]. It is recom-mended to run a sequence of models with increasing complexity and objectivefunctions types described on page 181:

1. choose objective function type 7 asking to maximize total production: thisscenario enables you to check whether production is possible, whether allreactors are attached to the network, and whether the total productionmatches the expected capacity (note that the model does not see any costand money related aspects; it will produce as much as it can and fills upall inventories);

2. choose objective function type 8 asking to maximize total production: thisscenario is similar to scenario 7 but it pays more attention to the currentdemand spectrum, but does not pay attention to cost either;

3. choose objective function type 4 asking to maximize total sales: this sce-nario enables you to check whether the flow from the production sites tothe demand points operates correctly; it might happen that demands arejust satisfied from inventory (note that the model does not see any costand money related aspects; it will just sell as much as it can and may justreduce the inventories to their safety levels);

4. if 7 (or 8) and 4 work fine, choose objective function type 1 to maximizecontribution margin;

5. if 7 (or 8), 4 and 1 work fine, choose objective function type 5 to concen-trate on the design problem

The user can activate or switch off certain types of constraints, e.g., controllingwhether 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 sup-ported by relaxing certain constraints. This concept is outlined using thefollowing example related to forced demand DF

dpcwt, which can easily make(8.55) infeasible. (8.55) can be relaxed if the control parameter DORELSB is setto DORELSB = 1 which replaces (8.55) by

sLRdpcwt +

∑o∈Odpcw

sLdpcwot ≥ DF

dpcwtDdpcwt ; ∀{dpcwt

∣∣∃Ddpcwt ∧ ∃DFdpcwt

}(8.84)

which includes the additional variables sLRdpcwt indicating which of the inequal-

ities of the original constraint (8.55) cause the problem. The variables sLRdpcwt

enter the cost term of the objective function as

196 8 Operative Planning in the Process Industry

cSLB :=∑d∈D

∑p∈P

∑c∈C

∑w∈W

NT∑t=1

3SPdpcwts

LRdpcwt .

Note that the specific costs associated with each of the artificial sales variablesis three time as high as the sales price of the useful product; does not showup in the yield term of the objective function. There is an ASCII output fileslr.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 ofmulti-location, multi-period, multi-purpose reactors. The purpose is to deriveoptimal production plans. On that abstract level one could claim that SAPAPO is able to do this. However, the question is whether this is really thecase when considering the philosophy of the existing planning approach andtaking a closer look when inspecting the various constraints and planningaspects describing the problem in detail.

Let us first summarize various aspects on the generic level before divinginto 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 reservedto short-term planning (PP/DS). A so-called setup matrix determines thesetup operations necessary when changing from a specific mode to anotherand is only available in PP/DS. Section 8.3.4 provides further commentson modeling multi-purpose reactors in SAP APO.

• Considering co-production is possible.

Thus, SAP APO allows modeling the process industry example model onthe whole. Locations, their corresponding location products, resources andthe production process models can be defined in the master data. The modechanging aspects cannot be modeled in SNP at this level of accuracy, but inPP/DS they can. The sales of products can be modeled as in the mathematicalformulation by including customers, distribution centers, or subsidiaries in thelocation master data. Locations can be connected by transportation lanes.

Let us now discuss a few structural features impacting the overall modelingfollowed 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 beformulated 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, trans-portation cost (between sites, between sites and demand points, and betweendemand points), inventory cost, and cost for external purchase (i.e., procure-ment) of products and raw materials are included in the model. With theexception of change-over cost for mode changes of a reactor, all of these costtypes 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 functionfor a PPM, but this does not directly account for multi-period lots resultingfrom 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 optimizerwill only schedule one setup operation per production campaign using capacityon a setup resource which can be associated a cost.

As nonlinear costs are beyond the scope of (MI)LP modeling, SAP APOuses the same approach of piecewise linear cost functions as the mathematicalmodel does. See Sect. 4.2.1 for defining piecewise linear cost functions. Convexcost functions are characterized by a cost per unit that increases with highervolume and can be modeled in an LP. Concave cost functions (costs per unitdecrease with higher quantity) require a MILP model.

Material that has to be burnt because of a lack of demand can incur costwhen modeled as product with associated shelf-life, for instance. However, amore detailed analysis of the business requirements and impacts on modelingis necessary to come to a final conclusion on this.

Overall, these features are sufficient to model the basic idea of the rawmaterial costs described in Section 8.2.4.1.

8.3.2 Objective Functions

In SAP APO the mathematical representation of the objective function can-not be defined freely. As a consequence, custom objective functions are imple-mented either by adjusting the cost structures on the SAP APO applicationlevel or with development support from the optimization group of SAP.

The model described in Sect. 8.2 supports ten modes of operation definedby ten objective functions as listed in Sect. 8.2.4 (pp. 181):

Maximize contribution margin is the “standard” operating mode of theSNP optimizer. Because SAP APO regards the individual non-delivery penal-ties 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 isbased on the same objective function, but the model includes an additionalhard constraint that puts a lower bound on the total sales quantity. A con-straint exactly like this is not included in the SNP optimizer and including itwould require a custom project with the optimization group of SAP. A possi-ble 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 couldprobably be implemented by introducing disproportionately high penalties fornon-delivery that have to be removed in post-optimization processing.

Minimize cost while satisfying full demand includes a hard constraint forexactly fulfilling each demand element, only costs are considered and revenueis ignored. Again, this constraint is not part of the model formulation inSAP APO, but can be simulated by introducing disproportionately high non-delivery penalties.

Maximize total sales neglecting cost ignores all cost and maximizes thesales volume. This can be modeled in SAP APO by switching off all costs butthe late and non-delivery costs in the SNP cost profile and setting these costsappropriately (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 plantsand opening/closing of reactors. As network design is no longer included inSAP APO this scenario cannot directly be modeled.

Multi-criteria objectives (max profit & min transport) and (max sales vol-ume & min cost) optimize regarding the first objective (i.e., max profit), andthen seek a solution optimizing for the second objective (i.e., min transport)with an additional constraint limiting the deviation from the first objectivefunction value. This cannot be implemented in SAP APO as-is, but dependingon the individual business targets to be achieved similar results may be accom-plished 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) pro-portional 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 thesame as the scenario above, but considers producing only those products forwhich demand exists. Again, commercial aspects and the limitation of salesvolume to demand volume is not included. In SAP APO this is modeled asabove, but with zero cost for products without demand.

Maximize total revenue (for fixed design), finally, is the same as the firstscenario (maximize contribution margin), but without considering costs. Thiscan be done in SAP APO by deactivating the appropriate costs in the SNPcost 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. Thequantity of delivered product is of course limited to the total demand. Thisis 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 ag-gregate over all individual customer orders and forecast elements in a specifictime bucket at a specific location.

Instead of constraining the service level by including hard constraints onfulfilling a minimum fraction of each demand, the SNP optimizer uses the coststructure to ensure demand fulfillment. Obviously, post-optimization analysiswould then be needed to “correct” the non-delivery penalties to reflect theactual revenue.

As an example, total demand fulfillment can be enforced by making pur-chasing 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. Themodel objects described at the beginning of Sect. 8.2 (p. 146) are translatedinto master data directly following from our description of modeling in SAPAPO in Chapters 3 and 4.

1. Products: They are actually called products in SAP APO and for theirlocation-specific properties the master data element location product isused. By using this concept production, procurement, storage, etc. aremodeled by location where the product can occur.

2. Production Modes: In essence, the mode a reactor can operate in definesthe available production processes that can be run on the particular reac-tor. 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 capac-ity of which is consumed in the PPMs representing the different modes ofproduction. The product to produce along with considerations concerningmode changes determine which PPM is selected. Co-production is part ofthe PPM and considered by the optimizer. Mode changes are modeled asproduction campaigns that eliminate setup operations and setup costs ifthe same PPM is used for production in consecutive time buckets (calledtime slices in Sect. 8.2). For using such production campaigns cross-periodlot size planning which considers setup operations (here: mode changes)for the same PPM in the previous time bucket has to be activated in theoptimization profile (see Sect. 4.2.1). Currently (SAP APO release 4.1), inthe SNP optimizer setup operations cannot be modeled depending on themode the reactor is changed from. As a consequence, sequence-dependentmode changes as required by the process industry example cannot be im-plemented using SNP. Following the hierarchical planning strategy, how-ever, sequence-dependent mode changes can be modeled in PP/DS viathe setup matrix .

3. Production Sites: In SAP APO, these are modeled as locations of typeproduction 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 oftype distribution center, customer, or even as production plants that areconnected by transportation lanes. Choosing the location type depends onmodeling preference and business requirements.

5. Reactors : The basic properties of the reactors are described in the resourcemaster data. The PPMs (see above) connect the reactors to a productionnetwork and represent the different modes of production.

6. Inventories: In SAP APO inventory can reside at each location. Depend-ing on the required level of detail inventory constraints such as maxi-mum product-specific storage quantity are specified in the location prod-uct master data or modeled more flexibly by assigning storage resourcesto locations.

8.3.4.1 Basic Assumptions and Limitations

1. The SNP optimizer does not specifically restrict the number of setup op-erations per period. However, setup costs and setup times will most likelylead to small numbers of mode changes. Note the issue regarding modechanges described in Sect. 8.3.4.

2. Transportation times and costs can be specified using cost functions. It isnot possible to provide probabilistic transport times in SAP APO.

3. Variable inventory costs containing the capital binding costs can be mod-eled in SAP APO.

4. In SAP APO resource utilization rates and constraints on them refer totime buckets.

5. Table 1.1 on page 19 lists the types of costs that are considered by the SNPoptimizer. The time-dependent costs can, of course, be discounted overprogressing time buckets. Some of the remaining costs (such as produc-tion cost, for instance) can be made time dependent when the underlyingobjects (the PPM, for instance) are made valid for certain time bucketswhich results in a high number of PPMs to be maintained.

6. Multi-product inventories with product-specific constraints are possible inSAP APO. However, there is no mechanism that restricts the number ofdifferent products that can be stored at any given time in the SNP opti-mizer. Also, sequence-dependent mode changes in inventories cannot bemodeled directly. This would require certain sequence-dependent opera-tions such as tank cleaning connected to discarding of remaining inventory– either burning it off or consolidating into other tanks. When moving toPP/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 pub-licly 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 wayin SAP APO, some – like time discretization – are approached differently.

The time discretization distinguishing between commercial and productiontime slices would most probably be modeled as a post-optimization planningbook feature in SAP APO: the planning itself would take place on the moredetailed time buckets and the results would be aggregated in according plan-ning 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 optimizationmodel and the equations in Sect. 8.2.3 due to the confidentiality of the math-ematical model formulation.

In SAP APO multi-stage production processes are modeled by generat-ing several PPMs which can include co-production. How to deal with mode-changes 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 wellas bounds on utilization of the reactors. There is a large variety of detailsinvolved in these constraints. In SAP APO one possibility is to include con-straints on resource utilization by defining resource variants (see Sect. 3.2.4.2);this translates into bounds on utilizing the reactors. Minimum productionquantities of certain products cannot be modeled explicitly; workarounds viathe cost structure or minimum lot sizes on PPM level exist and have to bealigned with the client’s business objectives.

Batch and Campaign Production

Batch and campaign production has an aspect regarding mode changes andminimizing setup costs and time and additionally we can limit productionquantities to integral multiples of a batch size. The first issue has been men-tioned multiple times in this chapter (Sects. 8.3.1 and 8.3.4); the condition ofproducing integer-multiples of one batch is used in our supply chain exam-ple described in Chapters 3 and 4 and is activated in the discrete constraintssection 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 enti-ties. Inventory has the attributes capacity, safety stock, storable product(s).Additional stock capacity can be leased at higher per unit costs than thenormal capacity. In SAP APO this is modeled as accordingly higher costsor 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 capacityvariants.

With the exception of multi-mode inventory that can hold only one prod-uct out of many at any given time SNP could handle the functionality ofthe model. Multi-mode inventory can be modeled using container resources inSAP APO (those can hold only one product at a time), but they are availablein 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 transporta-tion lanes we can control possible sourcing of the stored material. Safety stockconstraints are part of the SNP model and can be considered at any locationin the supply chain.

Modeling Transport

All three kinds of transportation, between production sites, from productionsites to demand points, and between demand points, are modeled as trans-portation lanes in the same way. The lanes can have product-specific prop-erties such as costs, minimal and maximal lot sizes, and transport duration.Due to the nature of minimal lot size constraints, one might expect they areimplemented using semi-continuous variables.

The SNP optimizer uses the bucket offset to determine the availability ofa 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 modelingmass loss during transportation.

Keeping Track of the Origin of Products

As SNP works quantity driven rather than order driven, order tracing is notsupported by the SNP optimizer. The existing mathematical model simulatesthis tracing by adding an index to each production variable which correspondsto creating a separate product in SAP APO according to its origin (which is,although extremely cumbersome, in principle possible). If production was asingle stage process the requirements could be fulfilled by adding and removingtransportation lanes.

In the process industry example there is also the constraint that there arecustomers or aggregated demands that must be satisfied from the same unit,but which unit is not fixed. This cannot be modeled explicitly in SNP, thereason again being in the fact that SNP optimization looks at quantities intime 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 tablesmentioned in Sect. 8.2.5.3 above. The difference is that the SAP APO businessuser will not look at tables like these, but expects an easy to use and to digestrepresentation. Therefore, the optimization results would be fed into one ormore SNP planning books (cf. Sect. 4.3.1) that show an arbitrary combinationof the output data tables and allows the user to interactively drill up and down,produce interactive graphics, etc. The planning book functionality goes farbeyond 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 datafor the optimizer in a similar way as displayed in Sect. 8.2.5.3. The log filescan be downloaded from the SAP APO application and look very similarto the tab-separated flat files we see in the example here. Therefore, it is afair statement that SAP APO can produce the same kind of output as themathematical model for the process industry here, but can display it in a farmore user-friendly way.

As modes are modeled differently in SAP APO, the production and modechanging plans would need some considerations. Of course the required in-formation is contained in the SAP APO data structures resulting from anoptimization run (keeping in mind the functional SNP limitations mentionedabove in Sect. 8.3.4): the planned order quantities are connected to PPMs andresources, and these are the elements modes are modeled with.

The gap in reporting is origin tracking: as it is – as we mentioned inSect. 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 andother information produced during an SNP optimization run. They are or-dered according to their significance (control parameters of the optimizer,etc.). Additionally, there are logs that detail the master and transaction dataconsidered by the optimization run, output logs detailing the individual tables,trace files, cost logs, solution quality logs, etc. However, there is no automateddiagnosis 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 thinkingis required when dealing with supply chain modeling tools like SAP APO.Given a fixed set of variables and constraints – and keeping the mathematicalconsequences 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 ofsucceeding depends on the detailed features and on the degree to which theycan be implemented using the fixed mathematical model.

In the current case the replacement of the model by the SNP optimizer inSAP APO for simultaneous mid-term and short-term planning turns out to beimpractical because too much reality would be lost. Aspects like straightfor-ward production planning, simple mode changes and campaign planning willbe implemented successfully if the modeler is willing and able to understandthe planning philosophy of SAP APO. On the other hand, features like multi-mode reactors and inventory and keeping track of origin are simply not partof the built-in model formulation and will act as show stoppers in the toolselection phase. Modeling the multi-mode features to the required level of de-tail would require significant changes to the mathematical model in SNP andare not likely to be included with manageable effort from both the customerand SAP sides.

On the other hand, it has to be noted that SAP APO follows a differentplanning philosophy, hierarchical planning, and comparing just one compo-nent of this hierarchical planning with a simultaneous approach might seemunfair. In this concept, mid-term planning (SNP) operates on a lower level ofdetail and integrates into short-term planning (PP/DS) operating on a higherlevel of detail. If it is practical to adopt this layered planning approach for theclient, 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 natureof the model. Some companies therefore decide to adopt the hierarchical plan-ning approach (and accept the different mathematics provided by PP/DS),others use a custom-built optimization application and use the superior evalu-ation capabilities of SAP APO interfacing the two applications (we elaboratemore on this in Chapters 7 and 9). The latter is true especially for companiesthat 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” mathematicalformulation is the arbitrary definition of objective functions, even of those thatdo not make sense in an economics environment and are just used for testingthe model. But we also observe that most of the “non-economic” objectivefunctions can be simulated in the SNP optimizer.

Although it is understandable that there is no detailed public domain doc-umentation of the SNP mathematical optimization model available it makesit very difficult to find out whether SNP maps an existing model well enoughor not. Strong expertise in both domains is necessary for successfully con-ducting an assessment like this. Thus, from the current case we learn that thetime and effort to make the differences between SNP and an existing modelapparent are not at all negligible.

9

Case Studies – Interfacing Tailored Models toSAP APO

We briefly summarize various case studies in which tailored optimization mod-els have been interfaced to SAP APO. In two out of three cases describedin this chapter the SNP optimizer is used and external models complementthe SAP APO TP/VS component, in the third case a tailored optimizationapplication is interfaced to SNP. This chapter illuminates indirectly how op-timization in SAP APO could be improved, indicates alternative tracks andfocusses on problems and issues to be considered when taking such an ap-proach. Section 9.2 and 9.3 have been contributed by Remi 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 SAPAPO has to be built to solve the problem at hand the question is: How do weconstruct the mathematical model corresponding to the problem? This taskis not easy and requires experience. Let us approach this task by the followingstatements:

• 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-Exupery: 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 formulateddescription 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 theproblem or model and what not (example: a production planning systemfor medium- and long-term may neglect those aspects needed in detailedscheduling based on a time resolution of minutes).

• Identification of important model objects (example: products, productionsites, inventories, transport lanes, etc.) and a verbal description of therelations among them.

• Acceptance and user : The model formulation should be appropriate to theproblem, the purpose of the problem and the potential user. Usually, itis problematic and negative for the acceptance of the model if the modelbuilder is not aware of all relevant relations. A vehicle routing system mightexperience some difficulties among the truck drivers if the modeler was toldto minimize the driving costs but each truck driver’s income depends onthe value of the goods delivered. In that case, each driver prefers tourswith only one piece of valuable furniture rather than tours involving manycheap goods.

• In the beginning, a scaled-down version of the model might help to developsome basic understanding and to check whether all features were under-stood properly. This also leads to a good communication base between themodeler and the client.

• Subproblems and substructures in the model might be treated separatelyin the beginning to develop efficient formulations.

• Parts of the real problem may be too difficult. It should be discussedwhether they are really relevant or whether they can be approximated.

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

9.2 The ILOG Cartridge Concept1

In 1999, ILOG introduced the cartridge concept: an external optimizer thatextends an SAP APO system, and launched the Optimization DevelopmentFramework (ODF), a set of tools and a methodology for building cartridges.Since that time more than half a dozen cartridges have been developed withcustomers, partners and ILOG Professional Services. The projects undertakenrange from medium to large scale, being independent of or embedded in majorSAP implementations. Some included graphics (User Interface); all success-fully went live or are close to go-live. The aim of this section is to shareILOG’s experience with companies considering an extension to their existing1 Remi Lequette, ILOG, 9 rue de Verdun, F-94253 Gentilly Cedex, France, Email:

rlequette@ilog.fr, http://www.ilog.com

9.2 The ILOG Cartridges Concept 207

or planned SAP APO system to fit specific business needs. We hope this in-formation will help them to gather input before taking a decision. We willnot discuss the optimization problem in itself. Of course, the feasibility of anoptimizer is a major driver and a showstopper for a project, but this subjectis 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 directattention 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 examplesof cartridge solutions developed by ILOG. The bulk distribution cartridge op-timizes vehicle routing for the distribution of liquefied gases. The load builderoptimizes vehicles loading in the beverage industry. For each project, we de-scribe the supply chain, the reasons to use SAP APO, the motivations for acartridge, the outline of the solution and give project information: skills andtimeline. The fourth part in Sect. 9.2.4 describes the architecture of a car-tridge. This is an IT oriented part covering the integration with SAP APOand the internal architecture of the cartridge. The fifth part in Sect. 9.2.5presents ILOG experience in the methodology for cartridge projects. Thispart covers the skill requirements, the project phase and the major risks. Theproject phases are based on the RUP methodology (Rational Unified Process):It starts with the inception phase where the decision to go for a cartridge istaken, followed by the elaboration phase where specifications are developed.The third phase is the construction phase where the cartridge is built. Thisphase has usually multiple iterations. The last phase is the transition phasecovering go-live and support.

I want to thank all the people involved in the cartridge business, our cus-tomers, our partners (especially at axentiv), the ODF team within ILOG andILOG consultants, with special acknowledgements to Fred Garrett, principalconsultant for ILOG Inc. who contributed the information about the optimizerin the load builder cartridge. In addition to the two case-studies presented inthis chapter, Chap. 7 contains two case-studies including cartridges developedby 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 inthree areas: optimization, visualization, and business rules. The optimizationproducts are ILOG CPLEX for LP (Linear Programming) and MIP (MixedInteger Programming) and ILOG Solver for constraint programming. ILOGSolver has two extensions: ILOG Scheduler for scheduling problems and ILOGDispatcher for routing problems. The visualization products are ILOG Views,a C++ library to build graphical user interfaces (GUIs) with advanced 2Dgraphics such as charts, maps and ILOG JViews products, Java libraries andGUIs 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, execu-tion, and management of business rules in software applications by businessusers using natural language.

ILOG customers can embed the libraries in software applications and usethe GUIs to develop software applications. These customers may be end usersbuilding in-house software applications or ISVs embedding ILOG technologyin commercial software. ILOG provides professional services to assist cus-tomers. 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 inte-grated with SAP APO, it developed ODF to facilitate the development of car-tridges to plug in to SAP APO. ODF is a workbench for building cartridges; itis based on code generation, libraries and template cartridges implementing apredefined architecture. ODF plugs in to the APX (SAP APO OptimizationExtension Workbench) which is a standard component of SAP APO. ODFembeds ILOG experience with an architecture validated by projects.

Cartridge development started in 1999. Cartridges have been developed byILOG Professional Services, customers’ IT departments and software servicecompanies. Typical areas where cartridges have been developed are vehiclerouting, vehicle loading, planning of chemical reactors, supply network plan-ning in the high tech industry, planning of plastic extruders, paper productionplanning 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 additionalconstraints 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, nitro-gen) 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 decideswhen they should be replenished. This is a typical VMI (Vendor Managed In-ventory) process: the suppliers must forecast consumption to decide on thebest delivery time; too late will result in a stock out, too early will result ina bad ratio of transportation cost to quantity of product delivered.

The product is delivered in bulk, which means the quantity can be ad-justed. Typically, the truck will visit a customer site and fill the tank, unlessthere is not enough gas left in the truck in which case the quantity will dependon the current content of the tank.

9.2 The ILOG Cartridges Concept 209

The later a delivery happens the larger is the required replenishment quan-tity. Some customers have high demand and require one or more full truckloadsbut a significant percentage (around 50%) requires partial truckloads. Two tofour tanks may be serviced by the same truck and it may be worth includinga customer in a trip even if the tank level is not close to the reorder point toavoid an isolated trip later.

9.2.2.2 SAP APO Project

The company launched a supply chain initiative and selected SAP APO release2.0. The DP module was selected to forecast customer consumption, SNPplans the production at the plants (air separation units) and dynamicallyassigns 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 dailybasis using the SNP optimizer (based on linear programming).

A substantial economy was expected from this process, as the cost ofproduction is the cost of electricity, which is subject to frequent variationswith short notice. Note also that PP/DS was not deemed necessary as theproduction plan only requires to know the quantity of air to liquefy each dayin each plant. The TP/VS module, new at that time, was selected to plan thedaily dispatch of trucks. There were specific business requirements, however,and SAP made a joint offer with ILOG for a cartridge extending TP/VS witha routing optimizer.

The company did not use the SAP R/3 ERP system, but kept the exist-ing legacy system (developed internally) for business execution. An interfacebetween this system and SAP APO was developed during the project upload-ing the consumption history and product inventories, and downloading theproduction plan and shipments (routes).

9.2.2.3 Cartridge Motivations

The SAP APO database and liveCache can model the truck shipments ef-ficiently but some customer requirements called for a specific development.Some are general requirements for a routing system, but others are specific tobulk distribution:

Geographical display: The user expected a visual display of the routes ona map.

Geographical data: The user expected real distances and driving durationsto be used by the route optimizer. A previous optimizer based on crow-flightdistances gave unsatisfactory results.

Driver and tractor resources: The company has its own fleet of trailersand tractors and the drivers are company employees. TP/VS consider onevehicle resource per shipment (the trailer), but was not able to model tractorsand 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 teamdrivers for some long trips (this is specific to argon gas where there are farfewer plants).

Source and product substitution: SNP does a tactical assignment of sourceto customers based on historical cost, but this assignment may be changedon a daily basis to fine-tune the current routes. The routing can consider analternative source of product for a customer if that improves the dispatchtime. It can also consider product substitution. Liquid oxygen and nitrogenhave two grades: industrial and medical. The difference is an additional qualitycheck, so that medical gas (the higher grade) can be delivered to industrialcustomers. It may make sense to include an industrial customer in a tripthat visits hospitals to reach a full truckload. The source substitution featurerequires the distribution optimizer to know the daily production cost in orderto evaluate the opportunity for substitution and it has to know the SNPproduction plan. The original SNP sourcing is compatible with production,but when the distribution optimizer changes the source, it must include checksavoiding too much product being pulled from a plant.

Outsourcing: The customer tanks can also be serviced from externalsources (competitors); the trailer will then be filled at the competitor siteinstead of an own plant. The optimizer takes this decision based on the costand availability of the product. Some outsourcing contracts are take or payagreements, which means an agreed quantity must be taken during a givenperiod. The optimizer keeps track of this “free” quantity to avoid losing it.Some contracts allow taking extra product at a certain price. Some contractsalso require a minimum daily take.

Bulk delivery: The ability to adjust the quantity delivered depending onthe time of delivery based on the consumption forecast is required. In theproject, this feature was called “variable demand”, to stress that the actualdemand depends on the time of delivery.

Duration of visits: The duration of a delivery is the pumping time depen-dent on the quantity of product delivered, the vehicle, and the tank. For oneproduct (hydrogen) there are two options, either the gas is pumped (this iscalled “bumping”) or the trailer is just swapped with the tank; a swap takesa fixed time. The duration of the visit may be increased when a techniciancomes for tank maintenance which is typically the case for the first visit. Theduration of the initial visits in plants to fill the truck also depends on thetrailer size and the plant. If there is enough time it is possible to plan a refillof the trailer at the end of the day. Then the next day this trailer can skipthe initial plant visit and go directly to the first tank.

Dispatching constraints: There are many other constraints which can makea route invalid if they are not enforced and which have to be considered bythe 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 trail-ers (for example with their names on), but also some trailers cannot reachsome 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 ahill: the trailer must be full when filling the tank; otherwise there will notbe pressure.

• There is a minimal delay between visits to the same customer, to avoidbringing 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 werenot really showstoppers, but when the main obvious gaps were detected andthe decision to build a specific optimizer was taken it made sense to list allbusiness constraints and incorporate them.

9.2.2.4 Solution Outline

Three cartridges were developed by ILOG for this project: the lane cartridge isused to update the distance and driving durations in the SAP APO databaseby a batch job; the GUI cartridge runs on the workstation to control theoptimization process and display the routes on a map; the optimizer cartridgeis 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 andfor graphical display of the routes on a map. From the user perspective, thecartridges are viewed as extensions of SAP APO, they are started from SAPAPO transactions. They do not have persistent data storage; instead they usethe SAP APO database and LiveCache.

The daily planning activities start every night. First, the inventories inplants and customer tanks are uploaded in SAP APO from the execution sys-tem. Then, DP runs and produces a forecast of tank consumptions. This isfollowed by an SNP optimizer run creating a global production and sourcingplan for the whole country. The production plan is then downloaded to theexecution system and the distribution planners (called dispatchers) work dur-ing the day with SAP APO to produce the routing plan for their region; adispatcher administrates a terminal and a set of plants. Note that the cus-tomers are dynamically attached to the region by SNP plant assignments. Aspecial case is the argon gas dispatcher who plans for the whole country usingteam drivers. There are significantly less argon than other plants.

The dispatcher will typically run the cartridge for a one-week horizonstarting the next 12-hour shift and may perform more than one run duringthe day to try different optimization objectives or consider changes in thedata. 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. Duringthe day, in addition to planning with the cartridge for the upcoming shifts,the dispatcher will also spend a significant amount of time reacting to currentunexpected events. He or she will modify the current day’s routes directly inthe execution system.

The Lane Cartridge

The lane cartridge is not an optimizer but follows the same architecture asoptimizer cartridges. Its purpose is to update the SAP APO database withup-to-date distances and driving durations computed with the PC Miler GISsoftware. SAP APO offers a database structure called transportation lanes,which is initialized based on a straight line between geographical coordinatesand a speed depending on the transportation type.

The lane cartridge shows a simple use of the ODF technology interfacingwith SAP APO. It relies on a BAPI (Business API) to update transportationlanes. The lane cartridge is started from an SAP APO transaction (see thearchitecture in Sect. 9.2.4). This transaction is used by system administratorsto update the SAP APO database when new customers are added or when theGIS database is updated with new geographical information. The optimizercartridge itself does not access the GIS software but relies on the data storedin SAP APO. This is faster as PC Miler takes about one second to computea route between two points. While this in itself is very good performance itcannot 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 andruns on the planner workstation. The technology to start a GUI cartridge isexplained in the architecture Sect. 9.2.4. The GUI cartridge reads the currentset of SNP orders and routes in the TP/VS transaction, so there is no needto provide any selection; the cartridge is completely integrated with TP/VSand leverages its data management.

Using the GUI the dispatcher can perform multiple functions. He candisplay 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 daythere are none), and compute KPIs: the global mileage and costs and themileage 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 firmsome routes, change the weights and costs for the optimization objective,choose the first shift and the number of shifts defining the horizon, and finallyrelax some constraints (compatibilities, accessiblities, time windows) or forbidproduct or source substitution. The dispatcher can request optimization; theoptimizer cartridge will then run on a specific computer (server) under thecontrol 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 theroutes in SAP APO, or simply leave the cartridge without saving.

The GUI cartridge was developed by ILOG using the C++ language andthe 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 userrequests optimization and is presented with a choice between the standardoptimizer and the cartridge. Then the cartridge starts and the screen withoptimizer parameters is shown. Figure 9.2 is a screenshot of the map with theshipments built by the cartridge.

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

The Optimizer Cartridge

The optimizer cartridge is started on a specific server by a request from theGUI cartridge. The cartridge reads all data it needs from SAP APO, there isno separate database. The master data are trailers, drivers, tractors, includ-ing availability times and remaining work hours, plant information (pumpingtime, etc.), tank information (size, accessibility, etc.), opening hours for ter-minals, plants, customer facilities, distances and durations, and competitorcontract data for outsourcing. The transaction data are the selected orders(tanks, quantity and source assigned by SNP, the current inventory in plantsand tanks, the forecast consumption in tanks and production in plants and theexisting routes). The optimizer computes an optimal solution by minimizingan 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 isanticipated for a customer tank. There is a cost for non-delivery within theoptimization horizon (a week) and a cost for delivering late, both costs aredependent on a priority assigned to the order; the costs for each prioritylevel (1 to 4) can be modified in the GUI.

• Sourcing cost: This is the cost for taking the product in plants or outsourc-ing 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 ondriving. It could involve waiting for a place to open, filling the trailer or atank, or an overnight stay because the driver has exceeded a driving timeor working time limit. This cost drives the optimizer to make efficient useof trailers, drivers and tractors.

• Payload cost: This is a cost incurred if some product is left in the trailerafter a route when it goes for refill. This cost drives the optimizer to groupdeliveries in full truck loads.

The optimizer was developed by ILOG using the C++ language and the toolsILOG ODF, ILOG Dispatcher, a library for routing optimization (knownas TSP: Traveling Salesman Problem), and ILOG Scheduler, a library forscheduling optimization; scheduling problems are in the driver-tractor con-straints for example. ILOG Dispatcher and Scheduler are both based on ILOGSolver, 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 con-straints, 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 inthe cartridge architecture Sect. 9.2.4 below, we here state specific features inthis project.

The APX in SAP APO was used for integration in the TP/VS interactiveplanning transaction. SAP APO standard BAPIs were used to read TP/VSdata such as SNP orders and shipments, to write TP/VS data such as modify-ing the source and quantity in orders and creating and modifying shipments, toread SNP planning books for inventories, production and consumption (fore-cast), and to read master data: locations (including tank capacity, reorderpoint), transportation lanes, resources (vehicles, time windows). Custom ta-bles were developed in the SAP APO database with the ABAP workbench foradditional master data to model terminal data, drivers, trailers, trailer data,compatibilities (trailers, products, tanks), outsourcing contracts, and productsubstitutions. Note that some “custom” data was stored in SAP APO cus-tom fields and read using standard BAPIs. For example, the plant and tankspumping 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 overallSCM project which additionally included SAP APO DP, SNP customization,the interface with the legacy execution system, training of users (including incartridge use), and cutover and go-live (including the cartridge). The projectwas supported by SAP who specifically enhanced SAP APO with the APX toinsert additional optimizers (in TP/VS) and the BAPIs to exchange data withTP/VS. Note that this project received an APICS Technology award in 2003.See: http://www.sdcexec.com/article arch.asp?article id=4660. More informationabout this project can be found also at: http://www.sap.com/solutions/ business-

suite/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 facto-ries/sources, 5 products, and 19500 lanes. This problems was solved within 15minutes on a high-end PC in 2002. The data exchange with SAP APO takesaround 5 minutes.

216 9 Case Studies - Interfacing Tailored Models to SAP APO

Timeline

September to December 2000 : Specifications of the optimizer, and pilot opti-mizer 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 ofthe cartridges.June to September 2001 : Testing and intermediate deliveries; DP, SNP go-livein July; and cartridge go-live in September.

Staffing

ILOG Professional Services’ involvement in the project was in the areas ofoptimization (two consultants part-time for a total of 12 man-months), thedevelopment of the GUI (one consultant for a total of 2 months), and ar-chitecture and integration (one consultant part-time for a total of 6 months).Additionally, other parties contributed specifically to the cartridge: customiza-tion of SAP APO and ABAP development for custom tables (1 month) anduser 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 largerSCM 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 bev-erage. The supply chain is composed of the following elements: 3 plants, onevery large and two smaller, 11 distribution centers (DCs), 550 distributorswho serve the retailers (stores, bars, and restaurants), and 150 SKUs (prod-ucts with different packaging).

There are two kinds of distribution channels: via the indirect channel, thedistributor receives deliveries from a distribution center, via the direct chan-nel, the distributor receives deliveries directly from a plant. This distinctiondepends on the volume, so a distributor may be direct for some products andindirect for others. Distribution centers receive deliveries from plants. Thereare also export customers who receive deliveries from plants.

Four modes are used for distributing the goods: rail is used between plantsand most distribution centers and also to some large distributors, truck is usedwith 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-productpair the choice of the source (plant or DC) and the mode of transportation isdetermined statically; this assignment is reconsidered on a regular basis (once

9.2 The ILOG Cartridges Concept 217

3 Plants11 Distribution

Centers

550 Distributors Retail

10% T, 90% R

75%Truck, 25%

Rail

100% Truck

“Direct Channel”Plant – Distributor

“Indirect Channel”Plant – DC -Distributor

•“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 shipmentsare tendered to carriers. Figure 9.3 summarizes the supply chain.

The company plans on a weekly basis. Distributors place their orders afew weeks in advance. At the beginning of the week, a replenishment plan forplants and DCs is established for the following weeks, based on the plannedinventories and the demands. Then the bulk production of beverage for thenext week is planned and shortly after that the detailed plan for packaging inthe plant is elaborated.

In the middle of the week transportation is planned first from the plantsto the DCs and direct customers, then from the DCs to customers. The trans-ports are tendered. During the rest of the week, the production and trans-portation plan is modified. At the end of the week the plan is released for nextweek. During the week, the plan established the previous week is executed andmodified to react to unexpected events. Exportation is planned a few weeksin advance, but this does not change the principles.

The major activity in transportation planning is not routing (all vehiclesserve a single destination) but defining the content of the vehicles (trucks,railcars) and their departure times. Many distributors will receive more thanone vehicle during the week. This activity (called load building) was the scopeof the project. Interestingly it seems to be in the same area as the previousproject described in Sect. 9.2.2 (transportation) at first sight, but is in factvery different. In the bulk distribution case the content of the vehicle is clearlydefined (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 toone 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 SAPAPO with the objective to reduce the lead-time between order and deliveryto two weeks and at the same time significantly improve delivery accuracy(distributors order on the internet). Note that a first anticipated consequenceof this project was a diminution of distributor’s safety stock leading to aninitial drop of sales.

All SAP APO modules were involved: DP for forecast, SNP optimizer toplan the network (replenishment) and for deployment, PP/DS for detailedscheduling of packaging, and TLB (Transport Load Builder) and TP/VS forload building. As load luilding was out of the scope of SAP APO for rea-sons described in Sect. 9.2.3.3 (note that the project was started mid-2002 asstated in Sect. 9.2.3.6) and the company expected an integrated solution SAPrecommended ILOG. The company had previously developed a load builderfor their legacy system. Based on this experience and with ILOG expertise, aload 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 trans-portation orders created by deployment and turns them into orders suitablefor transportation planning. It splits bigger orders into loadable quantities orgathers single-product orders into composite multi-item orders. Then TP/VScan 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 re-lease 3.0, seeSect. 9.2.3.6) there was no load-building algorithm or heuristicsin SAP APO enforcing the specific business requirements described below.

Supply availability: loads can leave a plant or a DC if there is enoughsupply 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 thepackaging lines are staged in an area called the “floor” before loading. Thefloor has a limited capacity and when it is saturated, production must beslowed down. Good synchronization between loading and production can lowerthe floor.

Improving line loading: In the plants, the packaging lines deliver palletsdirectly to the warehouse in front of the docks. When a pallet is picked, it canbe moved to the floor (floored) or directly to a vehicle if there is a load for thisproduct scheduled at this time. This is called “line loading” and maximizingline loading is a valuable objective: it decreases the floor and increases theproductivity because two pallet moves are saved (to and from the floor).

Controlling load complexity: the complexity of a load is the number ofdifferent products. Complex loads are more difficult to handle, but more im-portantly 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 loadwill be delayed. Minimizing complexity is especially important for plants.Note that from the distributor viewpoint complex loads are better becausethey prefer to receive a product mix lowering stock-out risk.

Vehicle utilization: At the time of the project TP/VS used simple dimen-sions for vehicle utilization such as weight and volume and did not considerthe additional weight of dunnage. This did not capture the loading of palletsin enough detail as it should be checked independently for length and width;in height, pallets can be stacked and some products allow partial pallets bylayers.

Splitting sales orders: A limitation of TP/VS was that it could not assigna part of a sales order schedule line to a shipment. So if a distributor ordersmore than a truckload of a product (a common situation), TP/VS would notbuild a load unless the sales order item is previously split into schedule lines.This split cannot be made before optimization because splitting in truckloadquantities is not enough. For example, suppose trucks have a capacity of 15pallets and a customer orders 10 pallets of each product A, B, and C. Thebest solution is two loads, for example 10 A+5 C and 10B +5 C. So the itemfor C should be split into two lines of 5 pallets each.

Optimization after tendering: Once the initial loads have been tenderedand accepted by a carrier the load builder may need to be run again. Then itmust work in a more constrained way. It should try to reuse already tenderedloads, changing the content of the load but not the dimensions of the vehicleand the shipping day. The time in the day can be changed because carrierswill send the trailers to a yard at the beginning of the day and pick them withtractors. Figure 9.4 shows the warehouse with the main business terms.

As with the previous project, many other requirements were not show-stoppers, but were enforced for a better business solution after the choice fora custom optimizer had been made. We give two examples:

Portal time computation: the portal time is the duration spent by thevehicle at the dock waiting to be loaded. Portal time is the time between thespot time when the vehicle arrives at the dock and the shipping time when itdeparts. A good evaluation of this time needs to capture the duration betweenlines and docks and floor and docks, the time to load a pallet and fixed timesto set up the truck, close the doors, etc.

Multiple handling resources: TP/VS used one handling resource for a loca-tion. Assigning multiple resources manages the availability of groups of docksseparately, for example the rail docks and the truck docks and uses them withthe appropriate shipments.

9.2.3.4 Solution Outline

The planning activities occur during the week. First, orders from the Webare 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

CoolerFlooring

LineLoading

Lines

DocksLoad from floor

Vehicles= loadable units of product (pallets)

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

(CIF), the SNP optimizer is then run immediately in SAP APO followedby PP/DS which is used to build the production plan based on SNP plannedtransportation (indirect channels) and sales orders (direct channel). Now SNPDeployment builds the exact transportation based on PP/DS production, salesorders and inventories. This brings us to the middle of the week; the loadbuilder is used first in the plants and then in the DCs. The loads built fromthe 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 assplit proposals and a custom development is used to create schedule linesin the SAP R/3 sales orders; then the loads are transformed to SAP APOshipments. The shipments are tendered using a transportation managementsystem (Manugistics) interfaced with SAP APO (the SAP APO database canassign a carrier to a shipment but the SAP APO tendering module was notused). The PP/DS production plan and the load builder plan can be reworkedduring the week. At the end of the week the shipments for the next week arereleased, deliveries and shipments are created in SAP R/3, and these arecommunicated to the warehouse management system.

Two cartridges were developed for this project, a GUI cartridge to displaythe data and pilot the optimizer and an optimizer cartridge to compute theloads.

The Graphical User Interface Cartridge

The GUI cartridge is started from the TP/VS interactive planning transac-tion, 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 anddeployment orders, existing shipments (loads), supplies (inventories, produc-tion 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 ademand already assigned to loads, and the status of demands (fulfilled,late, unfulfilled),

• Display the supplies (inventory, production, inbounds) and the parts of asupply already assigned to loads,

• Display the loads, the demand parts composing the loads, the supply partsattached to the loads, and the status of the load (full vehicle, etc),

• Evaluate the load builder plan, displaying KPIs (number of loads, com-plexity, 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, firm-ing selected loads, changing the objective function weights, and relaxingsome constraints, and

• Run the optimizer and review the results and save the load proposals toSAP APO.

After loading, the GUI performs a supply check, during which it checks ifthe current supplies still fit the loads in time and quantity. The inventories,the production orders and the inbound shipments may have been changedsince the last load builder run. Loads with an incorrect supply situation arehighlighted and the planner can restart the optimizer. Also at any time duringa session, the planner can force the cartridge to refresh the supplies from SAPAPO and perform a supply check. The GUI cartridge was developed by ILOGusing ILOG ODF and ILOG Views.

Optimizer Cartridge

The optimizer cartridge is started on request by the GUI cartridge. Uponstart it receives data from the GUI cartridge: demands, supplies, firmed andtendered loads, and master data. It computes a new set of loads optimizingan objective function. The components of the objective function are complex-ity 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, ILOGCPLEX, an LP and MIP library used to build loads and assign demands andsupplies, ILOG Scheduler, a constraint programming library specialized inscheduling, used to place the loads in time enforcing synchronization withsupply handling resources and business hours. The size of the MILP problemssolved 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 oftwo 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 denotesthe supply used. Several decomposition techniques are used, decomposition bypriority, for example.

9.2.3.5 Integration

The integration of the load builder cartridge with SAP APO was more com-plex than the bulk distribution case described in Sect. 9.2.2 for two mainreasons:

1. The SAP APO database (and the liveCache) could model the loads asshipments 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 ad-ditional procedure to split the schedule lines in the sales orders based onproposals 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 BAPIsfor 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 vehiclesand group of docks. Specific custom tables were also developed with the ABAPworkbench for master data not in SAP R/3 (e.g., duration between lines anddocks, vehicle dimensions).

9.2.3.6 Project Information

The project was developed by ILOG in close cooperation with SAP and thecustomer. The pace was mainly set by the large supply chain project, whichwas delayed to avoid going live during the summer peak season. Since thego-live, the customer reported the lowest historical level of the floor and thepeople in the warehouse reported a noticeable improvement in load execu-tion. The main factor of this success was the involvement of key users duringdevelopment.

Sizing

The Load Builder is used every week by planners for 3 plants and 11 distrib-ution centers, at least twice in each location (before and after tendering). Atypical 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 de-mand table has the dimension product × destination) and is rather sparse.The computations are done in 5 to 15 minutes, actually the bottlenecks ofthe process are reading the supply data from the liveCache and splitting theorders 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 man-agement system), development of ABAP custom tables by the customer,and intermediate deliveries and testing. Because of the delayed supplychain project, the team was not 100% allocated to this project during thisperiod.

• 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/3and SAP APO).

Staffing

ILOG Professional Services involvement in the project was in the areas of op-timization (one consultant full time for a total of 12 man-months), GUI (oneconsultant for a total of 3 months), and architecture and integration (oneconsultant part-time for a total of 10 months). Also, other parties contributedefforts specifically for the cartridge: customization of SAP APO and ABAPdevelopment for custom tables (6 months) and ABAP process for splittingorders in SAP R/3 (12 months). The estimated user involvement in specifica-tions and validation was about 24 months.

9.2.4 The Cartridge Architecture

To reduce risk and speed up project development ODF predefines the ar-chitecture and provides template cartridges. There are two basic cartridgearchitectures depending on the need for a specific graphical user interface.

• The server architecture in which there is only one cartridge which embedsthe optimizer. It runs on a separate computer under the control of SAPAPO.

• 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 and-

started and controlled by the GUI cartridge.

224 9 Case Studies - Interfacing Tailored Models to SAP APO

SAP GatewaySAP Gateway

APOAPO

Front-endWorkstation

OptimizationServer

APOServer

ClientClient

ServerServer

•Direct optimizer control•Result/Parameter exchange•Progress messages•Stopping

SAP GUISAP GUI

•BAPI/RFC

Fig. 9.5. Cartridge external architecture

Note that the client-server architecture is actually an extension of the serverarchitecture: the optimizer cartridge is similar. In the client-server architec-ture, 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; aserver cartridge is identical without the workstation part. Cartridges are sep-arate processes running on Windows computers. This section describes theSAP APO Optimization Extension Workbench (APX) used to integrate thecartridges 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 integrationof 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 inboth 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 externalprocess can be an RFC server (receive calls from SAP) or client (place callsto an SAP system).

9.2 The ILOG Cartridges Concept 225

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

• A Registered server : the external system is running and registered in aSAP gateway under a name. The SAP gateway is a broker program, thereis always a SAP gateway on an SAP instance, and it can also be installedstandalone on a computer. The used gateway and the name of the serverare configured in the RFC destination.

• An Invoked server : the external program is started by the RFC call, thepath of the program to start is configured in the RFC destination. Thereare three kinds of invocation depending on the computer where the serveris started. In Front-end workstation invocation, the server is started bythe SAP GUI. In SAP server invocation the server is started on the hostrunning the SAP instance. In Explicit host invocation the server is startedon an explicit computer (IP name or address) through a gateway installedon this computer.

An optimizer cartridge (server) uses explicit host invocation, this is also thetechnique 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 theoptimizer on the front-end workstation; this allows testing the optimizer beforedeployment to the server computer.

Once the cartridge process starts, it must use the RFC SDK to establishitself as a server and answer the RFC calls from SAP. The ODF templatecartridge performs this task automatically. The RFC protocol described aboveis strictly sufficient to integrate an external program with ABAP developmenton 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 andallows integration in the standard modules (PP/DS and TP/VS).

APX is based on a customizing activity (Maintain Optimization ExtensionWorkbench) where the extensions can be named; the following information isattached 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 inter-active planning session of PP/DS or TP/VS will give the choice of startingthe external optimizer instead of the standard optimizer. It is also possible tomaintain a restriction of users and custom configuration parameters that willbe sent to the external optimizer. APX also provides some predefined reportsand RFC modules: The /SAPAPO/APX OPTSTART report can be used tostart an external optimizer outside the interactive planning transactions. Thisreport offers selection of PP/DS and TP/VS data and is useful to define vari-ants and schedule optimization jobs. The /SAPAPO/APX OPTSTART func-tion 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-enabledfunction module used by the client cartridge to request SAP APO to startthe server cartridge. APX also predefines the RFC function module used tostart the external optimizer and pass some useful information with the activa-tion call: the name of the extension, the SAP module, the mode (interactive,batch), the user name, the Logical System, and the custom parameters regis-tered 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 SAPsession is blocked, but another session can be opened.

3. The cartridge GUI downloads data from SAP using BAPIs (see the nextSect. 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 gate-

way 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 ad-ditional developments. An important feature is also the creation of logs andsnapshot files of the data. These snapshot files can be used to repeat the op-timization offline with a standalone version of the cartridge. This is useful fordebugging, tuning, and regression testing.

9.2 The ILOG Cartridges Concept 227

APOAPODataDataAccessAccessEngineEngineControlControl

Control FlowUser Interface

Connection to ILOG Product Suite

APO Data Model

APO Protocols(BAPI/RFC)

Scripts to Load/Save

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 transactiondata. The main reason is that SAP APO was designed to work with any exe-cution system, not only SAP R/3, and the BAPIs have been provided for thisintegration. The BAPIs are documented in the BAPI browser (bapi transac-tion) 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 lo-cation, transportation lane, product, resource, and PPM (production processmodel) 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 SAPAPO (as it is often the case with master data). In this case, some additionaltables must be developed with additional RFC-enabled module functions toexchange them with the cartridge. ODF provides tools to extract the RFCdefinition and easily build the data model and the code to exchange the datawith SAP APO.

9.2.4.3 Internal Architecture

ODF also provides a predefined division of the cartridge into internal modulesas shown in Fig. 9.6. The cartridge modules are: The control module which con-tains the scripts to control the execution of cartridge functions. These scriptsare 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 in-terface to run the commands. The data access module contains the functionsto exchange data in relational format with SAP APO (through RFC), withdatabases (for access to legacy data or other data sources), and with flat files(for snapshot files). The data in relational format are translated in memoryto an object-oriented model. ODF provides code generation tools that auto-matically build the relational object data mapping. An object-oriented modelis easier and faster to access for data processing. The object-oriented modelinside the data access module is called the apo model because it is close tothe data model of SAP APO. The engine module is used for either the opti-mizer or the GUI. It also contains an object-oriented data model called theapplication model.

This architectural model implements the business concepts of the car-tridge and is used by the GUI and optimization developers. One of the maintasks in integration is to implement the transformation between the two mod-els, apo and application. This may range from simple computations as dateconversions, unit transformations, filtering, or aggregation, to more elaboratepreprocessing. A common example is to compute the projected inventories atthe beginning of the planning horizon, starting from the current stock andadding or removing all goods movements.

9.2.5 About Cartridge Projects

This section presents the ODF methodology that ILOG has built up fromcartridge projects. We first present the typical team involved in a cartridgedevelopment along with the required skills. Then we describe the main phasesof a project; ILOG bases the projects on the RUP (Rational Unified Process)methodology defining 4 phases inception ( the opportunity and feasibility ofthe project is assessed), elaboration (detailed specification and an optionalprototype are developed), construction ( the cartridges are developed and de-livered), and transition ( the cartridge goes live). We will end by presentingthe 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 optimizationlibraries (ILOG tools). There are two main tasks, which can be separated incase more than one consultant is involved or the first task can be also coveredby the project manager. This first task is to elaborate the functional speci-fications 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 ob-jectives presented by the planners and modeling skills to translate the businessobjectives into an optimization model. The ability to explain to the plannerwhat 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 goodsoftware engineering skills and knowledge of the optimization libraries.

Graphics Consultant

If there is a GUI cartridge a consultant will develop the graphical user inter-face, the main work being in charts (Gantt, etc.) and other specific graphics.There are similar roles as in optimization: elaborating specifications and devel-oping. Specific graphical knowledge is usually less critical than optimizationknowledge: the specification task can be covered by the project manager orthe integration consultant, and the development can be performed by theintegration consultant.

Integration Consultant

This consultant will be in charge of the architecture of the cartridge and theIT integration with SAP APO. He or she must have a good understanding ofODF and the SAP APO system from an IT perspective. A good understandingof the business problem, the SAP APO data model and modules, and the datarequired by the optimizer is essential. One task is to elaborate specificationsfor the data modeling in SAP APO and the method to access the data from thecartridge and for the transformation of the data to the application model usedby the optimizer and the GUI. Another task is to construct the cartridges,develop the data access and control modules, integrate the engine developedby the other consultants, deliver the final cartridges, and integrate them withSAP APO.

ABAP Development

Depending on the project, some ABAP developments will be required to de-velop transactions to manage and run the cartridge and to add custom tablesand function modules supporting the cartridge. These tasks are not performedand 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 largerSAP 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 successof the project. Business users, usually planners, are involved to develop thespecifications, validate the deliveries, and gain ownership of the cartridge.They will champion the use of the cartridge and act as “super users” after go-live. IT specialists are involved in the design and validation of the integrationand architecture of the cartridge. They will monitor the future administrationof the cartridge and SAP APO. The part-time, but continual, involvement ofa business user and an IT specialist in all phases of the project is a criticalfactor.

9.2.5.2 The Inception Phase

The project will start with an inception (also called assessment) phase. Thepurpose of this phase is to assess the opportunity for a cartridge: the businesscase for the optimizer and the reasons to build an extension to SAP APO(see below for some typical reasons). This phase also assesses the feasibilityof the cartridge: detect if there are showstoppers in the optimization and theintegration.

The outcome is a statement of work: high-level specifications of the projectwith an estimation of the timeline and workloads. The statement of workdefines the different project phases, especially the successive iterations in theconstruction phase. For each phase, the functional content and the deliverablesare listed. The statement of work lists the skills required for the project andthe amount of days in each phase. The statement of work states the additionaldependencies to support the cartridge project like ABAP developments, datadevelopments, access to legacy data.

This phase usually lasts 1 to 3 weeks and involves an optimization con-sultant and an integration consultant from the cartridge supplier side anda business user and an IT specialist from the customer side. The activitiesfor gathering information during this phase may include meetings and inter-views, plant visits, and prototyping an optimizer with ILOG products (suchas OPL, an Optimization Programming Language for mathematical program-ming). Note that it is important to clearly describe the business objectives,the overall business process upstream and downstram of the optimizationproblem, and the business problem requiring optimization.

The reason to develop an optimizer should be clearly stated in businessterms. Return on investment may be the first indicator to come to mind, butthis is actually not easy to assess because the business process will change andthe real costs are not known. Productivity of planning is often not seen as thereal driver for the tool. In some cases (as for the load builder) the planningprocess is too complex to be performed manually, more usually however itis performed by very skilled people who are difficult to train. Automaticallybuilding 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 areplacement for planners – this is not only a psychological, but also a businessmistake as planning is fundamentally a human decision. A key point is reachedwhen planners see the tool as an enabler to plan better and liberate them frombookkeeping tasks. It should be understood that an optimizer only optimizesa weighted trade-off between competing business objectives. We were veryhappy in our projects when the planners developed their own recipes to usethe tool. For example, a fundamental trade-off is between production costs(setups, resource utilization) and customer service (on-time delivery). Theuser can perform multiple runs of the optimizer, setting extreme weights toexplore the sides of the trade-off. The user of the load builder for examplefirst runs with priority on customer service, and then she firms the shipmentsfor the priority customers and performs a second run with an emphasis onresource utilization. Exploring these trade-offs manually would have been im-possible. Actually, in that case, the opportunity for an optimizer has alreadybeen 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 stan-dard SAP APO. This evaluation is extremely important because there is costin an external optimizer, which should be compared with the cost of usingSAP APO with minor gaps and/or some ABAP or other developments. First,it should be understood that differences often come from the fact that SAPAPO is generic software, not specific to an industry, and covers best the moregeneric functions where industries look most alike. Gaps are more often foundin operational planning (detailed scheduling of production, vehicle routing)than in tactical planning (DP, SNP). Approximations in tactical planning canbe acceptable, but in operational planning missing a constraint or approxi-mating will lead to daily frustration because the plan is not executable. Evenif there is a business requirement not explicitly covered with the SAP APOoptimizer, SAP APO is an extraordinary integration platform for the externaloptimizer. It provides the modeling of data, and the integration with the ex-ecution system (SAP R/3) and with the upstream or downstream processes.SAP APO, as all SAP systems, is also very good for extensions using theABAP workbench; this is widely used to support cartridges for integration.However, ABAP was not designed for advanced 2D graphics (charts) andcomplex optimization algorithms usually requiring object oriented program-ming in C++. The standard SAP APO optimizers, for example, use the samearchitecture as the cartridge: integration in ABAP and the algorithm in a sep-arate C++ process. The cost of integrating a custom optimizer is drasticallyreduced with SAP APO. This is the reason to see cartridges as SAP APOextensions instead of standalone software. In both examples, we saw how thecartridges integrate nicely with the results of SAP APO upstream modules(SNP, PP/DS), leverage SAP APO for data storage and selection, and relyon 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 thisboils down to missing master data or attributes in existing master data. Inalmost all projects, there will be a need to add master data. The good newsis that it is easy to add tables with the ABAP workbench, or simply to addcustom fields. Scope of data: very often, the optimizer will need to look atdata not in the usual scope. Both cartridges we presented plan transportationbut need production data. The standard TP/VS optimizer does not look atproduction data, it assumes product is available. Here we can also appreciatethat SAP APO provides access to all planning information (forecast, stocks,production, and transportation) in one unified database through standardBAPIs. Otherwise, the integration would have been much more difficult in-volving many systems. A great achievement in all our cartridge projects wasto use SAP APO as the only integration point. It is important in the inceptionphase to clearly detect clearly these data requirements. For this purpose, it isimportant to write down the data model required by the business problem andto map it to SAP APO. If the data are exactly the data used by a standardSAP 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 dataas the standard one; SAP will continue to improve the standard optimizers.

Two important decisions examined in the inception phase are the need fora GUI cartridge and the need to access legacy data.

GUI Cartridge

The main driver for a GUI cartridge is the need for advanced graphics, geo-graphical maps, 2D layouts (symbols), charts (Gantt, histograms, bar charts,etc.), or specific representations (e.g., develop a cartridge for paper trimmingwhere the cutting patterns are displayed). It should be decided if the GUIis only for displaying, evaluating the plan, and preparing the run (excluding,firming, relaxing) or if the user wants also to modify the plan manually. Thecosts are very different. The first reflex of the planners is to think they willneed manual planning. Actually in many cartridges we proposed to delay thisfunction to a later iteration and it was not developed because the optimizergave a good solution and changing the result in SAP APO or SAP R/3 wassufficient. If the interface contains only tables, an ABAP development shouldbe 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 decideif data will be available in the SAP APO project on time, if an interfacewith existing legacy data should be developed or if datasets should be builtmanually.

9.2 The ILOG Cartridges Concept 233

9.2.5.3 Elaboration

The purpose of this phase is to develop the detailed specifications. Optimiza-tion specifications contain the business model, the objective function, the con-straints and the high-level description of the optimization techniques (math-ematical model, algorithms). They also state the expected performance. GUIspecifications contain the description of screens that should be developed andthe control flow. Many tools (like ILOG Views Studio) can be used to producescreens. IT specifications describe the integration of the cartridge in term ofdata mapping reviewing the optimization business model and explaining howit is mapped within SAP APO and which method will be used to access it. Thedata mapping lists additional data required in SAP APO (custom fields, cus-tom tables). The cartridge architecture describes how the template cartridgearchitecture will be instantiated in the projects and how the cartridge will beintegrated in SAP APO. If legacy data will be used, the specifications describethe format and access to these data. Note that the ODF template architec-ture provides a placeholder for a legacy data model. But of course additionaldevelopment is required to map legacy data. Validation describes how thecartridge will be validated: optimization is usually validated with simple datasets showing specific features and global datasets showing real optimizationproblems; GUI and integration are validated by developing business scenariosand comparing the data in SAP APO and in the cartridge.

This phase usually lasts 1 to 2 months and involves an optimization con-sultant, an integration consultant, a business user to validate the optimizationand GUI specifications, and an IT specialist to validate the integration spec-ifications

9.2.5.4 Construction

During the construction phase, the cartridges are developed and the deliver-ables are no longer documents but software components. ILOG believes in iter-ative development with intermediate delivery of working cartridges. Iterationsare defined during inception and elaboration. Iteration covers a well-definedsubset of functionalities. A working version of the cartridges is delivered, usu-ally before the end of the iteration to get user feedback. ODF allows the build-ing of standalone versions of the cartridges using flat files. They can be usedbefore completion of the integration and construction of the SAP APO sys-tems. This is also very important for using well-defined datasets. It is actuallydifficult to always work directly with the SAP APO system for the followingreasons: the system may not be ready or accessible, it may contain bad data(especially in development systems) and data created for other purposes thanoptimization, and finally the content of the system may change over time andit is not easy to keep a stable set of data. The standalone cartridge also con-tains an automatic data browser to explore the data. This is a very valuabledevelopment 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 datasetsand write test scripts. Using data files and the standalone cartridge decouplesthe integration and optimization developments. The integration consultantcan access the SAP APO system to download data and create files for theoptimization consultants who works only with the standalone cartridge. Thisdecoupling dramatically increases the productivity of the developers.

9.2.5.5 Transition

The transition is the last phase. The project documentation is finalized andcontains updated specifications, the IT installation manual and user guide,and user documentation for the GUI and the optimizer. This phase is syn-chronized with the last SAP project phases, integration tests, go-live, and postgo-live support. In this phase, the key point is fast analysis of issues and quicksupport. Experience taught us that even with careful specifications, training,and planning, some issues can emerge: errors in data (especially in master dataconstruction) and incorrect behavior of the cartridge (bugs, bad interpreta-tion of the specification, missing specification). The most useful ODF toolsin this phase are the logs generated by the cartridge and the automaticallygenerated snapshot data files that can be used in the standalone cartridgewith the data browser.

9.2.5.6 Risks

We do not try to list all potential risks in a software projects but concentrateon 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 willof course wish to get value for the money and match its business needs exactlyas opposed to an off-the-shelf solution where some trade-offs are accepted. Thisis actually difficult for the following reasons: Planners “know” their businessvery well and know what a “good” plan is. However, it is very difficult towrite this down as specifications. Planners are not optimization specialists,and optimization consultants are not business specialists, they must reacha mutual understanding. Planners keep on asking for change and improve-ments as they begin to use the cartridge (this is often called “feature creep”).Planners would like a “magic wand” to incorporate requirements that are ex-tremely expensive or impossible to put in the scope. A typical magic wand isonline planning. When the plan has been released for execution it is usuallynot executed as planned for many reasons (machine breaks, supplies are de-livered late, demand is changed, etc). Planning is the easy part of a planner’slife, 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. Un-fortunately, this is usually a very different and harder optimization problem interm of constraints. For example, many component supplies are derived fromthe original plan (by MRP for example) and in replanning supply availabilitybecomes a very strong constraint. In our load building example tendering theshipments creates an additional constraint for subsequent runs, we did noteven consider replanning during the execution week. The first approach tothis problem is to try to improve the process to shorten the release horizonand increase the planning frequency if possible. If you plan for the next weekand release one week for execution and something goes wrong on Monday theplan will be warped and manual adjustment will be necessary in the plantduring the whole week. If you release two days you will manually adjust twodays in advance and have the opportunity to run the planning again startingthe horizon on the third day. The optimizer will consider the new situation atthe beginning of the third day and build a new plan.

It is extremely important in the project to manage the planners’ expecta-tions, ignoring them will create frustration, incorporating too much will createdelay and excessive costs. The preventive actions against this risk are simple.Good communication is required between the consultants and the plannerswhen writing specifications and during the whole project. Buy-in of a plan-ner in the project is very important. He or she must be an integral part ofthe project and one of its owners. Requirements should be sorted by priority(critical, useful, nice-to-have) and importance and assigned to successive it-erations. Pushing a requirement to a later iteration is a nice way to have anopportunity to reexamine it when more understanding of the project is built.Iterations and intermediate deliveries are key to get early feedback. Put achange request mechanism in place at a well-chosen time during the construc-tion phase. The main idea is to put some “sand” forcing users to question thevalue of the changes. Allow some budget for tuning and changes at the end ofthe project, or expect some overrun in costs. It makes more sense to developa limited core set of features first and add to it later than to develop featuresthat are never used. Some business features are never used because the costof maintaining accurate data offsets the benefit. In the bulk routing cartridgewe added a feature to incorporate weather conditions on driving time, but itis seldom used as the durations are not that precise anyway (due to trafficor other factors) and weather conditions must be maintained manually in themaster data. Note that from the customer perspective it is less expensive toincorporate a useless requirement in the original specification than to pay achange request for a forgotten important requirement. This leads to an “if indoubt, let’s do it” mentality. A better approach is “if in doubt lets’leave it toa later iteration”.

Data Availability

Optimization is very sensitive to data. Integration is simpler to test (small andnot 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 needsto be tuned on the real data and trying to cover all the possible configura-tions makes absolutely no sense if they do not correspond to a real businessscenario. 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 goodresults with his data. The specifications may be imprecise and may not cap-ture 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 duringspecifications because they were “obvious”.

There are not many ways to address this risk. The project manager shouldinsist on the need for real data during the inception; incorporate it in theplanning and the dependencies. The project should consider access to legacydata in existing systems or define an easy data format (Microsoft R© Excel R©,Access database) to be used by the planner to create datasets manually. Notethat ODF can very easily access Excel files or Access databases. When thedatasets are created manually usually they will exercise a specific feature, thisis of course very useful, but some datasets should be “real” too. This means henumber of objects must be comparable with reality. A common mistake is tobuild datasets with no released plan, as if the plant was just freshly built andthe first customer orders are received. In reality, the plan from yesterday willbe currently under execution so the resource will be busy with firmed ordersand inventories must be projected. A way to reach this state is to create afirst 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 andthe integration may be impacted seriously when the size of the data increases.This risk should be addressed with common sense; during inception, gatherinformation on the expected sizes of problems. Find formulae to extrapolatethe performance measured on the first tests. Build large-scale datasets (couldbe by simple repetition). Get real data as early as possible!

Project Dependencies

Dependencies create the risk of delay in any project. When dependencies arelate, the developers are not 100% efficient and the duration of the tasks will belonger than the planned effort. A typical issue is the availability of customeremployees like planners and IT specialists. These people are usually extremelybusy and not required 100% on the project, but they are needed punctuallyto answer a clarification question, review a document or give feedback on adelivery. Other potential issues are the availability of data (once again!) andthe coordination of cartridge development and ABAP development in the SAPAPO system.

9.3 Production and Sales Planning in the Chemical Industry 237

9.3 Production and Sales Planning in the ChemicalIndustry2

9.3.1 Situation

The BASELL group of companies is the world’s largest supplier of polypropy-lene and a leading supplier of polyethylene. Both are plastic materials with alarge variety of applications in many industries: car, film, furniture, building,and others.

BASELL Europe has about 20 production plants in central and southernEurope producing about 1200 different finished products. Most products cantechnically be produced at more than one plant. Product produced at theseplants serves the European market and, in some cases, markets worldwide.Fig. 9.7 shows the structure of BASELL’s supply chain, spanning procuringraw material, the chemical production processes, and outbound logistics andsales processes. Apart from the material flows, it lists the business constraintsand gives an idea of the supply chain complexity in terms of number of loca-tions, products, and deliveries.

BASELL uses a centralized SAP R/3 system to represent its businessworldwide (including BASELL Asia Pacific and BASELL USA). Demandplanning is done in SAP APO based on historical data and then updatedwith current market information. Every month, a rolling forecast is generatedthat 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 supplyplan 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 onthe supply chain:

• Production volumes must not exceed given capacities on production linesat plants.

• Current stock volumes have to be taken into account, as well as stockrequirements 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.2 Axel Hecker, Mathesis GmbH, Friedrichsplatz 11, D-68165 Mannheim, Germany,

e-mail: axel.hecker@mathesis.de, http://www.mathesis.de

238 9 Case Studies - Interfacing Tailored Models to SAP APO

BASELL Supply Chain

Procurement

Monomer Purchase (Propylene, Ethylene)

Other Raw Material Purchase

Production Powder (“Polymerization”)

Production Finished Products(“Granulation”)

Purchase PricesRestrictions on Availability

Production & Supply Logistics & Sale

Production Line CapacitiesMinimal Runs, Fixed Lot SizesEnergy Costs

Inventory Requirements, Costs & CapacitiesTransport CostsCustomer Demands & Prices

~ 20 Production Plants in Europe

~ 1200 different products produced

Packaging & Logistics (internal/externalInventory, Transport)

Sale to Customers in Europe & Overseas

~ 10 external Inventories in Europe

~ 5000 Deliveries to Customers in Europe & Overseas each month

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 describedabove. 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 prob-

lem that can be fed with current data and executed with solver softwareXpress-MP by Dash Optimization, the model is written in Xpress-Mosel)

• Throughout reporting

For the reasons discussed below, the Supply Network Planning (SNP) func-tionality built into SAP APO is not used. Besides interfacing, all functionalityis implemented outside of SAP. This is why the solution provided can be con-ceived as a “plug-in” optimizer for SAP APO.

The first implementation goes back to the year 1997; the system has beenenlarged and reworked considerably in 1999/2000. From the month of intro-duction in 1997, the system has been live and running to date, with minor3 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:anna.schreieck@basf-ag.de

9.3 Production and Sales Planning in the Chemical Industry 239

BASELL Planning Process

Sales Forecast(SAP APO)

“What Sales Department would like to sell”

Historical Data

Current Market Info

Sales Plan(SAP APO)

“What is actually available for sale to whom”

Optimizationby means of

MILP technology

Additional Input

Result OK?yes

Set additionalconstraints in orderto avoid problems

identified

no

inside

outsideSAP

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

adjustments that are continuously made. Currently (2005), SAP/R3 is usedin release 4.5B and SAP APO is used in release 3.0A.

The following subsections describe the items listed above in detail. As areference, Fig. 9.8 sketches the planning process inside and outside of SAPAPO.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 down-loaded from SAP APO and SAP R/3:

• Rolling sales forecast, composed in SAP APO from historical data andthen updated with current market information

• Current information on production: costs, capacities, restrictions, availableproduction lines, bill of materials, etc.

• Current stock quantities• Transport costs

Due to tight time constraints, users of the systems always wanted to be able todetermine themselves the exact point in time when these downloads should beexecuted; consequently, no fully automated procedure has been implementedfor 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, SupplyChain 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 60minutes 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 anessential part of the system. In case of problems, data may be corrected oreliminated at once. The importance of this “cleansing” process can hardly beoverestimated, because experience shows that data provided by many differentpeople in many different parts of the company will never be exactly clean inthe sense of some “dumb” optimization system that does not have a conceptof reality. These are the most important checks that are made before eachoptimization 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 aconsiderable amount of time (like several hours).

It should be noted, however, that time invested at this point at the sametime provides very good hints on how data quality might generally be im-proved. Several years ago, when SAP R/3 and the optimization system hap-pened to be introduced roughly in the same period of time, the checklistsgenerated by the procedures described above turned out to become one of themost useful sources for data quality control.

9.3.3.3 User Input

Sometimes, last minute information has to be introduced at a point in timewhen the process cannot restart from the beginning. More important, not alldata needed for optimization is available in the existing SAP environment.Consequently, a user interface has been created that allows modifying allcurrent data at will and supplementing data that is not available elsewhere.

Due to business process and system considerations, the implementationteam at BASELL decided to administer the following data manually in theoptimization application:

• Planned shutdown times on production lines and reservation of quantityfor 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 ofthe time data from previous optimization runs can be used with modifications.The system provides the possibility to generate new versions of the currentdata that can then be modified where needed.

9.3.3.4 Optimization

Optimization is set up to look for a solution that maximizes profit underobservation of all restrictions defined.

Optimization has proven to provide an excellent mechanism to decide onconcurrency situations, because it is able to take all side effects into accountsimultaneously. When complications accumulate, they could hardly be pur-sued by human planners. Running optimization is an automated process theuser 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 oftime needed (about 1 or 2 minutes), while the middle step might exhibit quitedifferent computing times, depending on the level of complication present inthe current problem.

Typical computing times for the middle step are 10 to 20 minutes; as soonas a feasible integer solution is found, it is up to the user to decide if he or shewants to stop the process or look for another, better solution. Users have beentold to watch the gap between the linear solution (relaxation) that does nottake 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 thefirst time then the created results will typically not be 100% feasible withreality as a result of facts unknown to the optimizer. For example, the opti-mizer might decide on a certain product mix on a certain production line in acertain month that, out of reasons too complicated for implementation in themodel itself, is difficult to achieve in reality. Consequently, experienced userslook through the results, and in case such an infeasibility occurs, correct themby setting additional constraints.

In a “trial and error” manner, additional optimization runs are executedand checked again until a result is achieved that everybody involved is happywith. This procedure might be conceived as being “primitive”, but techni-cal 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 optimumsolution”. But in reality, this is not true because reality is always much morecomplex than its representation in the model. Users compensate this bias byusing optimization as a tool that generates proposals they can approve orreject. And this is exactly what the seemingly primitive procedure describedabove provides.

Finally, results go through a checking process that takes the sequencingaspects of production into account. While the optimizer only focuses on quan-tities per month, according to predefined sequencing aspects, a product mightbe produced “early” or “late” in some month, which is not visible to the opti-mizer (at least for now; further refinements of the optimization process, espe-cially refinements that take into account product sequencing, are projected).Consequently, users have to shift some production quantities between plantsor production lines manually in order to provide for feasible sequencing. Thiscorrection 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 differentaggregation 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 thebuilt-in pivot functionality, allows fast access to all aspects of the result forpeople directly involved in the process.

Finally, the sales plan is uploaded back to SAP APO and represents thecurrent planning state – until it is replaced by the outcome of the next plan-ning round one month later.

9.3.4 Discussion

Some questions might come to mind, concerning the procedures describedabove:

1. These procedures combine the application of computing power with stepsexecuted by human beings in a more manual way – with well-known nega-tive side effects: sometimes arbitrary decisions, “trial and error” methods,sometimes complicated communication, etc. Wouldn’t it be possible toproceed in a more elegant, more rational, more automated and integratedway?

2. Why not use the Supply Network Planning (SNP) functionality built intoSAP 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 involve-ment of human beings” is always better. Experience shows that this might betrue sometimes, but not in complex planning situations like the one described.

One reason is that automated processes can hardly be communicated assuch. An automated process is typically conceived as a black-box that cannotbe understood (and thus communicated) but only trusted in. And optimizersshould 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 suchthing as the optimum (or in very rare cases only). Optimizers deal with amodel of reality, not with reality itself. Although the model might be a verygood representation of reality insofar as it takes into account everything (ormost of the things) that can be expressed in numbers, in many cases, thesenumbers only represent abbreviations that stand for something that is morecomplex – maybe too complex to be expressed solely in numbers at all.

At this point, specific strengths of human beings come into place. Humanbeings might be weak when they have to deal with numbers only, at leastwith more than a handful of numbers at the same time – this is what they usecomputers and optimizers for. But they can be very strong in dealing withcomplex situations. There is nothing that can replace human intuition and itscritical ability to discriminate the relevant from the irrelevant, reality fromconception, and right from wrong.

The procedures described above are all designed such that, ideally, every-body 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 beingachieved regularly; under the pressures of everyday life, people tend to sim-plify the process and act as if optimization would deliver solutions that do nothave to be critically reflected any more. Nevertheless it should be noted thatmistakes made during planning are more often due to too much automationthan too little. The ideal is not a fully automated, but a fully communicatedplanning 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 stateof a given enterprise with all objects and numbers that are potentially rele-vant – on the level of precision needed. Advanced planning systems like SAPAPO provide additional functionality to determine specific business targetsthat drive current actions and decisions. Mathematical optimization providespowerful mechanisms to support this process.

Much of the power of SAP R/3 is based on the assumption (proved tobe 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 APOwas supposed to repeat this success in the planning dimension.

However, this can only be achieved to a certain extent. While ERP sys-tems represent “facts” in terms of bookings, the planning dimension deals withobjects and numbers that are not yet facts; consequently, driving factors forfuture developments have to be taken into account. And these driving factorsmay be very different, depending on the nature of the specific business in ques-tion. For example, factors that drive the production and logistics processes ina chemical company are very different from those that drive similar processesin the automobile industry, and so forth in most other businesses.

Models set up for mathematical optimization try to take into accountsuch driving factors in order to be able to predict the outcome of futuredevelopments more precisely. For example, future business actions must alwaysobserve constraints on capacities because such limitations cannot be changedovernight.

Typically, some of these driving factors are critical for the supply chain asa whole. Due to their tight connection with the specific business, such drivingfactors are very hard to impossible to model in standardized systems like SAPAPO. Consequently, although such systems seem to be a logical extension toERP, the scope of possible actions, relations and constraints they supporttends 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 aspossible to take into account the specific factors that drive a certain business.For example, the next development step of the optimizer described above willtry to take into account rules and constraints on smooth production sequenc-ing – a feature that is regarded as essential in BASELL and similar processindustries. 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 sup-ported at the time of introduction):

• Profit maximization: SNP supports cost minimization. In case the opti-mization objective profit maximization is set in the optimization profile,it is possible to express differentiations in sales prices in terms of penaltiesthat can be defined in SNP in case some sale cannot be done, becausesuch 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 toconceive in day-to-day business and not covering the whole phenomenon,because it would mix two aspects that should be kept separated: prof-itability and the business decision on making a sale or not.

• Definition of stock in sales days: The model implemented supports thedefinition 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 ofthe previous month, in order to cope with situations of “late” productionin that very month. Due to the high relevance of production sequencingat BASELL, this is an essential feature of the model implemented. Similarfeatures available in SNP at the time of implementation did not meetBASELL’s requirements.

• Some high quality products can only be produced when certain other prod-ucts are produced, as well. The model implemented allows to define suchconstraints in terms of precise volume relations that have to be observed.No such feature was visible in SNP at the time of implementation, todayit might make sense to revisit that requirement and evaluate it against theco-production functionality in SNP.

Besides the first point mentioned (profit maximization), these items may beregarded as details that do not exist outside BASELL. There is a general pointto make here, though: experience shows that most real life situations have atleast 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 toprovide a tool that can create a detailed production schedule for 30 days onsome production lines; it not only takes into account demand on a day-to-daybasis, 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 thatdetermines how much of each product should be produced on each productionline at each plant in each month. Although this procedure makes sure thatthe supply plan corresponds to the current demand situation, currently thereis no way to guarantee in an automated way that the series of products tobe produced on a certain production line is technically feasible and what theoptimal sequence of products would be.

Instead, technical feasibility and the determination of the actual sequenceproduction should pursue are controlled manually by production planners whoare 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 sched-ule. Such events may be a changed demand situation that is no more compat-ible with the current state of planning or breakdowns of production lines dueto 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 thecurrent production schedule, this tool should not only run once per month, butpotentially once or several times per day. Response times of the tool shouldbe short, because under the pressures of everyday life and, especially, eventslike the ones mentioned, answers are useless when they are not available atonce.

9.3.5.3 Solution

The solution currently (2005) under construction follows a development pathdifferent from the system described above. Its characteristics are:

• Provide a general framework for real life problems to be optimized. Thisgeneral framework is called TriMatrix R©5; based on a generic data conceptand equipped as a full-blown stand-alone optimization system, its devel-opers claim that any real life problem which may be optimized by usingMILP technology can be represented and solved by using this framework –be it supply chain problems, sequencing problems, timetable problems orwhatever else one might think of. Even the famous “Rubic’s Cube” couldbe represented and solved by using the patterns provided, without anychange that would have to be made to the underlying framework itself.

• In order to provide the necessary calculation speed, a preprocessing isimplemented that focuses the optimizer such that only relevant alterna-tives are evaluated against each other. Normally, optimizers tend to searchthrough the space of possible solutions without much guidance, possiblywasting time with testing solutions that would not be feasible anyway.In order to avoid this, before optimization starts, the timetable of dailydemands is checked against alternatives that conform to the rules and re-strictions of proper product sequencing; only those alternatives are madevisible to the optimizer that pass the feasibility test. Consequently, theoptimizer only has to look through a relatively limited number of possiblesolutions, and therefore processes very fast.

5 TriMatrix has been developed by the company MATHESIS GmbH. Seewww.mathesis.de or write to info@mathesis.de 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 produc-ing and selling company can represent cars as “products” and the parts carsare made of as a “BOM” (bill of materials); in order to produce cars, workersand machinery are needed, which can be represented as “resources”, and soon. This kind of abstraction makes sure that companies producing and sellingdifferent things can mostly be represented by the same general patterns.

Although this kind of abstraction is the basis for any kind of standardiza-tion, it has its limitations: abstraction is always made from the real aspectsof objects in question only, not from their functional aspects. A product re-mains a product, that is: something a company sells in order to make money,and so on. As a consequence, optimization systems that follow these patternscan only represent what their designers expected to be part of the underlyingfunctional schema.

Take SNP in SAP APO, for instance. This system very well describesthe 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 oftransport vehicles, etc. All such details can be represented in optimization withspecific costs, capacities and other constraints. But the underlying functionalschema remains unchangeable.

This is where TriMatrix takes off. There is no underlying functional schemapresupposed. The only presupposition is this: Any action to be executed canbe described as “generate and/or consume resources of any kind at a certain lo-cation in a certain period of time”. For example, production may be describedas: consume raw materials and capacity and generate finished product(s); atransport could be described as: consume product at location A, generate thesame product at location B, and consume money (transport cost); a sale couldbe described as: consume finished product and generate money (income); andso on.

There is no intrinsic restriction to what may appear in the list describingthe possible actions to be executed. In case additional items are needed (forexample, if a sale also has to take duties into account) they are just added tothe list.

Resources may be: product, raw material, money, time, capacity, or what-ever else can be expressed in terms of quantities. Locations may be geograph-ical 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 thatsense. Time periods represent the flow of time with its characteristic unidi-rectional sense (time cannot go backwards), discriminated into slices of anylength (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 almostany 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 struc-tures are not defined in the model, but by data definitions only. Consequently,the underlying system is always identical, whatever be the real world problemto be represented and solved. No involvement of developers is needed. Thatis why the people who created TriMatrix claim it is a “general optimizationframework for individual solutions”.

Achieve Calculation Speed by Specific Data Preprocessing

The real-world problem to be solved at BASELL has the following character-istics:

• Different products may have to be produced on a certain production lineand are subject to the procedure.

• 30 days, starting today, are represented as individual time periods. Thesetime periods describe what optimization focuses on: the search for a fea-sible production schedule that fulfills all demands and restrictions definedfor the next 30 days.

• Furthermore, two additional time periods represent the following twomonths, where “month” is not a calendar month, but a time period com-prising 30 days each. These two additional months are looked at by theoptimizer in order to prepare for future demand that might have impacton the first 30 days as well.

• Demand for products is defined at the same level of precision: the first30 days have daily demands, composed from actual customer orders andremaining forecast broken down to individual days, while demand for thetwo additional months are aggregated accordingly.

• Production is represented with starting conditions and rules a good pro-duction sequence has to pursue: some changeovers from one product toanother are not feasible at all, while others are evaluated against eachother by the amount of damage created.

• Stock is represented with starting conditions, as well, and minimum re-quirements to be observed on each day.

The optimization problem can thus be described like this: Look for a pro-duction schedule that serves the demand on time, takes into account stockconditions and requirements, and provides optimal production sequencing.

The size of the problem to be solved can be expressed by the number ofvariables needed. For sequencing problems, the number of different orders thata given number of products can be arranged in is calculated by the facultyfunction (expressed by “!”). The number of possible orders for 10 differentproducts, for example, is 10! = 3,628,800; 20 different products already con-stitute 20! = some trillions of different orders – and so on. Although morevariables are needed in order to represent stock, packaging, and sale, this cal-culation 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 todo this in a couple of minutes, as users would expect.

This is where data preprocessing comes into place. It reduces the numberof variables by identifying the relevant alternatives optimization may choosefrom, and thus achieves computing times that are in sync with user expecta-tions. How is this done? These are the general strategies:

• Arrange products to be produced in their order of urgency. This can bedone for each product by fulfilling its demand from stock until the day itis exhausted; the earlier a product is exhausted, the more urgent it is.

• If no rules and restrictions on product sequencing were defined, the orderachieved would represent the natural order in which products should beproduced.

• Now sequencing comes into place: If two products follow each other ina way that would somehow violate proper sequencing, all other productsthat would recreate a proper sequence will be placed between them.

• After this procedure, a product sequence is achieved that still allows toproduce in the order that is constrained by the demand, but provides addi-tional intermediate campaigns that allow for proper sequencing. By usingthese intermediate campaigns, products that would originally come laterin the sequence might be advanced in time. Thus, several alternative pro-duction paths are created that may be pursued. The optimizer rearrangesthe product sequence by using these intermediate campaigns as slots in or-der to fulfill sequencing rules and minimize the damage created by productchangeover.

The size of this problem is only a small fraction of the size of the originalproblem outlined above, and thus can be computed in a fraction of the time.

TriMatrix provides a data processing engine where such preprocessing canbe implemented. Certainly, this preprocessing cannot be done in an abstractway, but has to follow the specific constraints imposed by the current problemto be solved. For this purpose, the general optimization framework providedby TriMatrix is supplemented with individual algorithms that do the pre-processing described above.

By this, the creators of TriMatrix claim that it can overcome the limita-tions of standardization: provide a kernel that does all the general optimiza-tion work and that can be fed with almost any type of optimization problemthat comes up in real world situations; and, at the same time, provide addi-tional data processing capabilities that help to support solutions that can bestreamlined 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 pro-vide a summary of experience in optimization projects. We consider the con-sequences of how the SAP APO optimizer can change habits in companiesand we give some views on how real world optimization might develop inthe future. We also express which features might further increase – from themathematician’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 optimiza-tion problems in various industries – this is “real optimization with SAPAPO”. Challenging problems are solved by exact optimization techniques im-plemented in SAP APO. The case studies presented should motivate readers tothink more about the opportunities mathematical optimization in SAP APOoffers. The reader and project teams implementing SAP APO are encouragedto do “real optimization with SAP APO”. Currently, many implementationsof advanced planning and scheduling systems do not yet fully utilize the math-ematical optimization potential. There might be several reasons for this:

• The clients are still busy with the first implementation steps of SAP SCMtargeting at goals like supply chain data visibility and forecasting and thusthe focus is not yet on planning and scheduling using mathematical opti-mization. The scope of most SAP APO implementations is still DP beingthe least complicated component, both technically and organizationally(see Dickersbach, 2004, [17]).

• The clients may have a professional background which is not close to mod-eling and optimization. Thus, they do not consider this in the first placeand hesitate to use optimization at all.

• Clients in companies which have a strong history in mathematical opti-mization (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 approximationquality to their “real world”.

• SAP as a company does not primarily position SAP APO as a tool formathematical optimization and does not provide extensive in-depth train-ing regarding modeling and optimization.

Conceptually, optimization in SAP APO has been designed in such a waythat the users1 build the model via the master data and can choose from pre-set solution techniques, but do not see the mathematical model equations.For many users this is what they probably prefer. Some real world planningproblems, however, require a more in-depth treatment of the mathematicsand/or modeling tricks with the available objects in SAP APO. SAP’s inhouseconsultants will help to explain the underlying mathematical assumptions, butconsultants with deep optimization and business software knowledge are oftenscarce. This is especially important to users who will not just accept a blackbox solution but really would like to understand what the underlying modellooks like and what they are computing.

In most cases it is not easy to replace an existing optimization applica-tion based on a tailored mathematical model by an APS based on predefinedmodels. Of course this depends on the complexity of the planning problem,the planning philosophies, and the solution techniques. For the case study inChap. 8, for example, it turned out that the planning philosophy of the cus-tom solution (integrated planning) and SAP APO (hierarchical planning) aredifferent and replacing the existing solution would result in splitting the plan-ning features and functionality in a medium-term and a short-term planningcomponent.2 Thus the change would result in considerable effort, probablycomparable to a new implementation.

SAP APO was developed claiming to be a standard to serve various in-dustries in planning and scheduling. If it matches the needs, then this is thebest that can happen. SAP APO meets the requirements of the industries onthe whole (keeping in mind that MILP optimization is just one aspect of SAPAPO). It would be interesting to know how many successful SNP optimizerlive implementations are used but without access to the SAP customer direc-tory it is impossible to quantify the ratio of companies using the SAP APOoptimizer over those using optimization add-ons to it or tailored models.

If after a careful analysis of the planning requirements it turns out thatadded 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 9and results in creating a mathematical optimization model that is interfaced1 Of course, “user” is not to be understood as the end user of the planning appli-

cation, but in the sense of the person who uses the software to implement theoptimization model.

2 It depends on the size and the structure of the decision problems whether it ispossible to treat aggregated and detailed planning in one model rather than in aseparate, 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 technolo-gies to connect own models and solution approaches to SAP APO. The secondpossibility is to discuss and conduct a development project with SAP opti-mization development resulting in a solution all within SAP APO. In thatcase it is a good idea to bring the mathematicians inside the SAP companyand 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 implica-tions of having bounds or not having bounds. We focus on data, the conse-quences of data inaccuracy and implementation issues, and illuminate the rolerules play in planning and scheduling and their importance for model build-ing. This section is based on the experience the authors obtained in a total ofover 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 mathematicaloptimization used in various supply chain problems. We have not yet focusedmuch on when mathematical optimization is most useful. Thus let us do thisnow by assuming a company wants to use it for production planning. A firstaspect to consider is the number of products involved. If the company producesonly one product 24 hours per day and 365 days per year there is not much toplan. It is safe to advise the company that mathematical optimization will nothelp much. The key element missing in this case is complexity . Mathematicaloptimization is extremely useful if the underlying decision problem can bequantified and involves many degrees of freedom and constraints leading toa complexity which is not easy for human beings to grasp. Ideally, the kindof optimization we have in mind is best for reasonably complex productionnetworks with utilization rates close to 100%. The argument here is similar tothe first one used above. If the production network is only utilized, say up to40%, then the decision of where to produce how much of a certain product isnot too difficult. Mathematical optimization can do it but probably the humanplanner can do it as well. If the amount of products is significantly above thecapacity of the production network the problem is more one of feasibility thanof optimality. The decision which customers can be served and which not canbe triggered by priority lists, customer classifications, etc., but usually theseaspects are difficult to specify in advance. Nevertheless, optimization can helpeven in this feasibility problem case provided the problem owner is willing tomake all aspects transparent in advance.

256 10 Summary, Visions and Perspective

Next we discuss scheduling. The border between scheduling and planningis often somewhat artificial. While scheduling includes many more details re-lated to the production process it usually covers only a significantly smallertime horizon, say a few days or weeks. As it is the case in planning: at a lowutilization rate the problem is relatively simple and mathematical optimiza-tion is easy. Optimization works best with respect to capacity gains whenthe utilization is close to 100%. Another benefit is to react faster and betteron spontaneous customer requests. Although continuous-time MILP formu-lations are a good choice for the chemical process industry including batchand continuous production, most MILP or MILP&CP hybrid approaches ex-perience difficulties if the utilization exceeds 100% significantly. The reason isthat the optimization problem becomes more and more a feasibility problem.The user has to provide reasonable data specifying which kind of weakly in-feasible solutions are tolerable, e.g., accepting late delivery, not serving somecustomers at all, violating the companies safety stock policies, stopping somereactors for a while, or driving the plant units slightly above their technicallimits. Mapping a scheduling problem to a mathematical model creates againtransparency. Human planners usually follow a set of rules which they areused to; see also Sect. 10.2.3. During the modeling process the reasons forsuch rules are made transparent.

That touches a very relevant aspect of mathematical optimization. Thedeclarative approach of optimization requires that all restrictions have to bespecified in advance – they are transparent. Of course, iterative modificationsare possible if a model differs too much from reality. As a consequence ofthis transparency mathematical optimization can help in the power battle oneoften experiences between sales departments, marketing units, and productiondepartments. It can help to put arguments on rational grounds – and it canlead to a shift of power.

In this book we often stressed the difference between the mathematical andthe business language usage of the term optimization. Somewhat connected tothis difference is the preference for exact optimization algorithms defined inSect. 2.2 versus improvement methods. Here we want to give some orientationon the consequences and requirements of both approaches. A valid questionis under which circumstances is it reasonable and worthwhile to strive for theexact 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 makesure 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 abstractionand/or a simplification of the real world. Although the client might ask somemathematicians for support, the only person who can decide on whether amodel is sufficiently accurate is the client who defines the purpose of themodel. It is of paramount importance that the client clearly defines this pur-pose and expresses what he or she wants to do with it. Never start a projectwithout being clear about the purpose, or start the project by working outthe purpose if that is what the client pays you for. To give an example, weconsider the process and design of building an elevator. The purpose is: trans-porting people or goods safely. An engineer or mathematician will probablyask: how many people, alive people or dead people, how much weight, whichtransportation speed and acceleration? He might also ask where the elevatoris to be used: on Earth, the Moon, or on planet Mars – in 20 years this will berelevant. 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 optimizationmodels we need to apply a similar level of care. Considering certain featuresor neglecting them may systematically change the results or the usefulness ofresults. Let us consider a planning problem targeting for good schedules whichcan be used in real life. Modeling batch reactors without considering fillingstations may produce results not usable if the filling stations turn out to be abottle neck. If there are plenty of filling stations available it is safe to neglectthem. Thus we learn that the features to be included in a model do not dependon the purpose but also on the values of the data. Even worse, if they dependon 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 processis accompanied by sufficiently competent personnel. Sales people when tryingto sell software should always be accompanied by technical people becauseotherwise there is a great chance that relevant points are missed leading toIT projects which in the end take much longer than expected, leading to timestress, or costing much more than expected.

In Sect. 10.2.2 we elaborate more on how to establish the accuracy and theconsequences of inaccurate data. To discuss the value of optimization versusimprovement methods let us assume that the model is approximating the realworld sufficiently accurate not leading to any systematic problems and thatthe data are exact (we relax this assumption later on).

To illustrate the problem when using improvement methods instead ofexact optimization algorithms let us work out the consequences of not havingor having tight and save bounds by considering the following example.

Assume that a large industrial user wants to compare the economic im-pact measured as the net present value (NPV) of two different investmentdecisions. Each decision would involve a combination of building new produc-tion facilities and discontinuing the use of old, less competitive assets. Theinvestment 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 manufacturinglocations.

After modeling and solving the problem using an exact optimization algo-rithm, the results presented for each alternative are:

units of million US$ alternativesscenarioNPVintegrality gap, max. deviation from optimal solutionMaximum possible NPV

A B110 1202.1% 1.8%

112.31 122.16

If we want to maximize the net present value of the two alternatives thenclearly, scenario B is better and preferable. Note that scenario A is boundedby 112.31, while in B we have already a feasible point with objective functionvalue 120.

A nonbound generating method might produce the following results:

units of million US$ alternativesscenarioNPVintegrality gap, max. deviation from optimal solutionMaximum possible NPV

A B112 110n/a n/a? ?

Since such methods do not provide the maximum possible deviation from thetrue optimal solution, a user might conclude that alternative A is more prof-itable. Note that in Scenario A we found even a better feasible point than theexact method. This demonstrates even more that computing feasible pointsis 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 valuethat is 99.7% optimal for alternative A and a value that is 90% optimal foralternative B. This can happen in real life; there is no control or guarantee forthe solution quality of improvement methods. In this example case we couldonly quantify the deviation from the optimal solution because we computedthe comparison basis with an exact optimization algorithm.

Therefore, we believe it is in the clients’ best interest to either prove opti-mality or at least provide reasonable tight bounds on the value of the objectivefunction. In addition, the use of exact optimization methods can be coupledwith sensitivity analyses, analyses of robustness, and stochastic optimizationdescribed in Sect 2.4.3. If the data we used in the example scenarios A andB 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 fairstatement saving us the trouble to have lengthy meetings and discussions. Ifthe input data are more accurate the scenarios can be distinguished givinga quantitative basis for further discussion. But note that the dependence ofthe uncertainty of the objective function on the uncertainty of the data canquantitatively 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 havethe 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 optimizationis 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 modifiedto be of more strategic spirit by adding appropriate design degrees of freedom.But even in pure operative planning problems, it might pay off to implementexact methods depending on the quality of the solution generated by exactoptimization or improvement methods.

There is another important difference between optimization algorithmsand improvement methods: exact fulfillment of hard constraints and the proveof infeasibility of a problem. Optimization algorithms guarantee constraintsto be satisfied. In improvement methods they are sometimes implemented bypenalty methods (this is actually a method to treat soft constraints). An al-ternative approach is to reject infeasible points completely. If an improvementmethod fails to determine a feasible point we cannot safely conclude that theproblem is infeasible. Of course, the exact fulfillment of hard constraints ispart of the discussion leading to a model which is sufficiently accurate andaccepted.

The permissible CPU time to solve the problem may be seen as somethingconnected to the purpose of the model. For planning problems MILP algo-rithms are usually sufficiently fast and CPU time is not a problem. However, ifthe purpose is to model and solve a scheduling problem to be used only opera-tively, it is usually expected to get a short response time, i.e., the solver is ex-pected to return a result in a few minutes. Scheduling problems as mentionedabove are usually difficult to solve and only highly specialised algorithms andtechniques can produce optimal solutions at all. Overall, short response timesare difficult to obtain for scheduling problems. Thus, improvement methodsare often seen as a last resort to produce (near) feasible schedules (althoughthe feasibility is a problem for improvement methods) in short time. If theclient wants to use the same scheduling problem also to investigate investmentquestions then the use of improvement methods is doubtful as the exampleabove illustrates. Ideally one would expect that a combination of exact opti-mization and improvement methods could solve the problem. Such a hybridmethod would use an exact algorithm for a small or mid-size problem and animprovement methods if the problem becomes larger or the solver does notreturn a feasible point quickly enough. However, technically this is not easy atall because the exact optimization algorithm expects a declarative model, sayan MILP model. The improvement method in contrast cannot easily digestthis model but requires a model formulation or problem structure which usesdifferent 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, permissibleCPU 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 gen-erating feasible points. This decision itself, as far as the functionality aspectis concerned, could be put on a quantitative basis by exploiting appropriatemathematical methods.

The aspects benefits and cost associated with both approaches (optimiza-tion versus improvement methods) are important and difficult to quantify atthe same time. Improvement methods, although technically simpler than ex-act optimization approaches, are not necessarily cheaper. Costs may includecost to buy or built a model and a solution technique, train people, integratethe approach into an existing structure or replace an existing structure, followup costs, etc. Experience shows that the costs are often underestimated. InJapan there is the tendency not to hide this but just to add more money – andeverybody is happy and the project is presented as a success as long as thetool works in the end and produces more benefit than costs. In Germany thereis 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 thefact that many decisions for doing something would not be taken if the costsappear too high in the beginning. Comparing the costs to benefits is an artin itself. There are hard benefits which sometimes can be well estimated toonly some order, but are easily wrong by a factor 2 or 3. In addition there areweak factors which often cannot be converted into money but are importantnevertheless: transparency, more consistent data, a well-established qualitylevel of a whole supply chain, more independence from the individual planneror decision taking person (a very delicate issue), changing culture and power(a human planner designing cutting stock pattern in the paper industry caneasily 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 importantissue: if a company wants to introduce a reasonable piece of software, thenthis 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. Ifthe weak benefits are the main driver then this will need to be communicatedand the management should justify this as a political or cultural decision notpretending commercial reasons working out monetary benefits estimated toohigh versus costs estimated too low. Let us discuss the weak benefits asso-ciated with improving the quality of company-wide databases. The softwareSAP provides significantly helps in cleaning the data a company holds; so dooptimization projects for the reasons discussed in Sect 10.2.2. But do compa-nies 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 notproperly show up in the benefits. If these costs are not quantified, could wedraw the logical conclusion that inconsistent data do not cause any problemsto companies, and it does not matter whether data are consistent or not? Asame line of arguments could be drawn for other weak benefits. Let us con-clude 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 triggerdecisions (we do not consider the case that somebody has already decidedand just looks for appropriate numbers supporting the decision), technicalmeans, project time, and personnel costs should be provided to work out thedecisions as well as possible. Thus, a safe advise in the context of SAP APOand optimization projects, is not to leave the field to sales persons (underes-timating costs believing this helps to get the deal) or high ranking managers(overestimating benefits because, believing in the idea of the project, theythink it is really great for their company) alone. SAP APO and optimizationtouch real world problems. Reality always strikes back (cf. De Beuckelaer,2001, [16]) – therefore, add technical personnel to working out decisions al-though this may be expensive. SAP has competent personnel available, i.e.,people with mathematical optimization background, so do many companies inthe metal, chemical or other industries. Bring them together and have teamsworking out relevant decisions involving simultaneously the board members,production leaders, human planners at the production floor, and mathemati-cians sitting at one table. Decomposition is a nice and successful techniquein mathematics. But observing that estimated costs are usually underesti-mated, it seems not to work too well for decision taking whether to initiate alarge scale optimization project or to introduce a software such as SAP APOaffecting 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 tokeep in mind that they are interpreted differently from the way a humaninterpreter looks at them. If you tell somebody a certain activity will last 24hours, the human interpreter will probably accept if it takes only 23h59m. Amathematical model would probably return something like infeasible. Thus,one should keep in mind that a mathematical optimization model expects verywell defined and consistent data.

In the optimization model concept, there is an important difference be-tween the human planner and scheduler and the optimizer’s world. Humanplanners usually know how to cope with certain situations – they can usuallysurvive with a small and fuzzy set of information. Once a model is avail-able the consequences of non-exact data on the objective function values canbe mathematically analyzed and quantified using the sensitivity analysis de-scribed on page 37. Note that this is only possible if a model is available and ifthe problem can be solved quickly to optimality; this is an additional value ofa model. If the uncertainty of data can be quantified by probability distribu-tions, stochastic programming or chance constrained programming describedin Sect. 2.4.3 can be applied.

Optimization models (for planning or scheduling) usually require a hugeamount 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 andschedules have to be described implicitly. Let us illustrate this by a humanpathfinder who knows a good way to cross a forest. He is very familiar withthe 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 pos-sible paths of the whole forest. Therefore, it can find the optimal path andprove that this is the optimal path. The human pathfinder cannot prove theoptimality of his path without knowing the rest of the forest.

The great challenge in model building is to identify the business rules whichunderlie existing planning or scheduling processes. Besides issues of politicalnature – such as managers afraid to give up or modify the way they work be-cause they fear becoming vulnerable in their organizations – many plannersare not really able to describe explicitly or define precisely the process theyfollow. Often there is no well-defined and documented planning process, thehuman planners know implicitly how to construct plans. The real planningrules and constraints can then be extracted from them only by constructingmore or less pathological cases and asking them how they would decide. Cor-porations resulting from a merger of several companies may have a multitudeof planning procedures in place, often differing only in their strategies forhandling exceptional situations. Thus, developing a reasonable and acceptedoptimization model is a lengthy and iterative process interwoven with a seriesof 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 declar-ative. All constraints hold simultaneously. They are implicit restrictions to besatisfied. In real life one often faces situations that human planners follow cer-tain rules to obtain reasonable plans or schedules. Rules can be recipes howto handle certain situations, heuristics trying various steps, or just experienceaccumulated in the human planner’s brain only. These rules sometimes enableus to derive and formulate constraints. In other cases, they represent more aheuristics to obtain feasible plans, or they follow certain goals possibly notyet made explicitly known. From the optimization point of view rules are usu-ally simplifications of the real world problem eliminating degrees of freedomleading to suboptimal solutions.

A planner following the rule that the production is adjusted in such away that the tank level is always between a lower limit and an upper limitmay lead us to ask about the meaning of these bounds. If the lower limitrepresents a safety stock or a limit justified technically and the upper boundthe capacity of the tank, his rules are fully compatible with the declarativenature of an optimization model; we would apply lower and upper bounds onthe tank variables. All tank levels between these lower and upper bounds aretreated 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 leveloften reaches the lower or upper bound.

If he follows the rule that he strictly observes the rules but also targets atstaying away from the extreme bounds to gain more flexibility at any time, wehave more than just the declarative nature. Partly he follows a goal (keepinga level of flexibility which comforts him), partly he influences the solutionprocess itself. If he convinces us or insists on keeping the tank level close tothe average value, we could penalize deviations from that average value.

A rule which contradicts somewhat the concept of mathematical optimiza-tion might be to fix individual production machines to a 100% utilizationlevel. If this rule only results from the production department being evalu-ated according to the overall utilization of the plant we should be careful withimplementing this rule. From the overall commercial view it maybe betterto sometimes stay well below a 100% level. A constructive approach the de-veloper of a mathematical optimization model may take is to offer a flag orswitch which realizes this rule as a bound in the optimization model. Thiskeeps the person in favor of the rules happy when the flag is switched on, andallows for transparency when the flag is switched off.

There is another aspect which becomes obvious when dealing with severalrules, 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 understoodand interpreted. It is, however, very important that the client understands thedifference between rules and mathematical optimization. Rules eliminate de-grees of freedom. Ideally, one should allow the user to use flags enabling ordisabling the familiar rules and thus allowing to make the effect of rules trans-parent. However, one should keep in mind that the mathematical modelingprocess targets to model the planning problem not the set of rules. Makingall rules explicitly known creates transparency. Not knowing all rules is notideal in terms of transparency. Providing a button mimicking the rules likelycreates acceptance but will most likely not lead to the global optimum.

In this context it is interesting to note that the SNP optimizer in SAPAPO offers a functionality (via the optimization bound profile) which enablesthe user to influence the solution in such a way that the returned solution willbe similar to the one obtained before. This is an example for a rule creatingmore stability in the resulting plans over multiple planning runs. It can beused merely to increase the planner’s acceptance or – and this is the reallyrelevant application – to level resource loads over time in the supply chainwhich is a perfectly valid business objective.

10.2.4 Implementation

Implementing an SAP APO solution very often occurs along with a mySAPERP implementation or follows introducing mySAP ERP for transactional

264 10 Summary, Visions and Perspective

production and logistics processing. Such a closely interwoven implementa-tion of ERP and advanced planning is typically most effective because of therelatively easy fine-tuning of the business processes between the two systems– once one of the systems is in place operational setup changes often involveconsiderable effort.

One of the biggest and most difficult tasks in implementing a new ERPor advanced planning solution is putting together a consistent set of masterdata. Especially in companies with many subsidiaries – and this is one ofthe business landscapes where optimization is most useful – it proves to bea lengthy and effort-intensive process that is always underestimated. If thecompany has grown by mergers and acquisitions these data are often in a ter-rible condition regarding such trivial-looking aspects as naming conventions,multiple occurrence of the same products in different contexts, etc. Directlyderived from that, one of the biggest benefits of a supply chain project statedby the user is usually the improved data quality on a corporation-wide level,together with benefits typical for supply chain optimization projects such asreduction in inventory, better customer service levels, and automated businessprocesses.

A challenge often encountered in implementing advanced planning is an ad-equate needs assessment before the actual implementation starts. Frequently,the prospective users are familiar with ERP-like software systems, but no ex-perts in mapping their business process in a level of detail and completenessnecessary for building an optimization application, be it a custom-built modelor an APS such as SAP APO. Resulting from that, supply chain software isbought as a package without going into details such as planning algorithms.During implementation, all sorts of issues regarding the detailed business rulesmay come up and often it will be too late to reconsider the chosen planningalgorithm or solution approach. It is the responsibility of the software ven-dor or mathematical consultant to adequately assess the real needs of thecustomer and – ideally – educate the client in the suggested methods andalgorithms. This needs to include revealing side-effects that may influence theplanning result. A current favorable development in this area is that thereare increasingly more people familiar with optimization at SAP and that theyhave the opportunity to participate early in supply chain projects to set ex-pectations realistically and work towards a solution that really fits the needsof the customers.

As mentioned numerous times in our cases, much care must be takenexplaining the optimization results to the user. This, again, requires peopleskilled and experienced in optimization and SAP APO and able to transferconfidence in the algorithm to planners and schedulers not familiar with ad-vanced OR methods. As an easy example, think of the concept of penaltycosts that are used to implement soft constraints and implications that willarise if their relation to real costs and their interdependency among each otherare 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 attentionto the data and the data model customized in mySAP ERP or SAP APO.Mathematical optimization often has different requirements to the data andtheir usage from what is needed when these data are used exclusively insidemySAP ERP or SAP APO. When using the SAP APO optimizer data inte-gration of the application database with the built-in optimization model istaken care of automatically. In projects in which a customized optimizationmodel is interfaced to mySAP ERP or SAP APO, the data might be storedin its own local database or user interface and the data might be enhancedeven from systems outside of SAP.

It is very important to check the consistency of the data. This is partlyrelated to the data themselves, but even more to the usage of the data inthe optimization model. If a state-task-network approach is chosen to modela scheduling problem in the process industry there are additional topologicalinformation needed. Once the data are in an optimization model, they gaina new dimension: this is exactness. Data used in hard constraints such astopology or mass balances can easily lead to infeasibilities. This is of extremeimportance if the data have only been used by a human planner. If the samedata now should be used by an automatic system, disaster can happen.

Ideally, the interface connecting SAP APO and the tailored model shouldinclude an automatic consistency checker identifying hard infeasibilities causedby data errors (e.g., the lower bound on tank level is larger than the capacityof the tank), or pointing out conflicts caused by incompatible data (e.g., ina scheduling problem the demand for a non-storable product is smaller thanthe minimal batch size of a chemical reactor).

10.3 Further Developments in Real World Optimization

Further developments of mathematical optimization in SAP APO dependstrongly on SAP’s own claims and business concepts related to SAP APOas an APS, requests formulated by clients, joint development projects withclients, activities of SAP’s competitors, and last but not least, algorithmicdevelopments in mathematical optimization. Thus, this section is less on pre-dicting 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 relatedSAP APO core functionality. Some of the case studies we present in this bookare based on prior releases of SAP APO and the functionality these externaloptimization models provide might now be part of standard SAP APO. Inthis section we want to state some recent planning philosophies outlining howthey might be implemented using SAP APO and briefly discuss SAP APO asa modeling tool.

266 10 Summary, Visions and Perspective

APS providers, and SAP is no exception, still hesitate to include topicssuch as customer or product portfolio optimization, planning under uncer-tainty, multi-criteria optimization, or even MINLP in their predefined APSmodels. These topics are considered reserved for specifically tailored mathe-matical optimization models – in the context of APS they are still part of amathematicians dream; see Sect. 10.3.4.

In this context we want to stress that among the most important topics forstandard software providers are profitability and the aspect of maintenance.Standard software vendors need high sales volumes in order to be successful inthe market. Transferred to optimization this means that economically it mightnot make sense to implement the latest state-of-the-art algorithms availablerealizing that they (a) need time to mature until suitable for standard toolsand (b) need to raise enough awareness and need in the market for actuallyconvincing clients to implement them. Therefore, rolling out highly specializedstate-of-the-art algorithms will consume excessive resources for maintainingthe software for just few, probably unhappy customers. In short: The customercan expect to get a reliable Audi, but not a Formula 1 Ferrari. The customerdraws advantage from this principle software vendors such as SAP follow: Heor she can rely on product support once a specific functionality or featurehas found its way into the APS – as long as the maintenance contract isactive the software vendor will support a specific optimization application;this might not be the case for specifically tailored optimization models doneby external consultants or even in-house if the respective mathematician hasleft 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 distinguishbetween operative planning and strategic planning is often a rather artifi-cial approach leading to unnecessary bottlenecks in operative planning. Ide-ally, the diffuse border lines between those areas should be overcome and thestrong overlaps between planning in production, distribution or supply chainmanagement and strategic planning should be exploited. Kallrath (2002, [50])describes a successful case study in which operative and strategic planningaspects are combined in one MILP model. The client reports cost savings ofseveral millions of US$ achieved via a reduction in transportation cost com-pared to the previous year when the model was not in use. The solution fora one year planning horizon allowed the company to better understand andforecast the flow of products between its sites. This knowledge was then usedto reduce the need and cost of urgent shipments. Moreover, it was beneficialto the client to see that the design solutions (which reactors to be opened orto be closed) were stable against up to 20% changes in the demand forecast.

The basic idea in this simultaneous approach is to include optional unitsand 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 SAPconcept of master data that defines the model this is also possible. Perhaps thenature of the task would then suggest a scenario in a planning version withoutfull 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 includethose in the ERP system as well.

Similar to simultaneous operative and design or strategic planning, in somereal-world problems it is appropriate to drop the barrier between mid termplanning and short term scheduling. If the problem is sufficiently small such asimultaneous optimization planning approach will lead to better results than alayered, hierarchical approach. As described in Chap. 8, SAP APO – althoughdesigned for hierarchical planning – can be used for simultaneous planninglike this if care is taken regarding specific model features (e.g., implementingsequence-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 in-volves so many subtle details that we might wonder whether a standard modelwill ever exist. Especially in the process industry one has to face complex prob-lems 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 includingextruders, batch reactors, tanks and silos, switch-tanks, and filling stationsreaches a hundred leading to huge state-task-networks introduced by Kondiliet al. (1993, [60]). Nevertheless, such problems have been addressed success-fully using continuous-time formulations using decomposition techniques. Werefer the reader to Ierapetriou and Floudas (1998a,b; [40], [39]), Ierapetriou etal. (1999, [41]), Lin and Floudas (2001, [66]), Lin et al. (2002, [67]), Floudasand 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 theprocess industry using mixed integer linear programming and, in particular,continuous-time formulations, and to Janak et al. (2006a,b; [43], [44]) for alarge-scale industrial case study.

As there currently are no standard models for mathematical optimizationfor scheduling we will not find them in standard business software. SAP APOaddresses this and meets clients’ need for a standard solution by treatingscheduling problems by evolutionary algorithms and constraint programming.While to a mathematician neither of these techniques is exact optimizationunless they are coupled with bound-generating techniques, they are widelyused 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 couldbe enhanced by continuous-time aspects via a custom development by SAPor, alternatively, interfacing an external optimizer via the standard SAP APOOptimization 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 optimizationtechniques while scheduling problems are treated by evolutionary algorithmsor constraint programming. While the former is not an exact optimizationtechnique in the sense of this book (cf. the definitions in Chap. 2), the lat-ter can produce feasible solutions but is very limited regarding optimization(for sums of linear terms the constraint propagation is not efficient). Moresignificant is the restriction that the SAP APO MILP optimizer assumes de-terministic input data to planning and scheduling.

Many planning and scheduling problems are, however, subject to a varietyof uncertainties. Demand forecast is one source of uncertainty in planning;processing time subject to stochastic fluctuations are an example for uncer-tainties in scheduling.

Modeling and solution approaches for both planning and scheduling underuncertainty are well developed in the scientific literature but they still need tobe integrated into the optimizers in many APS such as SAP APO (cf. in thiscontext the adaptive supply chain network support in mySAP SCM, aimingat the unexpected in supply chain management).

10.3.4 A Mathematician’s Dream

There is a continuous trend in mathematics that new developments becomestandard technologies after some time. In the 1950’s special solution tech-niques were developed to solve differential equations numerically. Nowadays,these are standard. Until 1980, solving MILP problems was a challenge. To-day, many difficult MILP problems are solved in short time with standardcommercial solvers such as CPLEX or Xpress-MP. Let us dream a little bit andbe optimistic and extrapolate into the future. Advanced planning systemssuch 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, and3 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 keepingtrack of origins.

Finally, customer and product portfolio optimization will be possible. Andhopefully, 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 feedit with data constituting the supply chain model, for instance by filling in flatfiles containing products and BOMs in a predefined way. SAP APO followsa different philosophy: the supply chain model is built from the SAP APOdatabase that can be integrated with the connected ERP system. In this way,a large part of the model is built automatically; during implementation theAPS- and planning method-specific settings are taken care of. If needed andas we outlined in Chap. 8.3, the resulting model and the objective functioncan be modified in various ways by appropriately modifying the master dataand the cost coefficients. Once this way of modeling is accepted, even “non-monetary” objective functions can be built based upon the predefined one.

A modeling tool in optimization will share some properties with mod-eling systems in mathematical optimization; cf. Kallrath (2004, [53]). Theway described above turns the solver tool SAP APO into a modeling toolthat addresses – within the limits of the underlying predefined mathematicalmodel – a wide variety of supply chain optimization problems. For clients withtraditionally strong mathematical optimization groups and mathematicians,including a declarative modeling language that would result in complete flex-ibility regarding implementing specific business rules would complement thepresently available modeling alternative in a perfect way (for mathematicians).On the other hand, including such a modeling language would significantlycomplicate product support which now can rely on one mathematical modelformulation and may limit user problems to the master data structure andthe optimizer customizing.

10.4 The Future of Optimization with SAP APO

The market position SAP has as the world’s leading business application soft-ware provider, its leading position also in the overall supply chain managementapplication software market, and the highly integrated approach of the SAPsoftware puts SAP APO in a favorable position to fulfill its promise “Ad-vanced Planning and Optimization”. For several years SAP APO has beenin the position in which clients see it as a candidate for their planning andscheduling activities.

Nevertheless, companies in the chemical industry such as Bayer AG, BASFAktiengesellschaft 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 websitehttp://www.sap.com/, this might lead SAP AG to roll in the technical re-quests from clients efficiently and be even closer in contact with the mathe-matical optimization community.

At the same time one has to keep in mind that compared to tailored op-timization models and applications, standard solutions have to achieve muchhigher standards of scalability and maintainability. This is an area SAP hasa proven record of with its suite of business solutions including SAP APO.Meeting this objective is mutually exclusive with supporting the latest devel-opments in mathematical modeling, the latter just needing time for maturinguntil they can be built in “industrial strength” standard solutions.

The proven success SAP has in the market along with SAP representa-tives participating in the supply chain management and operations researchcommunity give confidence that SAP will continue to strive for includingstate-of-the art optimization technology in their product. The race is neverover!4

4 In December 2005, SAP made the new version mySAP SCM 5.0 available forselected customers, see [74]. Enhancements relevant to optimization include theExplanation 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 SAPAPO beyond the SNP optimizer, the latter being the focus of the rest of thisbook. In this brief overview of what is in SAP APO we want to give a flavorof the rich functionality this tool has to offer without claiming to go intodetail which most probably would fill a number of additional books. We alsoomit system basis, architecture, and database considerations focusing on thebusiness application components. The purpose of this appendix is to give thereader a self-contained and quick reference to the SAP APO functionality.

Within the mySAP Business Suite, there is the supply chain managementoffering mySAP SCM providing solutions for supply chain collaboration, plan-ning, coordination, and execution processes. SAP APO is one component ofmySAP SCM providing functionality for planning and executing supply chainprocesses (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. Dick-ersbach, 2004, [17]). The components differ in their level of planning detailand the respective time horizons. They can be arranged in the supply chainplanning matrix as demonstrated in Sect. 1.2 or be interpreted as constituentsof 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 Schedul-

ing, 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 Collab-oration enabling data exchange with business partners using other systems orvia the internet and Supply Chain Monitoring providing supply chain perfor-mance KPIs, alerting in exception situations, and monitoring and comparingplan quality. There are also several industry-specific scenarios and functional-ity available, including a standard interface for connecting external optimizersto 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 distin-guished by their planning horizon and the typical level of planning detail. Thecomponents 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 datasuch as sales forecasts as well as short-term data such as customer orders. Itis also a powerful tool to aggregate and manage data sourced from systemsexternal to SAP APO.

Below the domains of the individual components are outlined and someexamples for scenarios in which they work together are mentioned. Note thatthis description is not considered complete and depending on the specificbusiness processes of the SAP client there are numerous possibilities how toorchestrate the components of SAP APO and the ERP system.

DP is SAP APO’s demand management and operates on a data grid basedon time buckets and key figures. The time bucket lengths can be freely de-fined, e.g., the first weeks can be planned in daily buckets followed by weekly,monthly, and quarterly ones. Key figures hold different “types” of demanddata such as statistical forecast, customer demand, strategic sales targets,etc. In DP several sophisticated statistical methods are available to computeforecast data. Simulation scenarios allow what-if analyses, promotion planningand lifecycle planning are also part of DP. The data can be refined via collab-orative scenarios involving different departments within the company as wellas input from business partners with connected systems or via the internet(“collaborative demand planning”). An example for a DP scenario is com-bining the different forecast figures in the DP planning book (e.g., strategicand sales forecasts, customer data) to form a “consensus forecast” by freelydefinable macros. Forecast consumption allows defining requirement strate-gies that determine how to process customer orders and forecast values inthe same time bucket. An example is to consume sales forecast quantities byactual customer order volumes. DP can consider BOMs (DP PPMs/PDSs)

A.2 Hierarchical Planning 275

for determining component demand. Database-wise, DP uses InfoCubes, theSAP APO database, and liveCache.

Tactical planning is the domain of SNP performing mid-term supply chainplanning on discrete time buckets across all relevant locations and BOM-levels.Typically based on demand data that is released from DP, SNP uses an inte-grated supply chain model to calculate a sourcing, production, transportation,and distribution plan. Next to MILP-based optimization, which is the topicof this book, heuristics and constraint propagation algorithms are available tobe chosen to best meet the needs of the client. The algorithms are outlinedin Sects. 1.4.1–1.4.3. If it turns out the SNP plan cannot satisfy the require-ments 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 cus-tomer demand. Heuristics (applying fair-share rules if demand exceeds supplyor push rules if supply exceeds demand) and optimization are available as de-ployment algorithms. Database-wise, SNP uses the SAP APO database andliveCache.

New functionalities available in SAP APO release 5.0 relevant to optimiza-tion-based planning are the Explanation Tool and the Result Indicators (cf.http://help.sap.com/). Both are based on the optimization log data and digestthe data in the logs for easier interpretation by the user. The Explanation Toolfocuses on two typical supply chain exceptions: non-delivery of a demandand shortfall of safety stock. In order to provide a possible explanation itanalyzes the optimizer log analyzing the factors capacity constraints, time-based constraints and maximum lot sizes, product availability, lead time, andcosts. From the nature of an optimization model it can only come up with onepossible reason for each exception. Via configuration settings determining thesequence of the analysis several explanation targets can be met (e.g., checkfor maximum lot sizes before checking the cost structure, or vice versa). TheResult Indicators take data from the optimization logs, too, and present theuser 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 cre-ates a detailed production plan. Differing from the SNP concept the plan iscalculated in a time continuous way rather than being based on time bucketsand reflects the actual order sequence on the resource-level accurate to thesecond. The available planning algorithms are based on heuristics, constraintpropagation, and evolutionary algorithms. Integrating PP/DS with medium-term planning is highly customizable and works via different order types forSNP and PP/DS and planning horizons determining whether a specific de-mand or order is planned by SNP or PP/DS. If releasing demand data fromDP, for instance, those requirements inside the PP/DS horizon will be inPP/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/DSrun. In a classical integration scenario with the execution system (in mostcases this will be SAP R/3) the planned orders created by PP/DS are imme-diately visible and executed in the ERP system. Next to heuristics there isthe “PP/DS optimizer” that uses constraint propagation and evolutionary al-gorithms. Database-wise, PP/DS uses the SAP APO database and liveCache.

Global ATP and Capable-to-Promise (CTP) provide functionality for oper-ational order promising. In order to match the specific business environment,configurable rules are applied to finding supply for an order (including, forexample, location and product substitution). If desired checks can be madeagainst available production capacity and orders can be scheduled to satisfythe demand by using CTP calling PP/DS for order scheduling or multi-levelATP (including BOM explosion). Global ATP can be configured such thatupon order entry in an connected SAP R/3 system SAP APO is called in thebackground and the confirmation dates show directly on the SAP R/3 orderentry screen. As sales order confirmation is a sequential process (first come,first served), it might be necessary to redistribute the confirmed quantitiesbased on priority rules. This is done by backorder processing, a functionalitythat can be seen as part of Global ATP in SAP APO. Database-wise, GlobalATP and CTP use the SAP APO database and liveCache.

Finally, there is TP/VS planning transportation. This is not to be con-fused with SNP that also considers transportation relationships between loca-tions and results in according planned stock transfers. In a two-step process,TP/VS consolidates freight units characterized by start and destination loca-tion, quantity, and date into shipments (defining mode of transportation androute) and then assigns transportation service providers to those shipments.This can be done manually or by applying evolutionary algorithms in the firststep and – starting with SAP APO release 5.0 – mixed integer optimizationin the second step. Database-wise, TP/VS uses the SAP APO database andliveCache.

B

Mathematical Foundations of Optimization

This appendix provides some of the mathematical foundations of optimiza-tion and provides the platform enabling the reader to understand the opti-mization algorithms embedded in SAP APO. This knowledge is valuable tojudge whether a standard approach is technically sufficient to tackle a chal-lenging problem or whether individual solution approaches are necessary andpromising. Linear programming (LP) is a well established approach. Problemswith millions of variables can be solved by standard solvers. Larger problemscan be solved by special approaches such as column generations techniques.Mixed integer linear programming (MILP) problems involving thousands ofbinary and integer variables can be solved using commercial branch-and-bound solvers. Presolving techniques are very elaborated. Advanced branch-and-cut and branch-and-price methods coupled to column generation methodsare available to solve even larger problems.

B.1 Linear Programming

Consider the linear optimization problem (often called: linear program) instandard form1

LP : max{

cTx | Ax = b, x ≥ 0, x ∈ IRn, b ∈ IRm}

(B.1)

where IRn denotes the vector space of real vectors with n components and Ais a m × n matrix.

Commercial software for solving linear programing problems usually pro-vides two alternative solution approaches: vertex-based methods such asSimplex-algorithms, and interior point methods.

One of the best known algorithms for solving LPs is the simplex algorithmdeveloped 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 feasiblesolution [see Section B.1.2] as a starting point, possibly by using another LPmodel which is a variant of the original model but allows us easily to deter-mine an initial feasible solution. The simplex or the revised simplex (a morepractical and efficient form for computer implementation) algorithm finds anoptimal solution of an LP problem after a finite number of iterations, but inthe worst case the running time may grow exponentially, i.e., for large prob-lems we should be prepared that running time is an exponential function of thenumber of variables and constraints. Nevertheless on many real-world prob-lems it performs better than so-called polynomial time algorithms developedin the 1980s, e.g., by Karmarkar (1984, [56]).

In most commercially available software systems the simplex algorithmprovides the foundation of a method which will comfortably produce rapidsolutions to problems involving 1,000,000s of variables and 100,000s of con-straints. When a problem is formulated as an LP, the formulation will not beunique, e.g., some modelers may prefer to introduce certain variables to repre-sent intermediate stages in operations while others will avoid these concepts.However, provided the models are valid representations of the problem thenthe resulting LP problems will all be essentially equally easy to solve and willprovide equivalent solutions.

In contrast to the idea of a vertex-following method to solve an LP prob-lem, more recently developed methods have concentrated on moving throughthe interior of the feasible region, a polyhedron in linear programming prob-lems. Such methods are called interior-point methods and first received wide-spread attention after work by Karmarkar (1984, [56]). Since then, about 2000papers have been written on the subject and research in optimization experi-enced the largest boom since the development of the simplex method (Freundand Mizuno, 1996, [27]). The idea of interior-point methods is intuitively sim-ple if we take a naive geometric view of the problem. However, first, it shouldbe noted that in fact the optimal solution to an LP problem will always lieon 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 pre-cious stone stretched out equally into many dimensions but more likely toresemble a very thin pencil stretched out into many dimensions. Hence, analgorithm which moves through the interior of a region must pay attention tothe fact that it does not leave the feasible region. Approaching the boundaryof the feasible region is penalized. The penalty is dynamically decreased in or-der to find a solution on the boundary. Interior-point methods will in generalreturn an approximately optimal solution which is strictly in the interior ofthe feasible region. Unlike the simplex algorithm no optimal basic solution isproduced. Thus, “purification” pivoting procedures from an interior point to avertex having an objective value no worse have been proposed and cross-overschemes to switch from interior-point algorithm to the simplex method havebeen developed [2].

B.1 Linear Programming 279

B.1.1 A Primal Simplex Algorithm

For an elementary treatment and examples for the primal simplex algorithmsee Kallrath & Wilson (1997, [55, Chap. 3 and Appendix]) and Kallrath (2002,[51]). Here, we just summarize the abstract ideas and consider the linearprogram (B.1). Vertex-based methods, the Simplex-algorithm is a special case,exploit the concept of basic variables collected into the basic vector xB . Thealgebraic platform is the concept of the basis B of A, i.e., a linearly independentcollection B = {Aj1 , ...,Ajm} of columns of A. Sometimes, just the set ofindices J = {j1, ..., jm} referring to the basic variables or linearly independentcolumns of A is referred to as the basis. The inverse B−1 gives a basic solutionx ∈ IRn which is given by

xT=(xT

B ,xTN

)where xB is a vector containing the basic variables computed according to

xB = B−1b

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 calleda 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 and3. the set {cTx : x ∈ S} is bounded from above,

then the set S defines a convex polyhedron P and each basic feasible solutioncorresponds to a vertex of P . Assumptions (2) and (3) ensure that the LP isneither infeasible nor unbounded, i.e., it has a finite optimum.

It can be shown that in order to find the optimal solution it is sufficientto 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 anLP is a combinatorial problem. An LP problem can have at most m positivevariables in the solution. At least n − m variables, these are the non-basicvariables, must take the value zero. McMullen (1970, [68]) has shown thatthere can exist at most2

f(n, m) :=(

n −⌊

m+12

⌋n − m

)+

(n −

⌊m+2

2

⌋n − m

)(B.2)

basic feasible solutions. Therefore, this purely combinatorial approach is notattractive 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 anedge-following algorithm that moves on the boundary of a polyhedron repre-senting the feasible set, i.e., from vertex to vertex of the polyhedron. In eachmove corresponding to a linear algebra step (technically, a Pivot step) theobjective function value is either improved or does not change. Algebraically,in each iteration, one column of the current basis is modified, according to thisexchange of basic variables, matrix A, and vectors b and c are transformed tomatrix A′, and vectors b′ and c′. Technically, this procedure is called a pivotor pivot operation or pivot step.

Now we can also understand degenerate cases in LP. A purely algebraicconcept is to call an LP problem degenerate if the optimal solution containsbasic variables with value zero. If we combine the algebraic and geometricaspects we can interpret a degenerate problem as one in which a certain vertex(usually we are considering the one leading to optimal objective function) hasdifferent algebraic representations, i.e., two vertices are co-incident with anedge of zero length between them.

Instead of keeping and computing the complete matrix A based on theprevious iteration, the revised simplex algorithm is based on the initial dataA,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 optimizationproblem itself.

Once the basis is known we can compute3 the inverse, B−1, of the basis,the values of the basic variables

xB = B−1b (B.3)

and the dual values, πT,πT := cT

BB−1 (B.4)

Note that πT is a row vector. Now we are in the position to compute thereduced costs, dj ,

dj = cj − πTAj (B.5)

for the non-basic variables [the reduced cost of the basic variables are all equalto zero d(xB) = 0]. Note that formula (B.5) computes the reduced costs byusing only the original4 data cj and Aj , and the current basis B. If any ofthe dj are positive, we can improve the objective function by increasing thecorresponding xj . So, the problem is not optimal. The choice of which positivedj to select is partly heuristic: conventionally, one chooses the largest dj butcommercial solvers are different from textbook implementations. They useso-called partial pricing and also devex pricing [36]. The term partial pricing

3 As further pointed out on page 282 the basis inverse is only rarely inverted ex-plicitly.

4 From now on Aj denotes the columns of the original matrix A corresponding tothe 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 tobecome the new basic variable. Other heuristics choose one of the non-basicvariables with positive sign randomly. And there must be a heuristic devicewhich tells the algorithm when to switch from partial to full pricing. Onlyfull pricing can do the optimality test. A sufficient optimality criterion for anoptimal solution of a maximization problem is

dj = cj − πTAj ≤ 0 , ∀j (B.6)

In a minimization problem the criterion is

dj = cj − πTAj ≥ 0 , ∀j

Note that we said a sufficient but not necessary condition. The reason is that inthe case of degeneracy several bases define the same basic feasible solution andsome can violate the criterion. If nondegenerate, alternative optimal solutionsexist (this case is called dual degeneracy) then necessarily the reduced cost forsome of the non-basic variables are equal to zero. If dj < 0 for all non-basicvariables in a maximization problem then the optimal solution is unique.

If we have not yet reached optimality we check whether the problem isunbounded. If the problem is bounded we use the minimum ratio rule toeliminate a basic variable. Both steps are actually performed simultaneously:the minimum ratio rule fails precisely when the incoming vector gives infiniteimprovement. The data needed for applying the minimum ratio rule are alsoderived directly from B−1

A′j = B−1Aj

After the minimum ratio rule has been applied we have the new basis, i.e., aset of indices or linearly independent columns.

What needs to be done is to get the current basis inverse B−1. There areseveral formulae to do this, but all of them are equivalent to computing thenew basis inverse although the inverse is never computed explicitly. To becorrect, the basis is only rarely inverted explicitly. Elementary row operationscarry over the existing basis inverse to the next iteration.6 However, every,say 100 iterations, the basis inverse is refreshed by inverting the basis matrix5 In this case we are solving a maximization problem.6 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 withthe current basis. The reason is that elementary row operations are equivalentto 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 basicvariables are multiplied by M and obviously give B·M = 1l, where 1l is the unitmatrix. 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 donot accumulate. In addition, in most practical applications A is very sparsewhereas after several iterations the transformed matrix A′ becomes denserso that, especially for large problems, the revised simplex algorithm usuallyneeds 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 implementationsof the revised simplex algorithms do not calculate B−1 explicitly. Insteadcommercial 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 initialbasis B0 (usually a unit matrix) and the so-called rather the eta-matrices oreta-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 verysimple structure (“1” on the diagonal, and just non-zeros in one column). Tostore the η-matrices it is sufficient to store the η-vectors u and v. Computingequations such as BxB = b yielding xB = B−1b are then solved by

xB = η−1k η−1

k−1 . . . η−11 b

The inverse of the η-matrices (under appropriate assumptions) can be com-puted very easily according to the formula

η−1 = 1l − 11 + vT u

uvT

Note that we need to store all ηi-vectors. As the iterations proceed, the amountof storage for the factors increases. So a re-inversion of the basis occurs notonly for reasons of numerical accuracy but also due to a “storage versus com-putation” trade off. Readers more interested in the details of the linear algebracomputations, LU factorizations, η-vectors and conserving sparsity may ben-efit 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 primalproblem (the original problem). When the dual problem is solved, the optimalvalues of its variables (and slacks) correspond to the values of the reduced costsand shadow prices of the primal problem. Thus the operation of the simplexalgorithm 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 columnsrepresent the product of all matrices Mk which then is the basis inverse of thecurrent matrix.

B.1 Linear Programming 283

values of the dual problem which provides current values of the reduced costson variables. Thus the simplex algorithm is an algorithm which is implicitlymoving between the primal and dual problems, updating solution and reducedcost values respectively.

Understanding the concept of dual values and shadow prices we can alsogive another interpretation of the reduced costs in terms of shadow prices.While the dual values, or Lagrangian multipliers, give the cost for activeconstraints, the reduced cost of a non-basic variable is the shadow price formoving 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 thatbound. That also explains why basic variables have zero reduced costs: innon-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 feasiblebasis and iterates it to optimality. We have not yet said how we could providean initial solution. There are several methods, but the best known are bigM methods and phase I and phase II approaches. Less familiar are heuristicmethods usually referred to as crash methods. To discuss the first two methodsconsider the LP problem with n variables and m constraints in standard form[here it is advantageous to consider a minimization problem]

min cTx

subject toAx = b , x ≥ 0

By multiplying the equations Ax = b by −1 where necessary we can assumethat b ≥ 0. That enables us to introduce non-negative violation variables v =(v1, . . . , vm) and to modify the original problem to

min cTx + M

m∑j=1

vj

subject toAx + v = b , x ≥ 0 , v ≥ 0

M is a “big” number, say 105, but it is very problem dependent as to whatbig means. The idea of the big-M method is as follows. It is easy to find aninitial 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 inwhich 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 variablesare zero. If not, one increases M . Ultimately, M must become very large if theproblem appears infeasible and one is essentially doing the two-phase methoddescribed in the next paragraph.

There is an alternative approach which does not depend on a scaling pa-rameter such as M : the two-phase method. The idea is the same but it usesa different objective function, namely

minm∑

j=1

vj

i.e., just the sum of the violation variables. Non-zero objective function valuesprove that the original problem is infeasible.

Why do we have two methods? Would not one be enough? If you inspectboth methods carefully you will notice that they have different advantages ordisadvantages. If one takes the limit M → ∞ the big M methods becomesthe two-phase method. Using the big M method the software designer has toensure and to worry that M is big enough. Often M is adapted dynamicallywhen trying to find an initial solution. It is just good enough to find a solutionwith v = 0. Keeping the original variables in the objective function mayprovide an initial solution which is closer to the optimal solution. In practicethe number of artificial variables is kept to a minimum. If a certain row alreadyhas 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 solu-tion very close to the optimal solution.

Initial feasible LP solutions can also be computed by re-using a basis savedfrom a previous related run. This approach produces good initial feasiblesolutions quickly if the model data have only changed a bit, or if only a fewvariables or constraints have been added.

New methods for computing initial solutions or good starting candidatesare hybrid methods. Such methods, combining the simplex algorithm andinterior-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 constraintsin standard form [it is not really important whether we consider a minimiza-tion or maximization problem]

min cTx

subject to

B.1 Linear Programming 285

Ax = b , x ≥ 0

In many large real-world problems it is advantageous to exploit another struc-ture which occurs frequently, upper and lower bounds on the variables. Thisis formulated as

min cTx′

subject toAx′ = b′ , l′≤ x′≤ u′

Since we always can perform a variable substitution x = x′−l′ and observingthat the new variables have the bounds 0 ≤ x ≤ u′−l′ = u, it is sufficient toconsider the problem

min cTx

subject toAx = b , 0 ≤ x ≤ u

Of course we could reformulate this problem by introducing some slack vari-ables s ≥ 0 in the standard way

min cTx

subject toAx = b

x + s = u , x ≥ 0 , s ≥ 0

Since in many large real-world problems we have n � m (there are oftenbetween three and ten times as many variables as rows) a straightforwardapplication 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 amodified 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, thatare at their lower bound of zero (the concept we are familiar with) and thosexj , j ∈ Ju, that are at their upper bound (the new concept). With the newconcept no explicit slack variables are necessary. Let us now try to see how thesimplex algorithm works when performing a basis exchange. Pricing now tellsus that a current basis is not optimal if one of these two situations occurs:

1) there exist indices j ∈ J0 with dj < 02) there exist indices j ∈ Ju with dj > 0

In case 1) we could increase a nonbasic variable, in case 2) we could decreaseit. Both cases would lead to a decreased value of the objective function. A newconsideration, when increasing or decreasing a nonbasic variable, is that weneed 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 variablesbecomes 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 theirupper bounds.

Case 1) leads to two sub-cases:

1a) the nonbasic variable xj can be increased to its upper bound while nobasic 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 movesthe index j into the new set Ju. Reaching zero in 1b) is handled as in thestandard simplex algorithm: variable xj enters the basis and the index of thevariable leaving the basis is added to the new set J0. When an upper bound ishit in 1b) the variable xj enters the basis and the index of the variable leavingthe basis is added to the new set Ju.

Case 2) can be analyzed by considering the slack sj = uj − xj . If thenonbasic 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 nonbasicvariable xj considered in 1a) and 1b) and thus the argument is the same.

The linear algebra involved in the iteration is similar to the standardsimplex, and essentially no extra computations are required. Readers moreinterested in the subject are referred to Padberg (1996, [76, pp.75-80]).

We have now seen why exploiting bounds on variables explicitly leadsto better, i.e., faster numerical, performance: there is a little more testingand logic required in the algorithm but no additional computations. This hassignificant consequences for the B&B algorithm which adds only new boundsto the existing problem.

Note that since the bounds are treated explicitly and not as constraints noshadow prices are available on these “constraints”. Instead, the shadow pricescan be derived from the reduced costs of the nonbasic variables fixed at theirupper bounds.

B.1.4 Dual Simplex Algorithm

The (primal) simplex algorithm concentrates on improving the objective func-tion value of an existing basic feasible solution. In contrast, there is also thedual simplex algorithm which solves an LP problem by taking a dual optimalbasic solution which is optimal in the sense that the reduced costs computedaccording to (B.5) have the correct sign, but are not basic feasible. The dualsimplex algorithm tries to achieve feasibility of the solution while retaining itsoptimal 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, thedual algorithm eliminates first an existing basic variable, and then selects anew basic variable.

B.1 Linear Programming 287

The dual simplex algorithm is often used within the B&B algorithm. Whena branch is made the subproblem just differs from the original problem inhaving a different bound on the branching variable; remember from SectionB.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 consideredoptimal but not feasible. In most cases, the dual simplex algorithm restoresfeasibility quickly to the solution, say, within a few iterations. By using thedual simplex algorithm we are able to take advantage of the earlier work doneby 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 besolved 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 espe-cially for large, sparse problems or those, which are highly degenerate. Hereconsiderable computing-time gains can be achieved. Such methods have al-ready 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 satis-fying x > 0, towards an optimal solution without touching the boundary ofthe 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 usconsider the logarithmic barrier method in detail when applied to the primal-dual pair

primal problem ←→ dual problem

min cTx max bTys.t. Ax = b s.t. ATy + w = c

x ≥ 0 w ≥ 0

(B.7)

with free, dual variable y, the dual slack variable w and the solution vectorsx∗, y∗ and w∗. A feasible point x of the primal problem is called strictlyfeasible if x > 0, a feasible point w of the dual problem is called strictlyfeasible if w > 0. The primal problem is mapped to a sequence of nonlinearprogramming problems

P (k) : min

⎧⎨⎩cTx − µ

n∑j=1

ln xj

∣∣∣∣Ax = bx > 0 , µ = µ(k)

⎫⎬⎭

with homotopy parameter µ where we replaced the non-negativity constrainton the variables with the logarithmic penalty term; instead of using xj in thepenalty term we could have considered the inequality Aix ≤ bi through termsof the form ln(bi − Aix).

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 objectivefunction, increases to infinity. By suitable reduction of the parameter µ > 0,the weight of the penalty term, which gives the name logarithmic barrierproblem to this methods, is successively reduced and the sequence of pointsobtained by solving the perturbed problems, converges to the optimal solutionof the original problem. So, through the choice of µ(k) a sequence P (k) ofminimization problems is constructed, where the relation

limk→∞

µ(k)n∑

j=1

ln xj = 0

has to be valid, viz.

limk→∞

argmin(P (k)) = argmin(LP ) = x∗

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-pointmethods are special homotopy algorithms for the solution of general non-linear 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 localoptima in NLP problems, we get a system of nonlinear equations which can besolved with the Newton-Raphson algorithm as shown below. The good news isthat the problems P (k) or systems of nonlinear equations they produce neednot to be solved exactly in practice, but one is satisfied with the solutionachieved after one single iteration in the Newton-Raphson algorithm.

So far we have considered the primal problem. To get to the dual and finallythe primal-dual7 version of interior-point solvers used in commercial solvers,the Karush-Kuhn-Tucker (KKT) conditions are derived from the Lagrangianfunction (a common concept in NLP)

L = L(x,y) = cTx − µn∑

j=1

ln xj − yT(Ax − b) (B.8)

Note that the constraints are multiplied by the dual value (Lagrange multipli-ers), yT, and then are added to the original primal objective function. Detailsare provided, for instance, in [55, Chap. 3 and Appendix].

By definition interior-point methods operate within the interior of thefeasible region and thus need strictly positive initial guesses for the vectorsx and w. How can such feasible points be obtained? This is a very difficult7 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 sincewe do not want to use the simplex algorithm. Since interior-point methodsare path-following methods one would like to have an initial point as close aspossible to the central path and to be as close to primal and dual feasibilityas possible. So called “primal-dual infeasible-interior-point methods” provedto be successful. These methods start with initial points x(0) and w(0) but donot require that primal and dual feasibility is satisfied. This is quite typical fornonlinear problems which use Newton type algorithms. Feasibility is attainedduring the process as optimality is approached8. Therefore, a primal and dualfeasibility 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 solutionof an LP but no optimal basic and non-basic partition of the variables. Sincethe optimal solution produced by the interior-point method is strictly in theinterior of the feasible solution there are many more variables not fixed attheir bounds than we would expect in a simplex solution. The concept ofbasic solutions is, however, very important for sensitivity analyses and theuse of LP problems as subproblems in B&B algorithms. The availability of abasis facilitates warm-starts.

Commercial implementations of interior-point methods use cross-overtechniques, i.e., at some time controlled by a termination criterion the al-gorithm switches from the interior-point method to the simplex algorithm.Crossing-over starts with the basis identification providing a good feasibleinitial guess for the simplex algorithm to proceed. The simplex algorithmimproves this guess quickly and produces an optimal basic solution.

At the moment the best simplex algorithms and the best interior-pointmethods are comparable. The simplex algorithm needs many iterations, butthese are very fast. The number of the iterations grows approximately linearlywith the number of constraints and logarithmically in the number of variables.Interior-point methods usually need about 20 to 50 iterations; this numbergrows weakly with the problem size. Every iteration requires the solution ofan n × n system of nonlinear equations which is quite costly. This systemis linearized. Thus the central computing consumption for a problem with nvariables is the solution of a n × n linear equation system. That is why it isessential for the success of the IPM, that this system matrix is sparse.

Although problem dependence plays an essential role for the valuation ofthe efficiency of simplex algorithms and IPMs, the IPMs seem to have advan-tages for large, sparse problems. Especially for big systems hybrid algorithmsseem to be very efficient. In the first phase these determine a nearly optimalsolution with the help of an IPM, viz. determine a solution near the polyhe-8 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) andpossibly 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 tocreate a basis. Finally, the simplex algorithm uses this basis as an initial guessand finally iterates to the optimal basis. Further aspects of using the simplexalgorithm 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 vari-ants of the Branch and Bound (B&B) algorithm originally developed by Landand Doig (1960, [64]) to solve mixed integer linear programming problems.The B&B idea or implicit enumeration characterizes a wide class of algorithmswhich can be applied to discrete optimization in general. For an elementarytreatment see Kallrath & Wilson (1997, [55, Chap. 3 and Appendix]) andKallrath (2002, [51]). Here, we provide an orientation about this method andits relevant computational steps.

The branch in B&B hints at the partitioning process used to produceinteger feasible solutions or to prove the optimality of a solution. Lower andupper bounds are used during this process to avoid an exhaustive search inthe solution space. The algorithm terminates when the differences betweenupper 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 —thatis that LP problem obtained when relaxing all integer variables to contin-uous ones— establishes the first node. The node selection is obvious in thefirst step (just take the LP-relaxation), but later on it is based on variousheuristics. A B&B algorithm of Dakin (1965, [13]) with LP-relaxations usesthree pruning criteria: infeasibility, optimality and value dominance relation.In a maximization problem the integer solutions found lead to an increasingsequence of lower bounds, zIP, while the LP problems in the tree decrease theupper bound, zLP. Note that α denotes an addcut which causes the algorithmto 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 algorithmis done by variable dichotomy: for a fractional y∗

j two child nodes are createdwith the additional constraint yj ≤ [y∗

j ] resp. yj ≥ [y∗j ] + 1. Other possibili-

ties for dividing the search space are, for instance, generalized upper bounddichotomy or enumeration of all possible values, if the domain of a variableis finite ([8], [73]). The advantage of variable dichotomy is that only simplelower and upper bounds are added to the problem. In Section B.1.3 we haveshown 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 anode 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 con-sidered (backtracking). In linear programming only lower and upper boundsare 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 solutionsare found deep in the tree. Nevertheless, in some cases the use of the oppositestrategy, breadth-first search, may be advantageous.

Another important point is the selection of the branching variable. A com-mon way of choosing a branching variable is by user-specified priorities, be-cause no robust general strategy is known. Degradations or penalties may alsobe used to choose the branching variables, both methods estimate or calcu-late the increase of the objective function value if a variable is required to beintegral, especially penalties are costly to compute in relation to the gainedinformation so that they are used quite rarely [73].

The B&B algorithm terminates after a finite number of steps. Termina-tion occurs when the lower and the upper bound cross or when the node listbecomes empty. In that case the result is either the optimal integer feasiblesolution or the message that the problem does not have any integer feasiblesolution. In practice, it happens very often that the user does not want towait until the node list becomes empty but wants to stop after one, or sev-eral integer solutions have been found. If an integer feasible solution has beenfound the upper and lower bounds mentioned above may be used to estimatethe quality of the solution. Let us see how that works: during the B&B for amaximization problem we know that

zLP ≥ z∗ ≥ zIP

where z∗ is the (unknown) value of the best integer solution, zIP (possibly−∞) is the value of the best integer solution found so far in the search andzLP = maxi{zLP

i } where zLPi 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 amaximization problem the upper bound, zU, is provided by the LP relaxationszLP while the lower bound, zL, corresponds to the best integer solution zIP

found. So we have the bounds

zL ≤ z∗ ≤ zU (B.1)

on the objective function value z∗ of the (unknown) optimal solution. In amaximization problem the difference zU − z∗ is called the integrality gap. Ifthe search is terminated before z∗ has been computed, the difference zU − zL

is used as an upper bound on the integrality gap.Assuming that both zL and zU are positive the quality of our solution can

also be expressed by the relative integrality gap

p := 100zU − zL

zL= 100

zLP − zIP

zIP(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 zL increases if we allow the algorithm to seek forfurther integer feasible solutions the upper bound zU decreases very slowlyduring the computations. The upper bound can be decreased faster by usingthe Branch&Cut algorithm embedded by commercial MILP solvers.

The Branch&Bound algorithm terminates if zLP − zIP ≤ ∆, where ∆ issome tolerance. If ∆ = 0, we haven proven optimality. If ∆ > 0, we have founda solution which at most deviates by ∆ from the maximum z∗. So it can beseen that a criterion for node selection in B&B is to reduce the integrality gapzLP − zIP. One way to do this is to select a node which has a good chance ofyielding a new integer feasible solution better than the current zIP. Anotherway is to branch on the node having the largest zLP

i on the grounds thata descendant of this node will certainly have no higher a value of zLP

i , andprobably will have a lower value, in which case zLP will be smaller.

The interpretation of the percentage gap introduced above becomes diffi-cult if a model includes penalty terms containing weighting coefficients with-out any economic interpretation. Sometimes such penalty terms are used toreduce infeasibilties. To illustrate the problem let us consider the followingproblem with an objective function containing two penalty terms

min P1r1 + P2r2 (B.3)

where r1 and r2 are relaxation variables with the following meaning. The firstone, r1, measures the deviation from demand. The second one, r2, quantifiesthe deviation from a due time. A valuable and expensive material is rarelydemanded in fractional quantities, D, by important customers, but can beproduced only in kilograms; the amount produced is denoted by the integervariable π. Deviations from demand are not avoidable. It is allowed to produceless 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 soon. The relaxation or deviation variable r1 is related to π by the disjunctiveset9 of constraints

π + r1 = D ∨ π − r1 = D . (B.4)

The demand is subject to a due time, TD. The time at which the productionstarts is denoted by the variable tS.

tS + TP ≤ TD + r2 . (B.5)

Let us assume in this example that the processing time, TP, is one hour, i.e.,TP = 7. Further we assume that TD = 16 hours, i.e., the production shouldbe finished at 4pm. The personnel at the production floor tells us that the9 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 minimalvalue for r2 is r2 = 1 as tS ≥ 10. If we use an example value of D = 1.4 kg weobviously 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 := 100zU − zL

zU= 100

zIP − zLP

zIP. (B.6)

The LP-relaxation gives π = 1.4, r1 = 0 and thus zLP = P2. If in the B&Balgorithm the node π ≥ 2 is evaluated first, the associated gap is

pπ≥2 = 100(0.6P1 + P2) − (0 + P2)

0.6P1 + P2= 100

0.6P1

0.6P1 + P2. (B.7)

Note that we have 0 ≤ pπ≥2 ≤ 100. If we increase P2 the gap pπ≥2 approacheszero. Thus, the gap depends significantly on scaling. The situation we arefacing here is, due to the appearance of r2 in (B.5), similar to adding a constantto the objective function. The lesson to be learned is that one needs to payattention to such issues. The penalty approach can be avoided completely byexploiting 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 theyare classified as NP hard and in many cases NP complete. In complexitytheory these are measures of how difficult it is to solve a certain class of op-timization problems. It is important to treat problems with such attributesrespectfully. 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 asBranch&Bound works well for a given problem instance, one might experiencedifficulties if the problem size changes by even only 20%.

It is this complexity why we find that all commercial packages use pre-processing and presolving techniques to tighten the model at the root node orwithin the B&B algorithm. This pushes the limit of which problems can besolved continuously towards larger and larger problems.

Preprocessing methods introduce model changes to speed up the algo-rithms. The modifications are made, of course, in such a way that the feasibleregion of the MILP is not changed. They apply to both pure LP problemsand 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 preprocessingtechniques is given by Savelsbergh (1994, [83]). The reader is also referred tothe comprehensive survey of presolve10 methods by Andersen and Andersen10 The terms preprocessing and presolve are often used synonymously. Sometimes

the term presolve is used for those procedures which try to reduce the problem sizeand to discover whether the problem is unbounded or infeasible. Preprocessinginvolves the presolving phase but includes all other techniques which try, forinstance, to improve the MILP formulation.

294 B Mathematical Foundations of Optimization

(1995, [1]). Some common preprocessing methods are: presolve (arithmetictests on constraints and variables, bound tightening), disaggregation of con-straints, coefficient reduction, and clique and cover detection. Many of thesemethods are implemented in commercial software but vendors are usually notvery 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 obvi-ous basis is identified. Being aware of these methods may greatly improvethe user’s model building leading to more efficient models or reduce the user’sefforts if it is known that the software already does certain presolve operations.

Commercial solvers, nowadays, also to apply heuristics to generate integerfeasible points from nodes still containing fractional values. These issues (pre-processing, presolve, constructive heuristics inside the B&B scheme) becomemore and more important in commercial MILP solver. They are the greatsecrets of the companies developing MILP solvers.

B.3 Multicriteria Optimization and Goal Programming

Here we provide examples illustrating two solution techniques for goal pro-gramming: the pre-emptive (lexicographic) and the Archimedian approach.

In pre-emptive goal programming goals are ordered according to impor-tance and priorities . The goals at a certain priority level are considered to beinfinitely11 more important than the goals in the next lower level. Pre-emptivegoal programming is recommended if there is a ranking between incommen-surate objectives available.

In the Archimedian approach weights or penalties are applied for notachieving 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 ofconstraints 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 percentageto give targets for this year.

We now adjoin four non-negative variables d1, d2, d3, d4 ≥ 0 as well as twonew goal attainment constraints to our model11 It would also be possible to define weights which express how much the ith ob-

jective is more important than the (i + 1)th objective.

B.3 Multicriteria Optimization and Goal Programming 295

2x +3y +d1 − d2 = P goal 1y +8z +d3 − d4 = C goal 2

The objective function is to minimize deviation from target

min d1 + d2 + d3 + d4

Any objective function attempted previously in the formulation would haveto be expressed as a goal constraint. The problem is now an ordinary LPproblem. (IP problems may be modified similarly.) Note the use of two d’sin each constraint (with opposite signs) and the presence of all d’s in theobjective function (with the same sign). Note also how the d’s perform a roleto represent a free variable, namely the deviation from target. The techniquefor two goals can be extended to handle three or more goals.

One feature of goal programming is that every goal is treated as beingequally important, and consequently an excess of 100 units in one goal wouldbe compensated by a shortfall of 100 in another, or would be equivalent toexcesses of 10 units in each of 10 goals. Neither of these sets of circumstancesmight 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 inreturn 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 mini-mize the violation of the constraints. These are met when the constraints aresatisfied. In the pre-emptive case as many goals as possible are met in pri-ority order. (It should be remembered that someone has to subjectively setweights to achieve this.) In the Archimedian case a weighted sum of penaltiesis 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 calcu-lated from the optimal value for the objective function row (by percentage orabsolute deviation). In the Archimedian case a multi-objective LP problem isobtained, in which a weighted sum of the objective functions is minimized.

Let us illustrate how lexicographic goal programming works by consideringthe following example with two variables x and y subject to the constraint42x + 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 10goal 2 (OBJ3): −3x + 15y − 48 min A 4goal 3 (OBJ2): 1.5x + 21y − 3.8 max P 20

.

The multi-criteria LP or MILP problem is converted to a sequence of LP orMILP problems. The basic idea is to work down the list of goals accordingto the priority list given. Thus we start by maximizing the LP w.r.t. the firstgoal. This gives us the objective function value z∗1 . Using this value z∗1 enablesus to convert goal 1 into the constraint

5x + 2y − 20 ≥ Z1 = z∗1 − 10100

z∗1 . (B.1)

Note how we have constructed the target Z1 for this goal (P indicates that wework percentage wise). In the example we have three goals with the optimiza-tion sense {max, min, max}. Two times we apply a percentage wise relaxation,one time absolute. Solving the new problem (B.1) we get:

z∗1 = −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:

z∗2 = 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 con-straint (B.3) (here we allow a deviation of 4) and maximize according togoal 3. Finally, we get z∗3 = 141.943995 and the solution x = 0.238062 andy = 6.923186. To be complete, we could also convert the third goal into aconstraint giving

1.5x + 21y − 3.8 ≥ 141.943995 − 0.2 · 141.943995 = 113.555196

Note that lexicographic goal programming based on objective functions pro-vides a useful techniques to tackle multi-criteria optimization problems. How-ever, we have to keep in mind that the sequence of the goals influences thesolution strongly. Therefore, the absolute or percentage deviations have to bechosen with care.

In addition to the lexicographic goal programming variant based on objec-tive function we could also use lexicographic ordered constraints. The goalsare to minimize the violation of constraints. The overall goal is to minimize theviolation of constraints. In the ideals case all constraints are fulfilled. Other-wise, we try to fulfill the constraints ordered by priorities as good as possible.Unfortunately, this also leads to some sorts of weights. We thus summarizethat the absolute or percentage-wise deviations used in lexicographic goalprogramming 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 herealso for the purpose of subsequent reference. Within this glossary all termswritten in boldface are explained in the glossary.

Algorithm: Probably derived from the name of the Arabian mathemati-cian al-Hwarizmı, a systematic procedure for solving a certain problem. Inmathematics and computer science it is required that this procedure can bedescribed by a finite number of unique, deterministic steps. At each step ofthe algorithm it is uniquely determined by the previous steps how to proceed.ATP: Available to promise; the business process describing the confirmationof sales orders. In software systems usually a set of rules exist that allow thesales representative to respond to customer inquiries with a delivery date. De-pending on the implementation and the software vendor, several variants exist:ATP looks at existing inventories and (planned) production orders, multi-levelATP considers rough-cut capacities and involves BOM explosion, and CTP(capable to promise) includes feasible scheduling of new production orders forfulfilling the new customer demand.Basic variables: Those variables in optimization problems whose values, innon-degenerate cases, are away from their bounds and are uniquely deter-mined from a system of equations.Basis (Basic feasible solution): In an LP problem with constraints Ax = band x ≥ 0 the set of m linearly independent columns of the m x n systemmatrix A of an LP problem with m constraints and n variables forming aregular matrix B. The vector xB = B−1b is called a basic solution. xB iscalled a basic feasible solution if xB ≥ 0.Bill of Material (BOM): A list of components that are used in producing amaterial. 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 onlyone variable and a constant which fixes the variable to that value, or servesas a lower or upper limit.Branch & Bound: An implicit enumeration algorithm for solving com-binatorial problems. A general Branch & Bound algorithm for MILP prob-lems operates by solving an LP relaxation of the original problem and thenperforming a systematic search for an optimal solution among sub-problemsformed by branching on a variable which is not currently at an integer valueto form a sub-problem, resolving the sub-problems in a similar manner.Branch & Cut: An algorithm for solving mixed integer linear programmingproblems which operates by solving a linear program which is a relaxation ofthe original problem and then performing a systematic search for an optimalsolution by adjoining to the relaxation a series of valid constraints (cuts) whichmust be satisfied by the integer aspects of the problem to the relaxation, orto sub-problems generated from the relaxation, and resolving the problem orsub-problem in a similar manner.Constraint: A relationship that limits implicitly or explicitly the values ofthe variables in a model. Usually, constraints are formulated as inequalitiesor equations representing conditions imposed on a problem, but other typesof relations exist, e.g., set membership relations.Continuous relaxation: An optimization problem where the requirementsthat certain variables take integer or discrete values have been removed.Convex region: A region in multi-dimensional space where a line segmentjoining any two points lying in the region remains completely in the space.CTM: Capable-to-match; a rules-based constraint propagation planning al-gorithm in SAP APO taking into account production capacity, transportationrelations, quotas, and priorities for computing a feasible production plan.CTP: see ATP.Cutting-planes: Additional valid inequalities that are added to MILP prob-lems to improve their LP relaxation when all variables are treated as contin-uous 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 problemthe difference between the primal and dual objective function values. In LPthe duality gap of the optimal solution is zero.Dual problem: An optimization problem closely related to the original prob-lem which is called the primal problem. The dual of an LP problem is obtainedby exchanging the objective function and the right-hand side constraint vectorand transposing the constraint matrix.Dual values: A synonym for shadow prices. The dual values are the dualvariables, i.e., the variables in the dual optimization problem.ERP: Enterprise Resource Planning systems are management informationsystems that integrate and automate many of the business practices associatedwith the operations or production aspects of a company.

C Glossary 299

Feasible point (feasible problem): A point (or vector) to an optimizationproblem that satisfies all constraints of the problem. (A problem for which atleast one feasible point exists.)Global Optimum: A feasible point, x∗, to an optimization problem thatgives the optimal value of the objective function f(x). In a minimizationproblem, f(x) ≥ f(x∗) holds for all other points, x �= x∗, of the feasible region.Goal programming: A method of formulating a multi-objective optimiza-tion problem by expressing each objective as a goal or target with a hypo-thetical attainment level, modeled as a constraint, and using as the objectivefunction an expression which will minimize deviation from goals.Heuristic solution: A feasible point of an optimization problem which isnot necessarily optimal and has been found by a constructive technique whichcould not guarantee the optimality of the solution.Improvement method: A method able to generate and improve feasiblepoints of an optimization problem with respect to some objective function.Improvement methods cannot prove optimality, do not provide safe boundsand 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 thecontinuous relaxation of an integer, mixed integer or discrete programmingproblem and its optimal objective function value.InfoCube: An InfoCube is an instance of a multi-dimensional data modelwithin the SAP Business Information Warehouse (SAP BW, which is implic-itly part of SAP APO). Technically, an InfoCube consists of a number ofrelational tables arranged according to the star scheme: a large fact table inthe center is surrounded by several dimension tables.Kuhn-Tucker conditions: generalization of the necessary and sufficient con-ditions for steady points in nonlinear optimization problems involving equal-ities and inequalities.liveCache: a memory-resident relational database in SAP APO optimizedfor fast data-access.Linear combination: A linear combination of vectors v1, ...,vn is the vector∑

i aivi with real valued numbers ai. The trivial linear combination is gener-ated by multiplying all vectors by zero and then adding them up, i.e., ai = 0for 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) = cTx + α for some fixedscalar α.Linear independence: A set of vectors is linearly independent if there existsno non-trivial linear combination representing the zero-vector. The triviallinear combination is the only linear combination which generates the zerovector.Linear Programming (LP): A technique to solve optimization problemscontaining only continuous variables appearing in linear constraints and in alinear objective function.

300 C Glossary

Local Optimum: A feasible point, x∗, to an optimization problem that givesthe optimal value of the objective function in the neighborhood of that pointx∗. In a minimization problem, we have for all other points of that neighbor-hood the relation f(x) ≥ f(x∗). Contrast with Global Optimum.Matrix: A rectangular array of elements such as symbols or numbers arrangedin rows and columns. A matrix may have associated with it operations suchas addition, subtraction or multiplication, if these are valid for the matrixelements.Mixed Integer Linear Programming (MILP): An extension to LinearProgramming which allows the user to restrict variables to binary, integer,semi-continuous or partial-integer values.Mixed Integer Nonlinear Programming (MINLP): A technique to solveoptimization problems which allow some of the variables to take on binary,integer, semi-continuous or partial-integer values, and allow nonlinear con-straints and objective functions.Model (optimization model): A mathematical representation of a real-world problem using variables, constraints, objective functions and othermathematical objects.Modeling system: In the context of mathematical optimization a softwaresystem for formulating an optimization problem. The optimization problemcan be formulated in an algebraic language, or can be represented by a visualmodel. The modeling system enables the user to bring together the structureof the problem and the data, to use various solvers, to trace the values ofvariables, constraints, shadow prices and infeasibilities, and to display Branch-and-Bound trees.MRP: Material Requirements Planning; a software-based production plan-ning and inventory control system used to manage manufacturing processes.MRP II: Manufacturing Resource Planning; a method for the effective plan-ning of all resources of a manufacturing company. Ideally, it addresses oper-ational planning in units, financial planning in dollars, and has a simulationcapability to answer “what-if” questions. Defined by APICS,the EducationalSociety for Resource Management (http://www.apics.org/).Network: A representation of a problem as a series of points (nodes), someof which are then connected by lines or curves (arcs), which may or may nothave a direction characteristic and a capacity characteristic. The network isusually represented by a graph.Non-basic variables: Those variables in optimization problems which areindependently fixed to one of their bounds.Nonlinear function: Any function f(x) of a vector x which has a non-constant gradient ∇f(x).Nonlinear Programming (NLP): Optimization problems containing onlycontinuous variables and nonlinear constraints and objective functions.NP completeness: Characterization of how difficult it is to solve a certainclass of optimization problems. The computational requirements increase ex-ponentially with some measure of the problem size.

C Glossary 301

Objective (objective function): An expression in an optimization problemthat has to be maximized or minimized.Optimization: The process of finding the best solution, according to somecriterion, to an algebraic representation of a problem.Optimization algorithm: An algorithm which computes feasible pointsof optimization problems and proves that the best feasible point is globallyoptimal. For mixed integer problems, it is expected to compute feasible pointsand, for a minimization problem, a safe lower bound. The simplex algorithmand the Branch&Bound method are examples for optimization algorithmsin MILP.Optimum (optimal solution): A feasible point of an optimization prob-lem that cannot be improved on, in terms of the objective function, withoutviolating the constraints of the problem.Pivot: An element in a matrix used to divide a set of other elements. Inthe context of solving systems of linear equations the pivot element is chosenwith respect to numerical stability. In linear programming the pivot elementis selected by pricing and the minimum ratio rule. In that context, the lin-ear algebra step calculating, although not explicitly, the new basis inverse, issometimes called the pivoting step.Planning (production planning): Determines which amount of a productshould be produced on which facility in a certain time period or time bucket.Planning uses usually discrete-time formulations and covers a time horizon ofseveral months or quarters. It contains less operational details than schedul-ing and is mostly based on material balance relations.Post-optimality (Post-optimal analysis): Investigation of the effect onthe 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 BOMinformation as well as the operations, activities and resources that are neededto make a certain product.Presolve: An algorithm for use on the specification of an optimization prob-lem prior to its solution, whereby redundant features are removed and validadditional features may be added.Ranging: Investigation of the limits of changes in coefficients in an optimiza-tion problem which will not fundamentally affect the optimal solution.Reduced cost: The price (or the gain) for moving a non-basic variable awayfrom the bound it is fixed to.Relaxation: An optimization problem created from another where some ofthe constraints have been removed or weakened, or where domain restrictionsof 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 givenset facilities. Scheduling requires much higher time resolution but is usuallyapplied to only shorter time horizons than planning.

302 C Glossary

SCM: There are numerous definitions of supply chain management. In thisbook we use “coordinating material, information and financial flows in a com-pany’s value chain including business partners such as suppliers, contract man-ufacturers, distributors, and customers”.Sensitivity analysis: The analysis of how an optimal solution of an op-timization problem changes if some input data of the problem are slightlychanged.Shadow price: The marginal change to the objective function value of anoptimal solution of an optimization problem caused by making a marginalchange to the right-hand side value of a constraint of the problem. Shadowprices are also termed dual values.Simplex algorithm: Algorithm for solving LP problems that investigatesvertices of polyhedra.Slack variables: Variables with positive unit coefficients inserted into theleft-hand side of ≤ inequalities to convert the inequalities into equalities.SNP: Supply network planning; the component of SAP APO focusing onmid-term planning on a somewhat aggregated level of detail regarding man-ufacturing processes. Planning takes place on time slices/buckets.Stochastic optimization: A technique to solve optimization problems inwhich some of the input data are random or subject to fluctuations.Successive Linear Programming (SLP): Algorithm for solving NLP prob-lems containing a modest number of nonlinear terms in constraints and ob-jective function.Surplus variables: Variables with negative unit coefficients inserted into theleft-hand side of ≥ inequalities to convert the inequalities into equalities.Unbounded problem: A problem in which no optimal solution exists (theobjective function tends to increase to plus infinity or to decrease to minusinfinity) because the feasible region is not bounded.Variable: An algebraic object used to represent a decision or other varyingquantity. Variables are also called “unknowns” or just “columns”.Vector: A single-row or single-column matrix.

List of Figures

1.1 The five management processes in the SCOR model . . . . . . . . . . 41.2 The supply chain planning matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 SAP covering the supply chain planning matrix . . . . . . . . . . . . . . 101.4 Schematic SAP APO optimizer architecture . . . . . . . . . . . . . . . . . 121.5 A sketch of the CTM Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 The structure of the simple supply chain example . . . . . . . . . . . . 433.2 Example supply chain structure displayed in SAP APO . . . . . . . 443.3 Model creation in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4 Planning version creation in SAP APO. . . . . . . . . . . . . . . . . . . . . . 533.5 SAP APO location maintenance screen . . . . . . . . . . . . . . . . . . . . . . 543.6 SAP APO location product maintenance entry screen . . . . . . . . . 563.7 SAP APO location product master, procurement view . . . . . . . . 563.8 Maintaining version-dependent costs for a location product . . . . 573.9 Maintaining version-dependent delivery penalties . . . . . . . . . . . . . 583.10 Resource maintenance entry screen in SAP APO . . . . . . . . . . . . . 593.11 Resource master data in SAP APO . . . . . . . . . . . . . . . . . . . . . . . . . 603.12 Quantity/rate definitions for a bucket resource . . . . . . . . . . . . . . . 613.13 Capacity variants of a bucket resource . . . . . . . . . . . . . . . . . . . . . . 623.14 Schematic structure of a PPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.15 The entry screen for maintaining PPMs . . . . . . . . . . . . . . . . . . . . . 633.16 The PPM maintenance screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.17 Operations and activities view in the PPM . . . . . . . . . . . . . . . . . . 643.18 The components view of a PPM activity . . . . . . . . . . . . . . . . . . . . 653.19 The mode view of a PPM activity . . . . . . . . . . . . . . . . . . . . . . . . . . 653.20 The resource view of a PPM mode . . . . . . . . . . . . . . . . . . . . . . . . . 663.21 The product plan assignment table in PPM maintenance . . . . . . 673.22 Activating the SNP PPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.23 The Supply Chain Engineer entry screen . . . . . . . . . . . . . . . . . . . . 703.24 An empty work area in the Supply Chain Engineer . . . . . . . . . . . 713.25 Adding objects to the model in the Supply Chain Engineer . . . . 713.26 Master data objects in the supply chain model . . . . . . . . . . . . . . . 713.27 Adding objects to a Supply Chain Engineer work area . . . . . . . . 72

304 List of Figures

3.28 The transportation lane entry screen in SAP APO . . . . . . . . . . . . 733.29 Defining product-specific transportation lanes in SAP APO . . . . 733.30 Defining means of transport in SAP APO . . . . . . . . . . . . . . . . . . . 743.31 Defining product specific means of transport in SAP APO . . . . . 763.32 The product independent transportation lane . . . . . . . . . . . . . . . . 77

4.1 The structure of the simple supply chain example . . . . . . . . . . . . 804.2 Adding a new optimization profile . . . . . . . . . . . . . . . . . . . . . . . . . . 814.3 Optimization profile maintenance in SAP APO. . . . . . . . . . . . . . . 824.4 Weighting the SNP cost types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.5 Central optimizer cost maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 884.6 An example priority profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.7 An example time bucket profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.8 The SNP planning book setup for the example case . . . . . . . . . . . 924.9 Selecting all location products of planning version SIMPLE . . . . 934.10 The example demand pattern in the SNP planning book (1) . . . 944.11 The example demand pattern in the SNP planning book (2) . . . 944.12 The optimization entry screen in interactive SNP . . . . . . . . . . . . . 954.13 Cost overview after a successful optimization run . . . . . . . . . . . . . 964.14 The optimizer input log: transportation resource availability . . . 974.15 The optimizer result log: created planned orders by PPM . . . . . . 974.16 The optimizer result in the SNP planning book . . . . . . . . . . . . . . 984.17 The optimization profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994.18 Cost overview after the MILP run . . . . . . . . . . . . . . . . . . . . . . . . . . 994.19 Planned orders in the discrete case . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.1 A schematic view of the semiconductor production process . . . . . 1065.2 The different kinds of products in the supply chain (simplified) . 1165.3 Internal and external processes in the semiconductor case . . . . . 117

6.1 The Carlsberg supply chain structure . . . . . . . . . . . . . . . . . . . . . . . 1226.2 The production process at Carlsberg (simplified) . . . . . . . . . . . . . 123

7.1 Forecast-driven planning in the German automotive industry . . 1277.2 Order-driven planning in the German automotive industry . . . . . 1277.3 Planning levels in the chemical case . . . . . . . . . . . . . . . . . . . . . . . . . 1357.4 Production layout in the chemical case . . . . . . . . . . . . . . . . . . . . . . 137

9.1 Starting a cartridge from within TP/VS . . . . . . . . . . . . . . . . . . . . . 2139.2 Cartridge map with shipments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2149.3 Beverage supply chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2179.4 The warehouse with packaging lines and loading docks . . . . . . . . 2209.5 Cartridge external architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2249.6 Cartridge internal architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2279.7 The supply chain structure in the BASELL case . . . . . . . . . . . . . . 2389.8 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 Raw material procurement costs in the supply chain example . . 443.2 Location independent costs in the supply chain example . . . . . . . 443.3 Resource capacities and capacity expansion costs . . . . . . . . . . . . . 453.4 Production process data in the supply chain example . . . . . . . . . 453.5 Transportation lanes in the example supply chain model . . . . . . . 463.6 The locations in the example supply chain model . . . . . . . . . . . . . 543.7 Location product data maintained version-independently . . . . . . 573.8 Version-specific costs for the location products in the example . . 583.9 Resources in the example supply chain model . . . . . . . . . . . . . . . . 603.10 PPM header data in the example model . . . . . . . . . . . . . . . . . . . . . 683.11 PPM component data in the example model . . . . . . . . . . . . . . . . . 693.12 PPM resource capacity consumption data in the example . . . . . . 693.13 Product plan assignment data in the example model . . . . . . . . . . 693.14 Product specific transportation lanes in the example model . . . . 773.15 Means of transport data - constrained transportation lane . . . . . 783.16 Means of transport data - unconstrained transportation lane . . . 783.17 Product-specific means of transport in the example . . . . . . . . . . . 78

4.1 Settings in the SNP optimizer profile . . . . . . . . . . . . . . . . . . . . . . . 834.2 Demand forecast in the supply chain example . . . . . . . . . . . . . . . . 93

6.1 Consumer product industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.1 Products, extruders and production conditions . . . . . . . . . . . . . . . 137

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 Algorithmsfor Linear Programming. Technical report, Department of Management Sci-ences, The University of Iowa, Ames, Iowa, 1994.

3. R. Andrade, A. Lisser, N. Maculan, and G. Plateau. BB Strategies for Sto-chastic 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 Prob-lems Contaminated with Uncertain Data. Mathematical Programming, 88:411–424, 2000.

6. G. Berning, M. Brandenburg, K. Gursoy, V. Mehta, and F.-J. Tolle. An Inte-grated System Solution for Supply Chain Optimization in the Chemical ProcessIndustry. OR Spectrum, 24(3):371–401, 2002.

7. J. R. Birge. Stochastic Programming Computation and Applications. IN-FORMS 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. OptimalWaste Reduction and Investment Planning under Uncertainty. Computersand Chemical Engineering, 28:1145–1156, 2004.

10. A. Charnes and W. W. Cooper. Chance-constrained Programming. Manage-ment Science, 5:73–79, 1959.

11. L. Cheng, E. Subrahmanian, and A. W. Westerberg. Design and Planningunder Uncertainty: Issues on Problem Formulation and Solution. Computersand Chemical Engineering, 27:781–801, 2003.

12. T. A. Ciriani, S. Gliozzi, E. L. Johnson, and R. Tadei, editors. OperationalResearch in Industry. Macmillan, Houndmills, Basingstoke, UK, 1999.

13. R. J. Dakin. A Tree Search Algorithm for Mixed Integer Programming Prob-lems. 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 UniversityPress, Princeton, New Jersey, 1963.

16. G. M. De Beuckelaer. It’s Broken, Let’s Fix It - The Zeitgeist and ModernEnterprise. 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 Interfacefrom Modeling Systems to the NEOS Server. Technical report, Argonne Na-tional 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, Heidel-

berg, 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 UniversityPress, Oxford, UK, 1995.

23. C. A. Floudas. Deterministic Global Optimization: Theory, Methods and Ap-plications. Kluwer Academic Publishers, Dordrecht, Holland, 2000.

24. C. A. Floudas and X. Lin. Continuous-Time versus Discrete Time Approachesfor Scheduling of Chemical Processes: A Review. Computers and ChemicalEngineering, 28:2109–2129, 2004.

25. C. A. Floudas and X. Lin. Mixed Integer Linear Programming in ProcessIndustry: Modeling, Algorithms, and Applications. Annals of Operations Re-search, 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 andFuture Directions. Optima (Mathematical Programming Society Newsletter),51:1–9, 1996.

28. A. M. Geoffrion. Generalized Benders Decomposition. Journal of OptimizationTheory and Applications, 10:237–260, 1972.

29. P. E. Gill, W. Murray, and M. H. Wright. Practical Optimization. AcademicPress, London, 1981.

30. F. Glover and M. Laguna. Tabu Search. Kluwer Academic Publisher, Dor-drecht, The Netherlands, 1997.

31. J. Gottlieb and C. Eckert. Solving Real-World Vehicle Scheduling and RoutingProblems. International Scientific Annual Conference Operations Research2005, Bremen, Germany, Sept. 2005.

32. M. Grotschel. Mathematische Optimierung im industriellen Einsatz. Lectureat Siemens AG, Munich, Germany, Dec 07, 2004.

33. M. Grotschel. 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. MathematicalProgramming, 5:1–28, 1973.

37. R. Horst and P. M. Pardalos, editors. Handbook of Global Optimization. KluwerAcademic 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 Formulationfor Short-Term Scheduling. 1. Multipurpose Batch Processes. Industrial andEngineering Chemistry Research, 37:4341–4359, 1998.

40. M. G. Ierapetriou and C. A. Floudas. Effective Continuous-Time Formula-tion 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 For-mulation 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, Massa-chusetts, USA, 1976.

43. S. L. Janak, C. A. Floudas, J. Kallrath, and N. Vormbrock. ProductionScheduling of a Large-Scale Industrial Batch Plant: I. Short-Term and Medium-Term Scheduling. Industrial and Engineering Chemistry Research, in print,2006a.

44. S. L. Janak, C. A. Floudas, J. Kallrath, and N. Vormbrock. ProductionScheduling 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 Unit-Specific Event-Based Formulation for Short-Term Scheduling of MultipurposeBatch 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 Op-erations based on a Continuous Time Formulation. Computers and ChemicalEngineering, 28:1001–1019, 2004.

47. E. L. Johnson, M. M. Kostreva, and U. H. Suhl. Solving 0-1 Integer Pro-gramming Problems arising from Large Scale Planning Models. OperationsResearch, 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 For-

mulations. In F. Keil, W. Mackens, H. Voss, and J. Werther, editors, ScientificComputing in Chemical Engineering II, pages 330–337. Berlin, 1999.

50. J. Kallrath. Combined Strategic and Operational Planning - An MILP SuccessStory 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 Aca-demic Publisher, Dordrecht, The Netherlands, 2004.

54. J. Kallrath. Solving Planning and Design Problems in the Process IndustryUsing 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 MathematicalProgramming. 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 asSide Constraints. Master thesis, Department of Mathematics, University ofChicago, Chicago, 1939.

58. R. B. Kearfott. Rigorous Global Search: Continuous Problems. Kluwer Acad-emic Publishers, Dordrecht, The Netherlands, 1996.

59. W. K. Klein-Haneveld and M. H. van der Vlerk. Stochastic Integer Program-ming: 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 forShort-Term Scheduling of Batch Operations - I. MILP Formulation. Computersand Chemical Engineering, 17:211–227, 1993.

61. S. Kreipl and M. Pinedo. Planning and Scheduling in Supply Chains: AnOverview 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 andProbability, pages 481–492, Berkeley, CA, 1951. University of California.

63. R. Kuik, M. Solomon, and L. N. van Wassenhove. Batching Decisions: Struc-ture and Models. European Journal of Operational Research, 75:243–263, 1994.

64. A. H. Land and A. G. Doig. An Automatic Method for Solving DiscreteProgramming Problems. Econometrica, 28:497–520, 1960.

65. Y. M. Lee and T. I. Maindl. A Web-Based Chemical Formulation OptimizationTool. Lecture at the INFORMS 1998 Fall Meeting, Paper SA04-2, 1998.

66. X. Lin and C. A. Floudas. Design, Synthesis and Scheduling of MultipurposeBatch Plants via an Effective Continuous-Time Formulation. Computers andChemical Engineering, 25:665–674, 2001.

67. X. Lin, C. A. Floudas, S. Modi, and N. M. Juhasz. Continuous-Time Produc-tion Scheduling of a Multiproduct Batch Plant. Industrial and EngineeringChemistry Research, im Druck, 2002.

68. P. McMullen. The Maximum Number of Faces of Convex Polytopes. Mathe-matika, 17:179–184, 1970.

69. S. P. Meyn. Stability, Performance Evaluation, and Optimization. In Hand-book 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. ORSpectrum, 26/4:447–470, 2004.

71. G. E. Moore. Cramming more Components onto Integrated Circuits. Electron-ics, 38(8):114–117, 1965.

72. B. A. Murtagh and M. A. Saunders. Large-scale Linearly Constrained Opti-mization. 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. Comput-erwoche, 42:24, Oct 21, 2005.

References 311

75. R. K. Oliver and M. D. Webber. Supply-chain Management: Logistics Catchesup 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 - Heidel-berg, 1996.

77. M. L. Pinedo. Planning and Scheduling in Manufacturing and Services.Springer, New York, 2005.

78. A. Prekopa. Stochastic Programming. Kluwer Academic Publishers, Dordrecht,The Netherlands, 1995.

79. J. Rohde, H. Meyr, and M. Wagner. Die Supply Chain Planning Matrix. PPS-Management, 5(1):10–15, 2000.

80. C. Romero. Handbook of Critical Issues in Goal Programming. PergamonPress, Oxford, 1991.

81. H. Rommelfanger. Fuzzy Decision Support-Systeme - Entscheiden bei Un-scharfe. Springer, Heidelberg, 2nd edition, 1993.

82. A. Ruszczynski and A. Shapiro. Stochastic Programming, volume 10 of Hand-books in Operations Research and Management Science. Elsevier, North-Holland, 2003.

83. M. W. P. Savelsbergh. Preprocessing and Probing Techniques for Mixed IntegerProgramming 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. KluwerAcademic Publishers, Boston, MA, 1995.

86. R. Schultz. Stochastic Programming with Integer Variables. MathematicalProgramming Ser. B, 97:285–309, 2003.

87. S. Sen and J. L. Higle. An Introductory Tutorial on Stochastic Linear Pro-gramming Models. Interfaces, 29(2):33–61, 1999.

88. P. Spelluci. Numerische Verfahren der nichtlinearen Optimierung. Birkhauser,Basel, 1993.

89. H. Stadtler. Linear and Mixed Integer Programming. In H. Stadtler andC. Kilger, editors, Supply Chain Management and Advanced Planning, pages335–344. Springer, Berlin, Deutschland, 2000.

90. H. Stadtler. Supply Chain Management – An Overview. In H. Stadtler andC. Kilger, editors, Supply Chain Management and Advanced Planning, pages7–28. Springer, Berlin, Deutschland, 2000.

91. H. Stadtler. Supply Chain Management and Advanced Planning. Talk atEURO/INFORMS 2003, Istanbul, Turkey, July 2003.

92. H. Stadtler and C. Kilger, editors. Supply Chain Management and AdvancedPlanning. Springer, Berlin, 3rd edition, 2004.

93. C. Suerie. Time Continuity in Discrete Time Models - New Approaches forProduction Planning in Process Industries, volume 552 of Lecture Notes inEconomics and Mathematical Systems. Springer, Heidelberg, Germany, 2005.

94. Supply-Chain Council. Supply-Chain Operations Reference-model – SCORVersion 7.0 Overview. Technical report, Supply-Chain Council, 1400 EyeStreet, NW, Suite 1050, Washington DC, 20005, USA, 2005. www.supply-chain.org.

95. M. Tawarmalani and N. V. Sahinidis. Convexification and Global Optimiza-tion in Continuous and Mixed-Integer Nonlinear Programming: Theory, Algo-rithms, Software, and Applications, volume 65 of Nonconvex Optimization And

312 References

Its Applications. Kluwer Academic Publishers, Dordrecht, The Netherlands,2002.

96. H. Tempelmeier. Supply Chain Planning with Advanced Planning Systems. InProceedings of the 3rd Aegean International Conference on Design and Analysisof Manufacturing Systems, Tinos Island, Greece, May 19–22, 2001.

97. R. J. Vanderbei. Linear Programming - Foundations and Extensions. Kluwer,Dordrecht, The Netherlands, 1996.

98. J. Viswanathan and I. E. Grossmann. A Combined Penalty Function andOuter-Approximation Method for MINLP Optimization. Comp. Chem. Eng.,14(7):769–782, 1990.

99. S. W. Wallace. Decision Making Under Uncertainty: Is Sensitivity Analysis ofany Use? Operations Research, 48:20–25, 2000.

100. H. P. Williams. Model Building in Mathematical Programming. John Wileyand Sons, Chichester, 3rd edition, 1993.

101. L. A. Wolsey. Integer Programming. Wiley, New York, US, 1998.102. H. J. Zimmermann. Fuzzy Set Theory and its Applications. Kluwer Academic

Publishers, Boston, MA, 2nd edition, 1987.103. H. J. Zimmermann. Fuzzy Sets, Decision Making, and Expert Systems. Kluwer

Academic Publishers, Boston, MA, 1987.104. 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 ofreal world optimization problems through extensive experience in Europe, theUSA, and Asia. He solves industry problems with a broad spectrum of scien-tific computing methods that range from physical modeling to decision processsupport, as well as production planning and scheduling by mathematical opti-mization. He is a recognized expert in modeling/optimization, and a teacher,writer, and consultant. In addition to years of industrial experience, he hastaught graduate courses in mathematical modeling at Heidelberg University.He is also expert in eclipsing binary analysis and teaches graduate and under-graduate courses in astronomy and applied mathematics at the University ofFlorida (Gainesville, FL). He leads the working group Praxis der mathematis-chen Optimierung of the Gesellschaft fur Operations Research, the OR societyof the German speaking world. He runs numerous seminars and workshops onreal world optimization and holds a diploma in physics and a doctorate inAstronomy from Bonn University (Germany) and a professorship of the Uni-versity of Florida. He has written reviews on mixed integer optimization andon planning and scheduling of real world problems, in addition to about 70research papers in astronomy, applied mathematics, and industrial optimiza-tion. He is author of two books on mixed integer optimizing, one on modelinglanguages in mathematical optimization, and one on eclipsing binary stars.

Dr. Thomas I. Maindl deals with strategic research and development top-ics related to supply chain management and applies mathematical modelingand optimization to real world problems including, but not limited to, sup-ply chain management. His experience is drawn from projects in Europe, theUSA, and Asia on supply chain planning and scheduling, distribution networkdesign, delivering web-based formulation optimization, schedule optimization,medical cancer diagnosis, analyzing the stability of dynamical systems, andapplying the theory of general relativity to satellite orbits and includes severalyears of working for a global chemical company in the USA. Dr. Maindl holdsa 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 gen-eral relativity, mathematical modeling, and web-based optimization and hasbeen teaching undergraduate and graduate courses in astronomy and celes-tial mechanics at the University of Vienna, undergraduate courses in businessinformatics at the University of Applied Sciences in Darmstadt, and teachesgraduate courses in supply chain planning with advanced planning systems atthe University of Cologne.

Index

Aabbreviations XXVabsolute value function 31acceptance 141, 142, 206, 263activities 26addcut 290advanced planning 3advanced planning system see APSalgorithm 297

Branch and Bound 290enumeration 298evolutionary 11, 24, 124, 138, 275exponential time 278genetic 24homotopy 288optimization 23polynomial time 278rule-based 8

allocation problem 26alternative solutions 281APO see SAP APO

advanced planning system 9APS XXV, 6, 8, 9, 243Archimedian approach 36, 294arithmetic tests 294ATP XXV, 7, 109, 117, 274, 276, 297automotive industry 125Available-to-Promise see ATPaxentiv 125

BBAPI XXV, 212basic feasible point 279

basic feasible solution 279basis 279, 294, 297

re-inversion of the 282batch constraints 167, 168batch production 167big M method 283, 284bill of material XXV, 14, 55, 61, 239,

297BOM see bill of materialbounds 283, 287, 289, 290, 298

treatment of 284upper 285

Branch and Bound 290, 298Branch and Cut 298branching 290

generalized upper bound 290on a variable 291

breadth-first strategy 291Business Application Programming

Interface see BAPI

Ccalendar information 140campaign 83, 85, 167campaign constraints 168campaign production 167Capable-to-Match see CTMCapable-to-Promise see CTPcapacity 122, 239capacity planning 4, 109, 115case period 151central path 289CIF XXV, 9, 53, 117, 220

316 Index

class A customer 180client 31clique 294co-production 18, 156, 196, 199, 201co-products 64, 162, 163column generation 277columns 26, 279, 300complexity 255concave 83constraint programming see CPconstraints 25, 30, 239, 240, 298

disaggregation of 294in SAP APO see SNP optimizerin the example model 43mode-capacity 160

constructive heuristics 24continuous-time formulations 256, 267contract manufacturing 13contribution margin 18, 57, 84conventions XXVconvex 83, 298Core Interface see CIFcost 123, 239, 240

concave 83convex 83delay 184duty 179external purchase 184, 186, 197in SAP APO see SNP optimizerin the example model 43inventory 183mode changing 183product purchase 182rented inventory 183total variable 184transport 178, 179, 183, 239utilities 182variable production 182

CP XXV, 10, 25, 34, 38, 138, 267, 275crash 283, 284cross-over 289CTM XXV, 16, 105, 108, 111, 116, 298

strategies 17, 112CTP XXV, 7, 276, 298currency unit XXVcuts 298cutting stock problem 26, 260cutting-planes 298cycle time 108

DDash optimization 143data 25

consistency checks 238, 240, 265data consistency checker 39decision variables 26decomposition 20, 84, 89, 124, 130, 132,

139, 222, 267, 268priority 84product 89time 20

degeneracy 281demand forecast 38

rolling 237, 239demand forecasting see demand

planningdemand planning XXV, 5, 7, 135, 274depot location 26depth-first strategy 290detailed scheduling 4discrete-time formulations 167, 168, 301distribution and transportation

planning 8documentation 34

SAP APO 41domain 27

of a variable 290relaxation 29

DP see demand planningdual degeneracy 281dual problem 298dual value 282, 298duality gap 289, 298duty cost 179

Eedge-following algorithm 280elementary row operations 281Enterprise Resource Planning see ERPERP XXV, 243, 298eta-factors 282evolutionary algorithms see algorithmevolutionary strategies 34example

planning horizon 152supply chain model 42, 79

Explanation Tool 270, 275external purchase 181

Index 317

Ffeasible point 23, 24, 33–35, 256,

258–260, 299feasible problem 299fixed setup plans 158forced demand table 180functions

linear 299nonlinear 300

fuzzy set 37

Ggap see integrality gap

duality 289genetic algorithm 24goals 35, 138graphical user interface see GUIGUI XXV, 41, 51, 141, 142, 207, 208,

211–214, 216, 220, 221, 223–229,232–234

Hheuristics 15, 35

constructive 24homotopy parameter 287hybrid methods 284

Ii2 Technologies 40, 105ILOG 206, 207

cartridge 206, 208, 209, 211–213, 220,221, 223, 231

ODF (optimization developmentframework) 206, 212–214, 221,223, 225–228, 233, 234, 236

implicit enumeration 290improvement methods 24, 256, 260, 299in-transit shipment 169independent infeasible sets 193index sets 27, 28infeasibilities 194

diagnosing 193InfoCube 14, 275, 299initial feasible basis 283initial solution 283Integer Programming see IPintegrality gap 189, 291, 292, 299

relative 291scaling of penality terms 292, 293

integrationSAP APO with SAP R/3 53SNP optimizer with PP/DS 85with SAP R/3 and SAP APO 238

interchangeability of products 13interior-point methods 18, 278, 284,

287–289inventory

capacity 171demand point 171end of planning horizon 170initial stock 171, 239rented 173, 183requirements 112, 114, 237, 244safety stock 124, 172site 169

IP XXV, 290

KKuhn-Tucker conditions 288, 299

LLagrangian function 288lexicographic approach 294Lexicographic Goal Programming 36linear combination 299linear independence 299Linear Programming see LPliveCache 14, 275, 276, 299location 53location product 13, 55, 90logarithmic barrier method 288lot size 122, 237

in SAP APO see SNP optimizerlot sizing 154LP XXV, 25, 30, 33, 81, 124, 130, 279,

291, 299LU factorization 282

Mmaintenance 157Markov processes 38mass loss during transport 170master data 13, 41

in the example model 51location see locationlocation product see location productPDS see PDSPPM see PPM

318 Index

product see location productproduction data structure see PDSproduction process model see PPMresource see resourcetransportation lane see transportation

lanemaster planning 5, 7, 8, 109, 115, 125,

126Material Requirements Planning see

MRPmatrix 277, 279–282, 289, 297, 298, 300matrix generation 194maximin 32metaheuristics 24, 34

simulated annealing 34tabu search 34

MILP XXV, 25, 30, 32, 33, 81, 84, 98,123, 124, 238, 246, 290, 300

rounding 189minimax 32minimum ratio rule 285MINLP XXV, 25, 33, 33, 300MIP XXVMIQP XXV, 33Mixed Integer Linear Programming see

MILPMixed Integer Nonlinear Programming

see MINLPMixed Integer Programming see MIPMixed Integer Quadratic Programming

see MIQPmode changes 154, 155, 158

sequence-dependent 155model 300

predefined 21–23, 25, 39, 40, 50, 254,266, 268, 269

purpose of a 257model and version management 52modeling 21modeling language 39, 40, 143

mp-model 143OPL Studio 126Xpress-MP 143

modeling system 39, 40, 300models

in TriMatrix 247mathematical 22, 238mechanical 22purpose of 22

modes 153MRP XXV, 6–10, 235, 300MRP II 300multi-criteria objectives 187multi-criteria problems 35mySAP SCM 5.0 270

Nnet present value 153network design 5, 26network flow problem 300neural networks 34Newton-Raphson algorithm 288NLP XXV, 25, 33, 300node selection see selectionNonlinear Programming see NLPNP complete 293, 300NP hard 293

Oobjective function 25, 31, 301

choice of 181degeneracy of the 185, 188in SAP APO see SNP optimizer

ODBC XXVOperations Research XXVoptimization 241, 243, 301

... and SAP APO 39algorithm 301chance constrained 37definition 23definition (colloquial) 23multi-stage stochastic 37portfolio 269robust 37stochastic 37, 302under uncertainty 36versus simulation 35

optimization algorithm (definition) 23optimum

global 299local 300

order-based planning 16

Pparameter study 35Pareto optimal 35PDS XXV, 14, 51pegging 16, 112, 114

Index 319

dynamic 16fixed 16

penalty costsin SAP APO see SNP optimizer

performance 33, 124phase I and phase II 283piecewise linear approximation 83pivot 301pivoting 280planning 301

allocation 126budget 126capacity see capacity planningdemand 7hierarchical 199, 204, 273, 274master see master planningmid-range 128, 131, 134network 5operational 274order-based 16, 134order-driven 125, 126, 131, 134production see production planningsales 126short-term 136strategic 5, 126, 131, 274tactical 5, 274transportation see transportation

planningunder uncertainty 268

planning horizon 85, 151, 152planning version 52

active 53version-dependent data 55–57

portfolio optimization 26post-optimal analysis 85, 301PP/DS XXV, 10, 85, 274, 275PPM XXVI, 14, 51, 90, 98, 301

creating in SAP APO 61plan 62, 67

preprocessing 139, 228, 246, 249, 293presolve 293, 294, 301pricing 281, 301

devex 280partial 280

priorities 36, 291, 294, 295problem

allocation 26blending 26cutting stock 26, 260

degenerate 280infeasible 284, 299sequencing 26unbounded 302

procurement type 56product

in SAP APO see location productlifecycle 105

production 163capacity 163, 237minimum requirements 164, 166multi-stage 157rates 157total on reactor 166

production data structure see PDSproduction planning 4, 5, 8, 10Production Planning and Detailed

Scheduling see PP/DSproduction planning and scheduling 7production process model see PPMprogramming

chance constrained 37goal 268, 294, 299linear see LPmixed integer linear see MILPmixed integer nonlinear see MINLPnonlinear see NLPstochastic 37, 38successive linear 302

QQP XXVI, 33Quadratic Programming see QP

Rranging 28, 301raw material availability 162raw material pricing

nonlinear 182reactor

Last-in-Chain 155subject to design decisions 162topology 162, 194

real-world problems 34, 248reduced costs 39, 301relaxation 124, 241, 301

continuous 298of domain 29

relaxation of constraints 194, 195

320 Index

reporting 242resource 13, 59

capacity 60, 61types in SNP 59

resource utilization 129restrictions see constraintsResult Indicators 270revenue 182rounding 130, 190routing 55rules 262, 263

Ssales forecast see demand forecastSAP APO XXVI, 243

... and modeling 269APX (optimization extension

workbench) 208, 215, 224, 225components 9, 10, 273, 274

PP/DS (production planning/detailed scheduling) see PP/DS

SNP (supply network planning) seeSNP

TP/VS (transportation planning /vehicle scheduling) 11, 205, 274,276

definition 9documentation 41model 52

active 53optimizer see SNP optimizerplanning version see planning versionrelease 10, 13, 16, 51, 53, 115, 138,

199, 203, 209, 215, 218, 222, 239,276

release 5.0 275transaction 51

SAP R/3 115, 117, 219, 243release 239

scale-up 40scaling 284, 293, 301scheduling 8, 10, 15, 17, 25, 32, 34, 38,

253–256, 259, 261, 262, 265, 267,275, 276, 293, 297, 301

backward 112detailed 4, 7, 10, 14, 108, 121, 124,

134–136, 138, 273finite 11, 39forward 112, 114

in the chemical industry 125in the process industry 267rules in ... 262short 121under uncertainty 268vehicle 273

SCM X, XI, XXVI, 3, 108, 113, 120,121, 125, 302

SCOR model 4SCP matrix 6, 8, 9selection

of branching variable 291of node 290, 292

semi-continuous variables see variablessemiconductor manufacturing 105, 106

Moores law 107supply chain modeling 110supply chain planning 108

sensitivity analysis 37, 258, 261, 302sequence-dependent mode changes 146sequence-dependent setup time 146sequencing 26, 242, 245, 246service level 121setup matrix 196, 199shadow price 39, 283, 302shelf-life 56, 119, 147, 197shutdowns 157, 237, 240simplex algorithm 277, 278, 280, 282,

285, 289, 302dual 18, 82, 84, 286, 287primal 18, 82, 84, 286, 287

simulation 35, 37, 52, 53, 300SNP XXVI, 10, 12, 242, 244, 247, 274,

275, 302CTM see CTMheuristics 15optimization see SNP optimizeroptimizer 205planning book 86, 91, 97

key figure 92, 94planning horizon 85planning methods 15

SNP optimizer 18, 39, 113, 124, 209,211, 218, 220

aggregation 84constraints 19, 76, 82, 85, 87, 98costs 19, 57, 63, 68, 83, 86, 99

maintaining 86customizing 89

Index 321

decomposition 20, 84, 89demand categories 84, 93incremental optimization 85logs 86, 95, 96lot sizes 82, 88, 90, 99model 42, 247

adding objects 69consistency check 86, 95

objective function 18, 84, 244penalty costs 57, 87planning run 95, 98, 124profiles 80–91, 95, 98

softwareCPLEX 8, 39, 105, 114, 126, 139, 207,

208, 221, 268, 287Mosel 238TriMatrix 246–249Xpress-MP XV, 8, 39, 114, 143, 166,

189, 238, 268, 287solution

heuristic 299number of 279optimal 301

solver 143CPLEX 8, 39, 105, 114, 126, 139, 207,

208, 221, 268, 287mp-opt 143Xpress-MP XV, 8, 39, 114, 143, 166,

189, 238, 268, 287sparsity 282, 287, 289stock see inventorystorage sites 146strategic network planning 7supply chain

example model 42master data 51

execution 5operations 5planning 5

Supply Chain Engineer 43, 69, 70, 77supply chain management see SCMsupply chain model 41, 79supply chain planning matrix 6, 273Supply Network Planning see SNPSupply-Chain Council 4

Ttargets 35, 36, 294, 295, 299termination criterion 289, 291time bucket 14, 60, 67, 75, 83–85, 87,

90, 91, 93, 98, 109, 123, 124, 197,199–202, 274, 275, 301, 302

see also time slice 27time period 301

see also time bucket 27, 248time slice 144, 147, 151–153, 168, 177,

199, 201, 302commercial 178see also time bucket 27

transaction 51transport 176transport mean 176, 179transport time 179transportation lane 72, 88, 90transportation planning 5, 8

routing 5TriMatrix 247–249two-phase method 283, 284

Uuser interface 131, 238, 240utilization rate 146, 147, 164–166, 195,

200

Vvariables 25, 302

artificial 283basic 279–283, 297binary 29, 31, 83, 155, 158–161, 168,

173, 176, 179continuous 29discrete 30, 32external purchase 155, 156free 30, 295integer 29, 168, 189mode-duration 154, 160, 161non-basic 279–281, 283, 300partial integer 30production 154semi-continuous 29, 155, 156, 163,

165, 166, 168, 177, 202semi-integer 30slack 284, 302state 155, 157stock 155, 173surplus 284, 302transport 155, 177, 178unconstrained 30

vector 302vector minimization 35vehicle routing 4, 206