Die Hochzeitsnacht einer Firmenehe verläuft alles andere als romantisch: Nach dem Standes-, äh: Kartellamt ist Aufräumen angesagt. So war es auch, als Ende 1998 der Fresenius-Bereich Pharma mit dem Infusionsgeschäft des schwedischen Unternehmens Pharmacia & Upjohn zur Fresenius Kabi AG fusionierte: Im Zuge der Konsolidierung wurden einige ausländische Standorte geschlossen, andere ausgebaut, und neue Marktgesellschaften entstanden.
Foto: Fresenius
Um die neue Struktur abzubilden und die Effizienz der Standorte zu erhöhen, beschloss Fresenius Kabi, auch die Logistikprozesse neu zu ordnen. Die unterstützenden Applikationen, beispielsweise von J.D. Edwards, Sigma und Movex, sollten dabei aber nicht abgelöst, sondern in ein übergreifendes System integriert werden.
Direktkontakt gegen den Bullwhip-Effekt
Mit Auswahl und Implementierung der Lösung wurde die Fresenius Netcare GmbH beauftragt. Die hundertprozentige Fresenius-Tochter bildet mit ihren 240 Mitarbeitern quasi ein konzerneigenes SAP-Kompetenzzentrum. Keineswegs unerwartet fiel ihre Wahl deshalb auf die Lösung des größten deutschen Softwareunternehmens, genauer gesagt: auf den „Advanced Planner and Optimizer“ (APO), heute „Mysap SCM“ genannt.
Laut Martin Wild, Leiter des Competence Center Materialwirtschaft, blieben Mitbewerber wie Manugistics oder i2 Technologies aber auch deshalb außen vor, weil die vollständige Integration in den R/3-Kernel zu den wesentlichen Anforderungen an das neue System gehörte. Darüber hinaus standen auf der Prioritätenliste die Punkte:
automatisierte Prozesse implementieren,
Unterstützung für einen 24-stündigen Lieferservice gewähren,
einen Workflow für Organisation, Materialfluss und Finanzen einrichten sowie
eine Grundlage für die Produktionsplanung schaffen.
In die Lösung zu integrieren waren mehr als 30 produzierende, beschaffende und verkaufende Einheiten mit 4200 „aktiven“ Materialien.
Das Projekt in Kürze
Ziel: Neuorganisation der Supply-Chain-Logistik im Zuge einer Fusion.
Umfang: für mehr als 30 produzierende, beschaffende und verkaufende Einheiten.
Unternehmen: pharmazeutischer Prozessfertiger.
Herausforderung: heterogene Ausgangssysteme, nicht ganz ausgereifte Software.
Zeitrahmen: von 1999 bis 2001, läuft produktiv.
Aufwand: damaliger SAP-Listenpreis von rund 17800 Euro für eine APO-Volllizenz, Kernteam von sechs Leuten.
Ergebnis: geringere Bestände, niedrigere Transportkosten, mehr Flexibilität.
Basis: Mysap Supply Chain Manager 3.0 A auf Basis von R/3 4.6B, SAP Business Information Warehouse, SunOS 5.8, DBMS von Informix.
Realisierung: Inhouse-Dienstleister Fresenius Netcare GmbH.
Besonderheiten: Anbindung bestehender Applikationen von J.D. Edwards, Sigma und Movex etc.
Nächster Schritt: Migration auf R/3 4.6C im Frühjahr 2003.
Das wesentliche Merkmal der heutigen Supply-Chain-Management-Struktur besteht darin, dass Werk und Niederlassung dieselben Planungsdaten verwenden können. Zuvor unterhielten Zentrale, Produktion, Kundendienst und Tochterunternehmen ihre eigenen Planungszyklen, deren Ergebnisse sie an die jeweils nachfolgende Stufe weiterreichten. Fehleinschätzungen zogen den berüchtigten „Bullwhip“-Effekt nach sich, bei dem sich eine erwartete und kommunizierte Bedarfsänderung über die logistische Kette hinweg zu gewaltigen Überkapazitäten aufschaukelt.
Um hier Abhilfe schaffen zu können, mussten zunächst alle beteiligten Organisationen ihre Stammdaten harmonisieren. Gleichzeitig wurden Regeln zur globalen Pflege der Materialstämme eingeführt. Zudem erhielten Vertrieb und Bestandsverwaltung ein eigenes Management-Informationssystem.
Im zweiten Schritt war die gesamte Organisation auf das Prinzip des „Direktkontakts“ umzustellen. Die Planungsebenen mussten verringert, die Prozesse zwischen Fertigung und Niederlassung standardisiert werden.
Berichte mit Key-Performance-Indikatoren
Erst dann konnte Fresenius Netcare das eigentliche Supply-Chain-Management in Angriff nehmen. Dazu gehören:
das kontinuierliche Auffüllen des Systems mit dynamischen Parametern,
die Automatisierung der Prozesse,
der Aufbau eines Berichtswesens mit Key-Performance-Indikatoren (KPIs) und
die Einführung der Supply Chain Execution auf der Basis von Ausnahmen („Alerts“).
Im Einzelnen nutzt Fresenius Kabi die SAP-Funktionen „Demand Planning“ (DP), „Supply Network Planning“ (SNP), „Deployment“, „Transport Load Builder“ (TLB) und „Alert Monitor“. Aus dem Transaktionssystem R/3 4.6B erhält das Planungssystem via Remote Function Call (RFC) die Bestands- und Forecast-Daten sowie die „Supply Chain Agreements“ (SCA); das sind Vereinbarungen zwischen Niederlassung und Fertigungsstandort, die alle planungsrelevanten Stammdaten aus R/3 und APO betreffen. R/3 wiederum wird von lokal installierten und via File Transfer Protocol (FTP) angebundenen Nicht-SAP-Systemen gespeist.
Foto: Fresenius
Die Auswertung der Supply-Chain-Daten, die Untersuchung hinsichtlich der KPIs und der Abgleich der Lagerdaten geschieht mit Hilfe des ebenfalls von SAP stammenden „Business Information Warehouse“ (BW), das mit R/3 und APO über „Intermediate Documents“ (Idoc) kommuniziert. Das gesamte System läuft auf Hardware von Sun mit einem Datenbank-Management-System von Informix.
Mit Hilfe des neuen Logistiksystems gelang es Fresenius Kabi eigenen Angaben zufolge, die Bestände zu verringern, die Transportkosten zu senken und Arbeitsaufwand zu sparen. Konkrete Zahlen will der börsennotierte Prozessfertiger nicht nennen, „aber allein die herausgefallenen Bestände reichen aus, damit das Projekt sich rechnet“, beteuert Wild. Zudem sei das Unternehmen heute in der Lage, flexibel auf Änderungen des Marktes zu reagieren. Insgesamt hätten die Prozesse an Transparenz gewonnen. Im Zuge der Neugestaltung habe sich die Qualität der Stammdaten und die Forecast-Genauigkeit verbessert. Kunden und Vertrieb profitierten von einer verbesserten Lieferfähigkeit.
Mit Release 3.0A eingestiegen
Eigenen Angaben zufolge hat Wild „lange gekämpft“, bis ihm das Unternehmen den Auftrag für die Implementierung der SAP-Software erteilte. Zunächst sei eine Eigenentwicklung präferiert worden. In das First-Customer-Shipment-Programm der SAP stieg Fresenius Kabi als allerletzter Kunde ein, was vor allem damit zusammenhing, dass der Pharmaproduzent nicht das bereits stabile Release 2.0B, sondern die Nachfolgeausführung 3.0A einführen wollte. Wie Wild erläutert, deckte 2.0B nicht alle Kabi-Anforderungen ab; beispielsweise habe es kein „Realtime-Deployment“ erlaubt.
Das Unternehmen: Sicher möchte niemand gern Endkunde von Fresenius Kabi werden. Das Kerngeschäft des Unternehmens bilden Infusionslösungen zum Flüssigkeits- und Blutvolumenersatz sowie zur intravenösen und enteralen (über den Magen-Darm-Trakt zugeführten) Ernährung.
Die Fresenius Kabi AG mit Sitz in Bad Homburg entstand 1998, als sich der Fresenius-Bereich Pharma mit dem Infusionsgeschäft des schwedischen Herstellers Pharmacia & Upjohn zusammenschloss. 2001 betrug der Umsatz des fusionierten Unternehmens rund 1,274 Milliarden Euro, womit er etwa 14 Prozent über den Einnahmen des Vorjahres lag. Der Profit vor Steuern sank allerdings von 88 auf 75 Millionen Euro. Für die ersten neun Monate des laufenden Geschäftsjahres verfehlte der Umsatz mit 935 Millionen Euro knapp die Vorjahresmarke von 942 Millionen, der Vorsteuerprofit übertraf jedoch mit 60 Millionen Euro den Vergleichswert von 2000 um mehr als 60 Prozent.
Release 3.0A aber lag vor vier Jahren noch in den Windeln und war auch zum Zeitpunkt der Implementierung nicht ganz ausgereift. So konnten beispielsweise im TLB-Modul zwei Anwender dieselben Daten bearbeiten, ohne dass eine Sperre sie daran gehindert hätte, erinnert sich Wild. Inkonsistenzen seien die logische Folge gewesen. Auch die Produktfreigabe für Informix dürfte etwas voreilig erteilt worden sein, denn während der Testphase hätten sich hier und dort hart codierte Zugriffe auf andere Datenbanksysteme gefunden. Dank der guten Kontakte zu den SAP-Entwicklern seien diese Probleme aber schnell beseitigt worden, beteuert der Projektleiter. Trotzdem rate er jedem Anwender, das System vor der Einführung gründlich auszutesten.
R/3 Enterprise noch kein Thema
Mittlerweile läuft das System seit einem knappen Jahr produktiv. Für das kommende Frühjahr plant Wild, das Transaktionssystem von Release 4.6B auf 4.6C zu migrieren. Für den Umstieg auf das von SAP heftig beworbene „Enterprise“-Paket sieht er derzeit keinen Anlass: „Wir haben ein stabiles System.“ Auch die Aussicht, bei einem künftigen Release-Wechsel nur noch Teile des Gesamtsystems austauschen zu müssen, vermag seine Bedenken nicht zu zerstreuen. Die Migration von 4.0B auf 4.6B habe ihn gelehrt, dass nicht alles so glatt laufe, wie es der Hersteller verspreche.