von Jörg Theobald, ORBIS AG

Die Zeit ist reif für die nächste Softwaregeneration. Das MRP-II-Konzept hat ausgedient, die Riege der Advanced Planning and Scheduling-Tools (APS) steht bereit. Einerseits stehen damit lang ersehnte Möglichkeiten zur Verfügung, mit denen sich viele Lücken aus der MRP-II-Ära schließen lassen. Andererseits kommen mit den APS-Tools auch viele neue Fragestellungen ins Haus.

Wie lang muss eine schöne Supply-Chain eigentlich sein?

Ein weit verbreitetes Missverständnis oder auch Vorurteil ist: „SCM-Lösungen sind nur sinnvoll, wenn es um Themen der unternehmensübergreifenden Zusammenarbeit geht.“ Das Bild der Logistikkette – vom Lieferanten zum Hersteller zum Kunden und weiter – hat sich offensichtlich zusammen mit den drei Buchstaben SCM in vielen Köpfen eingebrannt. Tatsächlich spielt die unternehmensübergreifende Integration der Planungsprozesse in der Mehrzahl der SCM-Projekte keine Rolle. Theoretisch steht zwar außer Frage, dass diese Form der Zusammenarbeit der Idealzustand wäre, aber in den meisten Supply-Chains ist die Bereitschaft zu einem so weit reichenden Schulterschluss nicht gegeben. Außerdem sind nicht alle Supply-Chains dafür geeignet. Was beim OEM und einer Handvoll First-Tier-Lieferanten noch umsetzbar ist, scheitert spätestens im Mittelstand an der überwältigenden Vielfalt der Lieferbeziehungen untereinander. Nicht zuletzt erreichen die einzelnen Lieferbeziehungen oft nicht die kritische Masse, die ein solches Vorhaben rechtfertigen würde. Kurz gesagt, oft liegen die weitaus realistischer zu erschließenden Potentiale im eigenen Unternehmen. Der gegebenenfalls später folgende zweite Schritt in die unternehmensübergreifende Zusammenarbeit ist damit nicht ausgeschlossen.

Big Bang oder scheibchenweise?

In APS-Einführungsprojekten geht es meistens um Planungsfunktionen – wie der Name schon sagt. Je nachdem, ob es um die Absatz-, Beschaffungs- oder Produktionsplanung geht, tangieren diese Projekte weite Teile des Unternehmens. Zudem ergeben sich regelmäßig notwendige organisatorische Änderungen. Die Erfahrung zeigt, dass eine schrittweise Einführung grundlegende Vorteile hat. Das war prinzipiell auch bei den gigantischen ERP-Projekten der vergangenen Tage so. Finanzwesen-, Controlling- oder Personalabrechnungsthemen bedingten allerdings regelmäßig die Notwendigkeit von unternehmensweiten Produktivstarts zu fixen Quartals- oder Jahresendterminen. Auch die Logistikfunktionen mit ihrem transaktionalen Fokus auf einzelne Geschäftsvorfälle eignen sich selten uneingeschränkt für die schrittweise Inbetriebnahme. Die Einführung von APS-Systemen hingegen ist diesbezüglich normalerweise unkritisch. Diese Chance sollten Unternehmen nutzen und die Einführung funktional und / oder unternehmensbereichsbezogen staffeln. Das reduziert die Komplexität des Produktivstarts deutlich und führt letztlich auch früher zu vorzeigbaren Ergebnissen.

Doppelt hält besser: Was tun, wenn manche Funktionalitäten mehrfach vorhanden sind?

Gerade im SAP-Umfeld werden Berater immer öfter mit dieser Frage konfrontiert. Wann soll die Absatzplanung mit APO-DP abgebildet werden? Sollen wir nicht lieber mal SEM untersuchen? Ist R/3-SOP wirklich tot? Wann ist PP, wann APO-PP/DS die beste Wahl? APO, BW und R/3 sind zwar technisch getrennt, aber aus Lizenzsicht ist diese Trennung in vielen Fällen bereits Nebensache. Schon in diesem frühen Stadium droht den Projektteams die Gefahr, auf das falsche Pferd zu setzen. Eine allgemeingültige Entscheidungstabelle gibt es leider nicht. Es ist vielmehr wichtig, zu diesem Zeitpunkt Berater einzubinden, die alle Alternativen kennen und nicht nur ihr bekanntes Standardrepertoire abspulen.

SAP-APO besteht aus vielen Modulen, die zusammen alle Teilpläne von der Budget- über die Absatz- bis zu Beschaffungs- und Maschinenfeinplanung abdecken – und noch einige Funktionen mehr. Immer wieder ist die Aussage zu hören, APO müsse auch immer als Ganzes genutzt werden. Das ist falsch. Auch ein APO-System, mit dem ‚nur’ eine Maschinenbelegungsplanung für einen Teilbereich des Produktspektrums eines Mittelständlers im Schwäbischen abgebildet wird, ist eine fertige und in sich abgeschlossene Lösung. Gegen eine Abbildung der restlichen Planungsfunktionen in R/3, JDE oder woanders spricht nichts. Mittlerweile fördert SAP diesen Best-of-Breed-Ansatz im Rahmen der Netweaver-Technologie sogar.

Ich hätte da gerne mal ein Problem

Zu allem Unglück haben diese SCM-Tools, obwohl sie noch recht jung sind, bereits Unmengen von Funktionen an Bord. SAP hat mit APO wie immer den Komplexitätsvogel abgeschossen und gleich mehrere Module abgeliefert. So oder so ähnlich lauten die Bedenken vieler Interessenten, die sich mit dem Gedanken an APS-Projekte tragen. Aber das Vorhandensein vieler Funktionen oder Module ist kein Malus. Ganz im Gegenteil. Berater wissen es zu schätzen, wenn ein großer Fundus an möglichen Alternativen existiert, um eine spezielle Fragestellung doch noch zu lösen. Eine schlanke Software ist nicht per se wünschenswert, wenn im Detail viele weiße Flecken bleiben. Es kommt auf die Übersichtlichkeit der damit erzielten Lösung an. Niemand muss alle Funktionen nutzen. Auch in der ERP-Welt bleibt schließlich die Mehrzahl der Felder und Masken ungenutzt, und der Problemlösungsansatz hat sich in der Projektpraxis bewährt. Bevor ein Unternehmen sich mit verfügbaren Softwarefunktionen befasst, sollten die Anforderungen und Schwachstellen unbedingt gesammelt und strukturiert aufbereitet werden. Klare Pflichtenhefte und logische Soll-Prozesse sind gegenüber der Trial-and-Error-Funktionsauswahl aus der Software-Funktionsbeschreibung klar im Vorteil.

Die Software wird’s schon richten?

Die nächste Softwaregeneration bietet sagenhafte Möglichkeiten. Aber ohne die Bereitschaft zu organisatorischen Änderungen bleiben die größten Potenziale ungenutzt. Gerade in diesem Umfeld lauern viele Nebenkriegsschauplätze und „Das war schon immer so“- Gefahren. Ein wenig Feintuning hier und da reicht in den seltensten Fällen. Bei ERP-Projekten konnten Unternehmen oft wählen, ob das organisatorische Redesign vorher, während oder nach dem Projekt erfolgen sollte – oder nie. Oft war eine neue ERP-Lösung ein Jahr-2000- oder Euro-fähiges Derivat des Altsystems mit homöopathischen Detailverbesserungen und manchmal auch Rückschritten. Das ist ein wesentlicher Unterschied zu SCM-Projekten: SCM-Projekte sind keine IT-getriebenen Projekte mehr. Ein klares Sollkonzept von Management- oder Anwenderseite ist Grundvoraussetzung für eine erfolgreiche Abbildung in der Software-Welt. Dazu gehört zuallererst die definitive Bereitschaft zu umfassendem Business Process Reengineering und ein verlässliches Commitment des Managements.

Fazit: SCM-Projekte sind eine Klasse für sich. Zu der Komplexität der Tools kommt die Notwendigkeit, (Planungs-)Prozesse im Vorfeld kritisch zu durchleuchten. Redesign an solchen Stellen betrifft im Endeffekt nicht selten den größeren Teil des Unternehmens. Das stellt deutlich höhere Ansprüche an ein geordnetes Change-Management und die Überzeugungskraft der damit betrauten Personen. Ein Punkt, der den Propheten im eigenen Land gelegentlich schwer fällt. Trotzdem kein ideales Feld für reine Management-Berater. Ein Quäntchen Proof-Of-Concept bereits in der Konzeptionsphase ist ratsam, um am Ende zu umsetzbaren Lösungen zu kommen.