Die Asea Brown Bovery AG, Zürich, ein international tätiges Unternehmen der Elektro-, Verkehrs- und Umwelttechnik, setzt sich aus mehr als tausend rechtlich selbständigen Einheiten zusammen. Deren Geschäft umfaßt sowohl die Einzelproduktion mit Losgröße 1 als auch Serienfertigung, woraus sich Anforderungen unterschiedlichster Art ergeben. Dessenungeachtet lautete die Vorgabe des ABB-Vorstands: "R/3 aus der Steckdose für alle Gesellschaften". Im Klartext: Hat eine der ABB-Gesellschaften die Standardsoftware - mitsamt dem Customizing - erfolgreich installiert, so soll diese Lösung möglichst unverändert auf die anderen Gesellschaften übertragen werden. Dadurch hofft das ABB-Management, Einführungs- und Wartungskosten sparen zu können.
Als Mittel bietet SAP hier die Funktion Korrektur- und Transportwesen (KTW) an, die dabei hilft, ein "Original" in andere Systeme zu "transportieren". Die Softwarepflege kann sich auf das Original beschränken, weil KTW die Änderungen weiterreicht.
Der ABB-Tochter Turbinen Nürnberg GmbH (TUR), einem Einzel- und Servicefertiger, gelang das Kunststück, in sechs Monaten die kaufmännischen Finanz- und Controlling-Daten von R/2 4.3 beziehungsweise 5.0 auf R/3 3.0C zu übertragen. Gleichzeitig implementierte das Unternehmen ein System für die Vertriebsunterstützung, das auf den R/3-Modulen SD (Vertrieb) und PM/SM (Instandhaltung und Projektsystem) basiert.
Zeitweilig arbeiteten sechs Projektteams aus unterschiedlichen ABB-Firmen, darunter der ABB Informatik GmbH, Mannheim, parallel daran, diese Aufgabe zu lösen. Auf dem Projekthöhepunkt waren 50 Mitarbeiter involviert, die ihrerseits von Know-how-Trägern der SAP und anderer Anbieter unterstützt wurden.
Gegenüber der Vorgängerversion stellt das R/3-Release 3.0C einen erheblich vergrößerten Funktionsumfang zur Verfügung. Trotzdem war es notwendig, die ABB-spezifischen Erweiterungen in den Bereichen Projekt-Controlling und Vertriebsablauf zu berücksichtigen. Das Projektgeschäft eines Auftragsfertigers bedarf nämlich einiger Funktionen, die im Standard-R/3 bislang fehlen.
Dazu zählt die automatische Generierung von hierarchischen Kostenträgerstrukturen zu einem Kundenauftrag, aber auch die Übernahme von Anlagen-Strukturen in einen "Warenkorb" und deren anschließende Kopie in ein Angebot oder einen Auftrag.
Für die Produktionsplanung und -steuerung nutzt TUR ein eigenes System, das auf der Grundlage eines Produkts von Debis entwickelt wurde. Dieses Programmpaket soll erst in einem künftigen Projektschritt abgelöst werden. Also waren zunächst einmal Schnittstellen zwischen PPS und SAP-Software notwendig. Die R/3-eigene PPS-Funktion stellt derzeit lediglich eine Schattendatenbank für das individuelle PPS-System bereit.
Materialstamm und Stücklisten werden nur über die TUR-Eigenentwicklung verwaltet, in der ebenfalls die gesamte Logistik läuft. Im SAP-System wird der Prozeß - beginnend beim "Primärbedarf", dem Kundenauftrag - erst von der Warenbereitstellung an mit Lieferschein und Faktura geführt. Einkauf und Fertigung laufen im TUR-Programm ab. Eine Schnittstelle transferiert jedoch alle anfallenden Kosten nach R/3, so daß der Wertefluß erhalten bleibt.
Sachbearbeiter mußten sich umgewöhnen
Das PPS-System der TUR bietet rudimentäre Vertriebsfunktionalität, wurde in diesem Bereich aber nur bedingt eingesetzt. Statt dessen nutzten die Vertriebsmitarbeiter das Microsoft-Paket "MS Office". Dieses PC-Werkzeug kann aber einige der für Unternehmen wichtigen Anforderungen nicht oder nur teilweise erfüllen:
-Corporate Identity beim Layout der Vertriebsbelege,
-einheitliche, sachbearbeiterunabhängige Bewertungs- und Kalkulationsschemata,
-kundenspezifische Preisfindung und -pflege,
-Vertriebsinformations-Systeme sowie
-Datenbankzugriffe auf Primärinformationen wie Kundendaten, Materialien, Preise, Maschinenstrukturen, Einbauorte und verschiedene Schlüsselsysteme.
Fazit: Bei einem größeren Unternehmen ist ein System mit Datenbankunterstützung unabdingbar. Wenn möglich, sollte es durchgängig von der Kundenanfrage bis zur Faktura genutzt werden. Nur dann stehen allen Sachbearbeitern konsistente Daten zur Verfügung.
Die Arbeitsweise des an "Winword" und "Excel" gewöhnten Sachbearbeiters änderte sich dadurch grundlegend. Vor allem war er gezwungen, sich an eine im Geschäftsprozeß definierte Reihenfolge der Bearbeitung zu halten.
Zumindest anfangs führte das zu erhöhtem Aufwand, der wiederum Verdruß beim Management nach sich zog. War doch in der Kosten-Nutzen-Analyse des Projekts von einer deutlichen Reduzierung der Durchlaufzeit die Rede gewesen. Rechtzeitige Aufklärung der Entscheidungsträger und gründliche Schulung der Endanwender tragen dazu bei, daß diese Frustration schnell vorübergeht.
Heute kann der Servicevertrieb der TUR in wenigen Minuten ein Kundenangebot erstellen, indem er auf die Stammdaten der Maschinen zurückgreift, in einer damit verbundenen "Ersatzteilstruktur" die gewünschten Posten ankreuzt und sie dann kopiert. Derartiger Komfort setzt allerdings einen gewissen Pflegeaufwand voraus.
Schwierigkeiten bereiten lediglich die zahlreichen Schnittstellen zwischen SD und dem eigenen PPS-System sowie aus den innerhalb der SAP-Software erstellten Zusatzfunktionen. Das macht die Wartung schwieriger, die Datenkonsistenz weniger sicher, die Bedienoberfläche heterogen und das Berichtswesen komplizierter.
Trotzdem wurde das Vertriebsmodul der SAP zunächst ohne eine hinreichende Materialwirtschaft installiert. Aus Sicht der Geschäftsführung war es wichtiger, den Vertrieb schnell mit einer durchgängigen Lösung zu unterstützen, als in einigen Jahren ein von Anfang an komplettes System einzuführen.
In der täglichen Praxis wirkt sich diese Einschränkung nicht weiter störend aus. Problematisch ist nur die Abrechnung der verschiedenen Profit-Center untereinander. In der Version 3.0C erfüllt R/3 hier noch nicht die Praxis-Anforderungen. Um eine durchgängige Numerierung der Kundenaufträge sicherzustellen, hat TUR die Erweiterungsmöglichkeiten genutzt, die 3.0C anbietet. Sie sorgen zum Beispiel dafür, daß die "Append"-Strukturen releasewechselfähig bleiben.
Die Vertriebsabwicklung mittels SD hat nicht nur das Projekt-Controlling auf festere Füße gestellt, sondern bietet auch automatische Links zur Finanzbuchhaltung. Aufgrund eigener Erweiterungen auf dem Sektor Zahlungspläne kann der Buchhalter dem System jetzt einen Teil der bislang manuell nachgehaltenen Buchungsvorgänge übertragen.
Die Vermutung liegt nahe, daß die Implementierung der Fibu-Komponente "FI" tatsächlich der Forderung nach SAP aus der Steckdose nachkomme, da die Fibu-Prozesse schließlich durch gesetzliche Vorschriften normiert seien. Aber zum einen muß eine ABB-Tochter, wenn sie die Lösung einer anderen übernehmen will, ihren bisherigen Kontenplan aufgeben. Zum anderen sind Funktionen wie Akkreditivabwicklung im Exportgeschäft oder Zahlungspläne nur für Auftragsproduzenten von Belang, den Serienfertigern hingegen unbekannt.
Hinzu kommen unterschiedliche Schnittstellen in die jeweilige Systemumgebung. Fast jeder Betrieb setzt sein eigenes "Logistiksystem" ein, womit der SAP-Jargon die Materialabwicklung bezeichnet. Die Interfaces zu vereinheitlichen ist nur möglich, wenn jede ABB-Tochter ihre Altsysteme in einem Zug ablöst.
Ein solches Projekt wäre aber hochgradig komplex und die "Operation am lebenden Objekt" extrem risikoreich. Darunter, daß die Laufzeit meist zwölf Monate übertrifft, leidet die Übersicht - zumal sich Zwischenstufen nur schwer definieren lassen.
Das TUR-Projekt stellt also einen Kompromiß dar: zwischen den Forderungen nach kurzer Realisierungszeit, maximaler Erfüllung der Geschäftsziele und minimalem Risiko. Seit Anfang Juli besitzt das Unternehmen ein System, das als Basis für die Vertriebsabwicklung auch bei anderen Auftragsfertigern genutzt werden kann. Damit sparen die ABB-Gesellschaften Zeit und Geld. Die Vorstellung, daß diese Lösung eins zu eins übernommen werde könne, bleibt allerdings Illusion.
Angeklickt
Eine einheitliche SAP-Implementierung für unterschiedliche Konzerngesellschaften zu schaffen war die Vorgabe, die der Technologiekonzern ABB mit der Migration von R/2 auf R/3 verband. Für dieses Ziel hätten die einzelnen Betriebe einschneidende Änderungen in den Geschäftsfunktionen hinnehmen müssen. Zudem wäre das Gesamtvorhaben wesentlich komplexer und zeitaufwendiger geworden. Deshalb ging das Projekt-Management von der Maximalforderung ab und realisierte eine Lösung, die als Basis für individuelle Implementierungen dienen soll.
*Gerrit Meyer ist IS-Manager bei der ABB Turbinen Nürnberg GmbH, Dr. Bernd Müller, Projekt-Manager bei der ABB Informatik GmbH, Mannheim, zeichnete für die Migration von R/2 nach R/3 verantwortlich.