Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.


22.09.1995

Software-Strategien/Mythos BPR - Versuch einer Entzauberung (Teil 2) Business Process Re-Engineering - alter Wein in neuen Schlaeuchen

In einer fuenfteiligen Artikelserie beschaeftigt sich Friedrich von Loeffelholz mit dem Thema Geschaeftsprozess-Re-Engineering. Der erste Teil stellte die Schluesselfragen, die sich aus diesem Schlagwort ergeben. Im zweiten Beitrag wagt der Autor die These, dass es sich dabei oft nur um einen zweiten Aufguss laengst bekannter Ziele handelt. Der dritte Artikel wird den alten Gegensatz zwischen Individual- oder Standardsoftware in ein neues Licht ruecken, worauf im vierten Teil eine Wirtschaftlichkeitsbetrachtung folgt. Geschaeftsprozess-Re-Engineering als Chance zum Lean Office soll der Gegenstand des fuenften und letzten Beitrags heissen.

Von Friedrich von Loeffelholz*

Das Modewort Geschaeftsprozess-Re-Engineering bezeichnet eine laengst bekannte Sache: die Ueberarbeitung der Ablauforganisation. Etwas hat sich allerdings geaendert. Frueher konnten die Unternehmen ihre Prozesse frei gestalten, heute sind sie an die Vorgaben ihrer Standardsoftware gebunden.

Lean Production hiess die in den vergangenen Jahren oft praktizierte Strategie, um den Abbau von Fertigungskapazitaeten durchzusetzen. Durch Lean Production liess sich die Effizienz der Produktion weiter steigern, und dadurch wurden Fertigungskosten eingespart. Eines blieb aber unerreicht: die Verschlankung des staendig wachsenden Verwaltungsapparats. Der Abbau von Verwaltungskapazitaet faellt den Unternehmen viel schwerer als der Abbau von Fertigungskapazitaet. Oft entsteht sogar der Eindruck, je schlanker die Produktion wird, umso dicker wird die Verwaltung.

Die Begruendung aus den Bueroetagen ist schwer widerlegbar: Um den Herausforderungen der modernen Logistik gerecht zu werden, benoetigen wir mehr Information als bisher. Auf keinen Fall koennen wir auf ohnehin schon knappe Personal- und Sachmittel verzichten.

Die Welle des Geschaeftsprozess-Re-Engineerings ist fuer das Management nun ein willkommener Anlass, gegen den immer aufwendigeren Verwaltungsapparat anzugehen. Nach dem Motto: Was in der Produktion erreicht werden konnte, muss sich doch auch in der Verwaltung durchsetzen lassen.

Woertlich uebersetzt heisst Re-Engineering eigentlich Zurueck- Entwicklung. In diesem Fall sollen aufgeblaehte und komplexe Verwaltungsprozesse reduziert werden. Doch wie laesst sich ein solches Geschaeftsprozess-Re-Engineering konkret durchsetzen?

Erfahrene Marktbeobachter halten das Business Process Re- Engineering (BPR) fuer alten Wein in neuen Schlaeuchen. Frueher hiess das schlicht und einfach Ueberarbeitung der Ablauforganisation. Im Kern haben diese Kritiker recht. Ein Geschaeftsprozess ist in der Tat nichts anderes als der ganzheitliche Durchlauf eines Auftrags durch die gesamte Unternehmenslogistik.

Nur in einem Punkt laesst sich der Status quo nicht mit vergangenen Zustaenden vergleichen: Frueher war der vorwiegend manuell gefuehrte Ablauf frei gestaltbar. Heute ist er von den Gesetzmaessigkeiten der Software vorgegeben. Denn in den 80er Jahren haben viele Unternehmen zur Unterstuetzung ihrer Ablauforganisation integrierte Standardpakete eingefuehrt. Die Folge war eine voellige Umgestaltung der vorhandenen Organisation. Heute erscheinen Software und Organisation mehr denn je miteinander verwoben.

Die Verwaltung zehrt viele Einsparungen auf

Ziel der Standardsoftware-Einfuehrung war es, die Durchlaufzeiten zu verkuerzen, die Kapazitaetsauslastung zu erhoehen, die Bestaende zu reduzieren und trotzdem das leidige Problem der Termintreue zu loesen. Das alles sollte mit Computer-integrated Manufacturing (CIM) erreicht werden.

Erkauft wurde die Computer-integrierte Fertigung mit erhoehtem Personaleinsatz fuer die Bedienung der neuen Systeme. Dahinter stand naemlich zwangslaeufig die Pflege einer Unmenge von Daten. Es draengt sich der Verdacht auf, dass ein Grossteil des erhofften Einsparungspotentials durch zusaetzlichen Verwaltungsaufwand aufgezehrt wurde. Ob die urspruenglich angestrebten Ziele erreicht wurden, ist zudem zweifelhaft.

Wie konnte es zu dieser Fehlentwicklung kommen? Anfang der 80er Jahre waren die selbstgestrickten Anwendungsprogramme nicht mehr in der Lage, den gestiegenen Informationsbedarf der Fachabteilungen zu decken. Durch die CIM-Euphorie war die Erwartung an die Datenverarbeitung in den Himmel gewachsen. Man sprach von der glaesernen Fabrik, der mannlosen Schicht, der voelligen Automatisierbarkeit durch totale Integration.

Die DV-Abteilung kam den Anforderungen aus den Fachabteilungen nicht mehr nach. Fuer noch so kleine Anpassungsprogramme an die Cobol-Ruinen stellte die DV-Kostenstelle grosse Summen in Rechnung.

Andere Firmen hatten sich zwischenzeitlich fuer - wie man dachte - viel kostenguenstigere Standardsoftware entschieden. Dadurch wollten sie sich aus der Abhaengigkeit von der eigenen DV-Abteilung befreien. Die Weiterentwicklung der selbstgestrickten Programme wurde eingestellt.

Das erklaerte Ziel lautete: mit fertiger Standardsoftware auf einfache Weise die gestiegenen Anforderungen der Fachabteilungen erfuellen und den Schritt in Richtung CIM vollziehen. Zusammen mit externen Spezialisten wurde ein PPS-Projekt aufgesetzt. In der Folge analysierte man das Unternehmen, man erstellte ein Sollkonzept, ermittelte die Anforderungen an das neue System und schrieb ein moeglichst vollstaendiges und umfangreiches Pflichtenheft.

Nach der Vorauswahl legten die Verantwortlichen das Pflichtenheft dann unterschiedlichen Systemhaeusern vor. Sie entschieden sich fuer das Produkt, das die groesste Zahl von Anforderungen erfuellte und die meisten Installation nachweisen konnte - um so sicherer, wenn dahinter auch noch ein potenter Anbieter stand.

Erst als es an die Einfuehrung des neuen Systems ging, wurde der immense Aufwand deutlich, der fuer die Bedienung des Systems erforderlich war. Mit der Installation eines Softwareprodukts war die CIM-Idee noch lange nicht verwirklicht. Ploetzlich musste

- jeder Auftrag - und sei es auch ein noch so kleines Ersatzteil - erfasst,

- jeder Lagerzu- und -abgang gebucht,

- jeder Ausfall von Personal oder Kapazitaet nachgehalten,

- jedes Werkzeug eingegeben und den Maschinen zugeordnet werden.

Diese Liste zwanghafter Datenerfassung laesst sich beliebig fortzusetzen.

Nach dieser Erfahrung wurden die Fachabteilungen unzufrieden. Mit einem derartigen Reorganisationsaufwand hatten sie nicht gerechnet. Um den Mehraufwand in Grenzen zu halten, versuchten die Applikationsspezialisten, die Software an das Unternehmen anzupassen. Dadurch stiegen aber die DV-Kosten weiter, anstatt zu sinken. Und schliesslich wurde kurzerhand die gesamte DV-Abteilung ausgegliedert. Dabei glaubten die Unternehmen, sich derselben Strategie bedienen zu koennen, die sie bereits bei der Lean Production praktiziert hatten: Verlagerung von ueberfluessigen Kapazitaeten nach aussen. Doch dieser Schuss ging nach hinten los. Zwar gibt es in vielen Unternehmen keine interne Kostenstelle DV mehr. Doch kommen die Rechnung statt dessen von draussen - und zwar mit gesalzenen Preisen. Den Fachabteilungen ist das egal. Soll sich doch das Management mit den Notwendigkeiten des hochkomplexen Systems auseinandersetzen! Soll sich doch der Einkauf darum kuemmern, wo er die Systemspezialisten herbekommt!

DV-Leute nehmen die Sache wieder selbst in die Hand

Dutzende von Firmen schreiben jedes Wochenende Stellen aus, weil sie mit derselben Software ihre liebe Not haben. Die Situation in den Unternehmen ist erschreckend. Zwischen Fachabteilung und Systemspezialisten tobt ein bisher nicht gekannter Grabenkrieg.

Die urspruengliche CIM-Euphorie ist mittlerweile in der Lautlosigkeit versunken. Die ach so hochgelobten Systeme haben bei weitem nicht das gehalten, was Systemhaeuser und Berater versprochen hatten. Verursacht werden die aktuellen Probleme durch sehr komplexe und ineffiziente Geschaeftsprozesse. Es bleibt den DV-Fachleuten nichts anderes uebrig, als die Sache wieder selbst in die Hand zu nehmen.

Zu diesem Zweck wird allenorts das Geschaeftsprozess-Re-Engineering in Angriff genommen. Solche Projekte stehen unter dem Motto: weg von komplexen Systemen hin zu einfacheren Anwendungen.

Die Forderung nach schlankeren Ablaeufen, auch in der Verwaltung, stellt den in das Korsett einer vorgefertigten Software gepressten Anwender aber vor eine neue Aufgabe. Er muss die Ablauforganisation, die in die Regeln und Gesetze der Software gegossen ist, komplett in Frage stellen.

Aber wie kann er sich aus den Fesseln der vorgegebenen Programme befreien und sich auf die wirklich wertschoepfenden Prozesse beschraenken? Und wie lassen sich aufwendige Bedienfunktionen eliminieren? Zunaechst sollten sich die Unternehmen folgende Fragen stellen: Muss wirklich fuer jedes noch so unbedeutende Teil ein kompletter Teilestammsatz erfasst werden? Ist fuer jede winzige Aenderung eine neue Stueckliste notwendig? Braucht es fuer jede Anpassung des Fertigungsauftrags einen neuen Arbeitsplan?

Die starren und zeitfressenden Grenzen zwischen den Abteilungen sollten ueberwunden werden, indem die Auftraege fliessend durch das Unternehmen, auch durch die Verwaltung, wandern. Zudem muss die aufwendige und kostenintensive Pflege ueberfluessiger Daten wegfallen. Dazu ist aber die von den Softwarepaketen vorgegebene Zwangssteuerung aufzubrechen. Last, but not least ist es notwendig, komplexe Programme in kleine Vorgangsbearbeitungen zu zerschlagen.

Mit Hilfe des elektronischen Workflow-Managements wollen die Unternehmen Auftragsmappen ueber das Client-Server-Netz von Sachbearbeiter zu Sachbearbeiter uebertragen. Dabei soll nicht der Rechner, sondern der Anwender den Ablauf bestimmen. Wie aber koennen diese Forderungen realisiert werden?

Nach ihrer Auffassung von einfachen Systemen befragt, geben die in- oder externen Spezialisten stets die lakonische Antwort: Wenn das System konsistent bleiben, die Buchhaltung funktionieren und die Auswertungen stimmen sollen, muessen selbstverstaendlich alle Daten eingegeben und alle Ablaufaenderungen im System nachhalten werden.

Dabei stoesst das Re-Engineering-Projekt aber schnell an die Grenzen der eingesetzten Software. Das Unternehmen kann sich nun entweder mit diesen Grenzen abfinden oder auf die Suche nach einem neuen, fuer das Business Process Re-Engineering geeigneten System machen.

Hier stellt sich eine alte Frage mit neuer Brisanz: Mit welcher Softwarestrategie lassen sich die unternehmensspezifischen Geschaeftsablaeufe gezielt unterstuetzen, ohne dass dabei auf die notwendigen Informationen verzichtet werden muss? Gibt es auf dem Markt inzwischen fertige Pakete, mit denen der Verwaltungsaufwand reduziert werden kann? Oder muss das Unternehmen wieder eigene Wege gehen, um dem Informationsbedarf der Fachabteilungen gerecht zu werden?

Angesichts der bitteren Erfahrungen mit kostspieligen und verworrenen Individualentwicklungen begibt man sich lieber auf die Suche nach einer fertigen Loesung. Vielleicht lag es ja doch an der falschen Software. (wird fortgesetzt)

* Professor Dr. Friedrich Frhr. von Loeffelholz lehrt an der Fachhochschule Wuerzburg/Schweinfurt/Aschaffenburg im Fachbereich Wirtschaftsingenierwesen. Zudem war er viele Jahre in der Bewertung und Auswahl von PPS-Systemen taetig.