Client-Server-Anwendungen/Re-Engineering bedeutet auch, den Mitarbeiter ernst zu nehmen Allround-Ansatz der SAP AG stoesst beim PPS an Grenzen

03.03.1995

Der PPS-Bereich war in der Vergangenheit nicht eben die Staerke der SAP AG. Das Modul "RM-PPS" wurde in der Praxis oftmals auf die Funktionalitaet einer einfachen Materialverwaltung reduziert, berichtet Jochen Konrad-Klein*. Mit Einfuehrung der Industrial- Solution-Module, so der Autor, wird sich im R/3-Umfeld einiges aendern.

Als Technologieberater haben wir eine eigene Sicht auf die SAP- Installationen in Unternehmen. Uns interessiert die Perspektive der Mitarbeiter sowie der Betriebs- oder Personalraete. Gegenstand unserer Beratung sind zum einen die Realisierung von Datenschutz und die Vermeidung ungerechtfertigter Leistungs- und Verhaltenskontrollen, zum anderen befassen wir uns mit betrieblichen Reorganisationskonzepten.

Darunter fielen frueher das Computer Integrated Manufacturing (CIM) einschliesslich Produktionsplanung und -steuerung (PPS). Heute beschaeftigen uns Lean Production und Business Re-Engineering. Vor diesem Hintergrund ist festzustellen, dass die mit der Einfuehrung von SAP-Software verbundenen Probleme in der Regel unterschaetzt werden. Die durch die Software erzwungenen organisatorischen Anpassungen in den Betrieben sind bedeutsamer, als dies von vielen Anwendern vermutet wird. Diese Erfahrung mag verwundern, gilt doch gerade die Anpassungsfaehigkeit der Software an den jeweiligen Betrieb als wesentlicher Erfolgsfaktor.

Extreme Komplexitaet macht Berater unentbehrlich

SAP-Software wird in so unterschiedlichen Branchen wie der Chemie, der Serienfertigung, Metallindustrie, in Grosshandel und Dienstleistung eingesetzt. Der Umfang und die Universalitaet der Software schaffen eine Komplexitaet, die sich in der Praxis in langen Einfuehrungszeitraeumen und einer staendigen Abhaengigkeit von externen Beratern niederschlaegt.

Die Tabellentechnik soll die Anpassung der Standardsoftware an die Beduerfnisse des jeweiligen Betriebs garantieren. Neben der Tatsache, dass in einem SAP-System ueber 4000 Tabellen existieren, die sich zudem gegenseitig beeinflussen, beinhaltet selbst eine extrem anpassungsfaehige Software immer eine Vorstellung davon, wie ein Betrieb funktionieren soll. Und da gilt eine einfache Regel: Es ist allemal leichter, sich etwa bei der Finanzbuchhaltung dem der Software zugrundeliegenden Funktionsmodell anzupassen, als die Software auf gewuenschte Ablaeufe hinbiegen zu wollen.

Deutlicher formuliert: Wer sich weitgehend am Standardsystem orientiert, kann mit einer schnellen Einfuehrung der Software rechnen. Dort, wo die Software an betrieblichen Ablaeufen ausgerichtet wird, treten Probleme auf. Wer also Schwierigkeiten vermeiden will, wird den Betrieb der Software anpassen.

Der Zwang zu einer Software-orientierten Reorganisation ist nicht unbedingt negativ zu bewerten. Gewerkschaftsnahe Berater wie Andreas Blume von BIT meinen gar, dass darin Chancen fuer die Beschaeftigten liegen koennten (siehe "Computerinformation" 10/94). Probleme beginnen meist dort, wo Berater die Realisierung der SAP- Software mit einem Business-Re-Engineering-Projekt verbinden. Solche Vorhaben, zumal in der Fertigung, beruhen auf Reorganisationskonzepten, die eher die Einfuehrung der Software zum Ziel haben, als die reine Lehre des Business Re-Engineering zu verfolgen.

Dies wird deutlich, wenn man sich mit dem Scheitern von PPS oder CIM-Loesungen beschaeftigt. So hat die Einfuehrung des SAP-Moduls RM- PPS, also der Versuch, die Produktion mittels Datenverarbeitung zu planen und zu steuern, stets zu Problemen gefuehrt. RM-PPS hat vermutlich noch in keinem Betrieb zufriedenstellend funktioniert.

Nur noch Ueberwachung von Lagerbestaenden

De facto wurde RM auf eine einfache Materialverwaltung reduziert; es ging nur noch um die Ueberwachung von Lagerzu- und -abgaengen. Mitunter planten Unternehmen auch noch verbrauchsgesteuert, indem sie Materialien an Mindestbestellmengen banden. So plante und generierte das Programm Lagerbestaende und Bestellanforderungen.

Eine derartige Materialverwaltung liess sich in einem Fertigungsbetrieb ebenso wie in einem Sanitaergrosshandel oder einem Krankenhaus realisieren. Ein Standardprogramm erfuellt hier seinen Zweck, weil sich die funktionalen Ablaeufe der verschiedenen Branchen im Kern gleichen und deshalb durch ein gleiches, der Software zugrundeliegendes Funktionsmodell abbilden lassen.

Mit einer derart reduzierten Materialverwaltung kommen Unternehmen heute nicht mehr aus. Jetzt geht es darum, das in den Lagerbestaenden gebundene Kapital freizusetzen. Die Ziele heissen nun Reduzierung der Lagerbestaende und Durchlaufzeiten sowie termingenaue Bestandsplanung. Das zu erreichen erfordert die Planung und Steuerung der Fertigung. Die Materialdisposition haengt jetzt vom Funktionieren des PPS-Programms ab- und damit auch von der Frage, wie betriebliche Ablaeufe DV-technisch abgebildet werden.

Programme wie Inteps, Miacs oder Copics sind nicht deshalb gescheitert, weil die zugrundeliegenden Algorithmen falsch oder ihr Funktionsumfang unzureichend gewesen waere. Das Konzept dieser Softwareprodukte an sich war nicht stimmig, weil es den Betrieb allein als technisches Gebilde betrachtete. Diesen Mangel muss sich auch das SAP-Modul RM-PPS gefallen lassen.

Mit dieser Loesung soll die Fertigung geplant und gesteuert werden. Sobald die Auftraege disponiert sind, wird Material im Lager reserviert. Dieses kann von jetzt an nur noch fuer den vorgesehenen Auftrag aus dem Lager entnommen werden. Dem Vorarbeiter wird die Befugnis, Material wie auch Personal an den Maschinen zu disponieren, entzogen.

Er muss nicht mehr Material fuer Eilauftraege oder Schnellschuesse "organisieren", da es nur noch Auftraege mit vorhandenem Material gibt. Um diese Funktionsweise durchzusetzen, ist die Realisation von PPS-Programmen immer mit der Errichtung eines "geschlossenen Lagers" verbunden, bei dem Zu- und Abgaenge moeglichst zwangsweise protokolliert werden und die Datenverarbeitung verhindern kann, dass Material entnommen wird.

Als technisches Modell ist eine derart organisierte Fertigung mit angeschlossener Materialverwaltung leicht zu verwirklichen. Es laesst sich auch einfach in einem technischen System - dem Computer - abbilden. R/2 repraesentiert dieses Konzept.

R/3 bildet die Ablaeufe einzelner Branchen ab

Mit der Entwicklung des R/3-Systems scheint SAP das Scheitern des PPS-Ansatzes, das in der unzureichenden Anpassungsfaehigkeit eines einzigen Standardprogramms begruendet ist, einzusehen. Die sogenannten Industrial-Solution-Module fuer Krankenhaeuser, Verlage etc. orientieren sich an branchenspezifischen Ablaeufen.

R/3 ermoeglicht darueber hinaus mit der Einbindung von Windows- Programmen wie Excel oder Access die Entwicklung individueller Anwendungen. Gleichzeitig wird die Abap/4-Workbench verkauft, die Entwicklungsumgebung, mit der Anwender aehnlich wie SAP-Entwickler Programme schreiben koennen.

Dennoch bleibt die Frage: Kann SAP an der Vorstellung eines zentralistischen Konzepts, das Planung und Steuerung durch eine Maschine vorsieht, festhalten? Das Scheitern der PPS-Programme und der CIM-Idee hat seine Ursache in diesem hierarchischen Ansatz. Sie fuehrten zu Reorganisationen, deren Ziel es war, die betrieblichen Ablaeufe einem ungeeigneten Konzept anzupassen.

Business Re-Engineering stellt dagegen den Mitarbeiter in den Mittelpunkt. Man hat erkannt, dass der Betrieb kein allein technisches Gebilde ist und sich deshalb auch nicht durch ein technisches System steuern laesst. Wenn es in die Entscheidungsbefugnis eines Hotelangestellten faellt, auf die Kritik eines Gasts an einem mangelhaften Zimmerservice mit einem Gutschein fuer ein Abendessen zu antworten, dann wird auch dem Vorarbeiter in der Fertigung irgendwann zugestanden, bei der Disposition von Material und Personal mit zu entscheiden. Business Re-Engineering beinhaltet die "Ermaechtigung" des Mitarbeiters.

In zentralistischen Konzepten darf ein Mitarbeiter eine Information erzeugen, jedoch nicht ueber ihre Verwendung und Verarbeitung befinden. In einem SAP-System wird dieser antiquierte Zustand unterstuetzt und darueber hinaus bei jedem Beleg festgehalten, wer diesen zu welchem Zeitpunkt erzeugt hat.

Der einzelne Mitarbeiter kann nicht einmal entscheiden, wie die mit ihm verbundene Information verarbeitet wird. Der Betriebsrat, auch eine zentrale Instanz, muss dann mit der zentralen Instanz des Arbeitgebers verhandeln, dass von ihm nicht gewollte und vom Mitarbeiter befuerchtete Auswertungen ausgeschlossen bleiben.

Der "ermaechtigte Mitarbeiter" dagegen wird seinen "Kunden" die Information zur Verfuegung stellen, die diese benoetigen. In vielen Betrieben fehlt es jedoch an den einfachsten Informationen: Wo haengt ein Auftrag? Wieviel ist zur Zeit fertig? Wann kann er abgeschlossen werden? Die gekauften Programme sind fuer die Loesung solch einfacher Fragen ueberdimensioniert. Sie behindern sogar manches Unternehmen, weil sie in ihrer Komplexitaet und Funktionsvielfalt Bedingungen stellen, die sich in den Betrieben nicht erfuellen lassen. Die Kundenbeduerfnisse in den Informationsbeziehungen werden nur zum Teil oder gar nicht befriedigt.

Die Weitergabe der Information wird an den betrieblichen Prozessen orientiert sein. Es geht um die Vermittlung einfacher, wirklich benoetigter Informationen. Der Kunde wird sie mit seinen Anwendungen verarbeiten. Das werden Programme sein, die die Mitarbeiter in ihrer Arbeit, ihren Entscheidungen unterstuetzen - und nicht entmuendigen. Moeglicherweise werden es mit Abap/4 entwickelte Programme sein, schlank und mit eigener Datenbasis. Das aber funktioniert nur, wenn die SAP-Einfuehrung mit einem echten Business Re-Engineering verbunden wird.

* Jochen Konrad-Klein ist Mitarbeiter der Technologieberatungsstelle Nordrhein-Westfalen in Koeln.