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 wagte der Autor die These, dass es sich dabei lediglich um alten Wein in neuen Schlaeuchen handelt. Der dritte Artikel rueckte den alten Gegensatz zwischen Individual- oder Standardsoftware in ein neues Licht, worauf im vierten Teil eine Wirtschaftlichkeitsbetrachtung folgte. Geschaeftsprozess-Re-Engineering als Chance zum Lean Office heisst der Gegenstand des fuenften und letzten Beitrags.

Von Friedrich von Loeffelholz*

Geschaeftsprozess-Re-Engineering mit vorgefertigter Standardsoftware ist ein Widerspruch in sich. Einfache und angepasste Loesungen orientieren sich immer an den Fertigungssprozessen und jeweiligen Produkten des Unternehmens. Folglich sind sie per definitionem individuell. Die heute verfuegbaren Mittel fuer die Realisierung unterscheiden sich allerdings massgeblich von den Software-Tools der 80er Jahre.

Viele Unternehmen schleusen heute sehr aufwendige und komplexe Geschaeftsprozesse durch die Verwaltungsabteilungen. Verantwortlich dafuer ist die Einfuehrung hochkomplexer und integrierter Softwarepakete.

Die Fachabteilungen fordern mehr Entscheidungsspielraum und Flexibilitaet, um die Abwicklung ihrer Auftraege kundenorientiert optimieren zu koennen. Die Verfechter der integrierten Standardpakete pochen jedoch auf Einhaltung der durch die Software vorgegebenen Regeln, indem sie die Gefahr von Inkonsistenzen in der Datenbasis heraufbeschwoeren. So hat sich bei vielen Anwendern ein tiefer Graben zwischen den Fachabteilungen und den Verfechtern des integrierten Softwarepakets aufgetan.

Die Programmierung individueller Loesungen wurde in den 80er Jahren aufgegeben - aus Kostengruenden. Aber die Einfuehrung von fertigen Standardpaketen hat zu einem mindestens ebenso hohen Aufwand gefuehrt. Der beste Loesungsweg sollte einen wirtschaftlichen Kompromiss zwischen den beiden Extremen Individualloesung und Standardpaket bieten. Dabei sind zunaechst die Kostentreiber der beiden Extreme zu untersuchen.

Aufwand fuer die Analyse: Mit maschinennaher Individualentwicklung lassen sich sehr redundanzarme und effiziente Systeme entwickeln. Dazu ist jedoch im Vorfeld ein hoher Aufwand fuer die Analyse der Anforderungen erforderlich. Beim Einsatz von Standardsystemen hingegen brauchen Anforderungen ueberhaupt nicht erfasst zu werden, weil hier die Funktionalitaet des Systems von vornherein vorgegeben ist.

Aufwand fuer das Design: Wer ein Standardsystem einsetzt und die Anwendung nicht selbst entwickeln will, braucht auch kein Softwaredesign durchzufuehren. Je maschinennaeher hingegen programmiert wird, um so mehr Zeit und Arbeit muessen in das Softwaredesign investiert werden.

Aufwand fuer die Programmierung: Je hoeher die Programmiersprache, desto geringer der Programmieraufwand, aber desto spezialisierter die Entwicklungsumgebung, desto hoeher der Schulungsaufwand und desto weniger Spielraum, um auch extreme Spezialfaelle loesen zu koennen.

Aufwand fuer die Wartung: Systemnahe Sprachen erfordern hier grossen Aufwand. Fertige Anwendungen hingegen muessen eigentlich ueberhaupt nicht gewartet werden. Das uebernimmt der Anbieter, indem er regelmaessig neue Releasestaende herausgibt.

Aus dieser Zusammenfassung laesst sich auf den ersten Blick der Schluss ziehen, es sei Unsinn, ein System selbst zu entwickeln. Aber beim Einsatz von Standardsystemen muessen Aufwendungen beruecksichtigt werden, die bei individuellen Systemen ueberhaupt nicht auftreten oder zumindest kaum ins Gewicht fallen.

Aufwand fuer Beratung: Standardsysteme passen fast nie hundertprozentig in die vorhandene Organisation. Um festzustellen, wie die Organisation veraendert und das System konfiguriert werden muessen, ist im Vorfeld ein hoher Beratungsaufwand zu treiben. Individuelle Systeme hingegen fordern kaum Beratung, weil sich hier das System voellig an die Organisation anpasst.

Schulungsaufwand: Einfache Programmiersprachen wie Assembler und Cobol lassen sich sehr leicht lernen. Um die Zusammenhaenge komplexer Standardsysteme einigermassen zu beherrschen, sind jedoch viel Schulung und jahrelange Erfahrung notwendig. Erst dann kennt der Anwendungsexperte die Schlichen und Tuecken des Systems.

Aufwand fuer die Einfuehrung: Die Systemeinfuehrung ist bei Standardpaketen sehr viel aufwendiger als bei Individualsystemen. Selbsterstellte Loesungen passen sich harmonisch in die Anwendungsumgebung ein, waehrend bei den Standardsystemen kostspielige Umstrukturierungsmassnahmen ergriffen werden muessen, um die Organisation an das System zu adaptieren.

Anpassungsaufwand: Wo es nicht moeglich ist, die Organisation an das System anzupassen, muss das System an die Organisation adaptiert werden. Solche Anpassungsmassnahmen sind bei hochkomplexen Standardpaketen sehr viel schwieriger als bei einfachen und flexiblen Entwicklungsumgebungen.

Wuerden die Entwickler ihre Anwendungen rein in Maschinencode (Nullen und Einsen) schreiben, so haetten die Unternehmen maximale Flexibilitaet und minimalen Schulungsaufwand. (0 und 1 versteht jeder sofort.) Aber Analyse, Design, Programmierung und Wartung wuerden viel Zeit und Arbeit verschlingen.

Bei Assembler sinkt der Programmieraufwand drastisch. Analyse, Design und Wartung bleiben jedoch aufwendig. Als Vorteil waere allenfalls zu werten, dass Assembler als maschinennahe Sprache die Voraussetzung fuer sehr effiziente Anwendungen liefert.

Eine Sprache der dritten Generation verringert den Programmieraufwand im Vergleich zu Assembler noch einmal. Damit lassen sich effiziente kaufmaennische Anwendungen schreiben, wenngleich bei den prozeduralen Sprachen das Wartungsproblem nicht einfach zu loesen ist. Zusaetzlich erfordert beispielsweise Cobol mit seinen rund 300 Befehlen schon einen gewissen Schulungsaufwand.

Am geringsten ist der fuer die Programmerstellung notwendige Aufwand bei den Sprachen der vierten Generation, beispielsweise bei SQL, sowie bei objektorientierten Sprachen und CASE-gestuetzten Programmgeneratoren. Ausserdem unterstuetzen solche Sprachen auch die Analyse und das Design. Bei durchschnittlich 2000 bis 3000 Objekten in den Klassenbibliotheken muss der Anwender jedoch erstmals auch fuer den Umgang mit den Tools die Leistungen erfahrener Berater in Anspruch nehmen.

Zur juengsten Generation der Progammierhilfen im eigentlichen Sinn zaehlen die fertigen Softwarebausteine, mit denen sich individuelle Loesungen zusammensetzen lassen. Indem diese Komponenten bereits einen Teil der gewuenschten Funktionalitaet abdecken, verringern sie den Programmieraufwand noch weiter. Auch Analyse und Design werden auf diese Weise reduziert. Dabei bleibt zudem ein hohes Mass an Flexibilitaet erhalten. Ohne Beratungs- und Schulungsaufwand kommt das Unternehmen hier jedoch nicht mehr aus.

Eine Kategorie fuer sich bildet die Componentware. Darunter fallen Software-Tools wie PC-Datenbanken, Tabellenkalkulation, Mail- Systeme und Adressverwaltungen sowie kleine Anwendungen wie Fuhrpark-, Leergut- oder Werkzeugverwaltung. Fuer den Anwender bedeuten diese Softwarebausteine noch weniger Aufwand fuer Analyse und Design. Ausserdem lassen sich die Komponenten beispielsweise via OLE recht einfach miteinander verbinden. Allerdings wird hier allmaehlich die Komplexitaet zum Problem. "Office" von Microsoft verfuegt zum Beispiel ueber zigtausend Funktionen.

Noch eine Stufe hoeher finden wir die Anwendungssysteme: Teilanwendungen decken ganze Funktionsbereiche - beispielsweise Finanzbuchhaltung, Warenwirtschaft, PPS, Leitstaende oder Personalverwaltung - ab. Der Programmierungsaufwand geht hier gegen Null. Erstmals kommt es aber zu einem erheblichen Aufwand fuer die Einfuehrung, denn diese Systeme sind in sich geschlossen und daher schnittstellenintensiv.

Den Anspruch, alle Anforderungen mit einem System abzudecken, erheben die integrierten Maximalsysteme: Wenn dort - wie versprochen - bereits alle Funktionen vorhanden sind, benoetigt der Anwenderbetrieb theoretisch weder Analyse noch Design, geschweige denn Programmierung. Und der Anbieter uebernimmt die Wartung.

Aufgrund ihres grossen Umfangs sind diese Maximalsysteme jedoch extrem beratungs-, schulungs- und einfuehrungsintensiv. Die Funktionsvielfalt nimmt den Anwendern jede Flexibilitaet, presst sie mithin in ein enges und starres Softwarekorsett. Zwar entfaellt die Programmierung, aber sie wird durch eine mindestens ebenso aufwendige Anpassung ersetzt. Und dabei muss der Anwender genauso umstaendlich agieren, als wenn er nach Altvaeter Sitte in Maschinencode programmieren wuerde.

Die Einfuehrung von Standardsystemen erfordert also - neben dem ohnehin hohen Aufwand fuer die Datenpflege - auch noch Zeit und Geld fuer Beratung, Schulung, Einfuehrung und Anpassung. Andererseits verschlingt die Entwicklung von individuellen Systemen unvertretbar hohe Kosten fuer Analyse, Design, Programmierung und Wartung. Also stellt sich die Frage, wo der richtige Kompromiss zwischen diesen beiden Extremen zu suchen sei.

Legt man die Aufwandskurven fuer die Eigenentwicklung und die Einfuehrung von Standardpaketen uebereinander, so stellt man fest, dass auch hier der richtige Weg in der ausgewogenen Mitte liegt. Nach dem heutigen Stand der Software-Entwicklung wird das Aufwandsoptimum durch den Einsatz leistungsstarker Software- Entwicklungswerkzeuge beziehungsweise den Einsatz von kleinen anwendungsnahen Softwarebausteinen erzielt.

Dabei vermindern sich die Nachteile der aufwendigen kompletten Eigenentwicklung, aber auch die Schwierigkeiten, die bei der Einfuehrung eines starren Standardpakets auftreten. Kurz gesagt: Die Vorteile der Individualsoftware bleiben weitgehend erhalten, und ihre Nachteile werden teilweise aufgehoben.

Geschaeftsprozess-Re-Engineering fuehrt dazu, sich der individuellen Software-Entwicklung auf neue Weise zu naehern. Das bedeutet keineswegs, in alte Programmiertechniken zu verfallen. Die neue Individualitaet muss auf dem Einsatz moderner Softwaretechnologie beruhen. Das bedeutet den Schritt zu 4GLs, den Einsatz von relationalen Datenbanken sowie die Nutzung von objektorientierten Programmiersprachen und kleinen vorgefertigten Anwendungsprogrammen in Form von Componentware.

Der Einsatz von anwendungsnahen Softwarebausteinen (zum Beispiel in objektorientierten Entwicklungswerkzeugen) vereint Flexibilitaet und Preisvorteil. Componentware ist sofort einsatzbereit und ueber DDE, gemeinsame Datenbank sowie OLE integrierbar.

Die nicht enden wollende Leistungssteigerung der Hardware bei gleichzeitig sinkenden Preisen hat eine Revolution in der Computerwelt zur Folge. Und die Veraenderungen im Hardwarebereich fuehren immer, wenn auch etwas zeitversetzt, zu einer Veraenderung der Softwaretechnologie. Diese Technologie wird in naher Zukunft massiv auf das Geschaefts-prozess-Reengineering Einfluss nehmen.

Nach den oft negativen Erfahrungen mit hochkomplexen und inflexiblen Standardpaketen gehen fortschrittliche Unternehmen jetzt dazu ueber, wieder individuelle Anwendungen zu bauen oder bauen zu lassen, indem sie eines der vielen kleinen Softwarehaeuser mit der Erstellung von Spezialloesungen beauftragen, die dann ueber eine gemeinsame Datenbank oder ueber OLE miteinander verbunden werden.

Die wirklichen Rationalisierungspotentiale liegen in den Bereichen, in denen sich ein Unternehmen von der Konkurrenz unterscheidet. Durch eine bessere Finanzbuchhaltung oder eine noch ausgekluegeltere Lohn- und Gehaltssoftware lassen sich kaum Wettbewerbsvorteile erarbeiten. Mit neuer Softwaretechnologie sind hingegen individuelle Systeme fuer Vertriebssteuerung, Materialdisposition und Fertigungssteuerung realisierbar. Und in diesen produktnahen Aufgaben liegt die Moeglichkeit fuer Alleinstellungsmerkmale.

Wer glaubt, er koenne Geschaeftsprozess-Re-Engineering mit allgemeingueltiger und allumfassender Software, also ohne die Naehe zur eigenen Produktion, realisieren, giesst in der Tat alten Wein in neue Schlaeuche. Wenn die Hersteller von Standardpaketen ihre Software als Werkzeug fuer das Geschaeftsprozess-Re-Engineering vermarkten, so stellen sie damit einen Widerspruch in sich auf. Geschaeftsprozess-Re-Engineering ist eine grosse Chance fuer das "Lean Office". Wer sie nicht nutzt, wird an seiner Verwaltung ersticken und womoeglich gar nicht merken, dass ihn die Konkurrenz schon lange links und rechts ueberholt hat. Die Anwender sollten notfalls rigorose Massnahmen ergreifen, um ihre weit ueber das Ziel hinausgeschossenen Anwendungen durch einfache und unkomplizierte Loesungen zu ersetzen. Einfache Loesungen konzentrieren sich auf die tatsaechlichen Erfordernisse des Unternehmens. Sie sind spezifisch und individuell, denn sie haengen unmittelbar mit den Produkten und der prozessnahen Herstellung der Produkte zusammen.

Wer Re-Engineering ernst nimmt, weiss, dass er das in der CIM- Euphorie der 80er Jahre gekaufte System zurueck- oder gar abwickeln muss. Ein Schritt zurueck bei der Komplexitaet ist ein Schritt nach vorn in der Sache. Diese Einsicht ist der erste Schritt in Richtung Re-Engineering.

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