Die Durchfuehrung von Client-Server-Projekten geht oftmals mit der Einfuehrung der SAP-Standardsoftware R/3 einher. Thomas Gutzwiller* ist der Meinung, dass die Software zu Unrecht in Verdacht geraten ist, sie druecke dem jeweiligen Unternehmen ihren ablauforganisatorischen Stempel auf. Vielmehr fehle es vielen Firmen an Know-how darueber, wie das Business Process Redesign die Optionen einer Standardsoftware nutzen koenne.

Vor allem Informatiker argumentieren, der Einsatz von Standardanwendungssoftware wirke einengend und schreibe Ablaeufe zwingend vor. Dieses Argument trifft nach unserer Ansicht fuer Individualentwicklungen zu, kann aber fuer SAP-Software generell nicht bestaetigt werden. Die Probleme bei Prozessimplementierungs- Projekten liegen eher in der mangelnden Kenntnis ueber den neuen Typus des Projektprozesses.

Business Process Redesign, Re-Engineering oder auch Transformation sind vieldiskutierte Management-Themen, ueber die in der Presse sehr polar berichtet wird: Von extremen Erfolgen ist ebenso die Rede wie von katastrophalen Misserfolgen. Fest steht indes, dass Business Process Redesign eine neue Aera des Managements einleitet.

Es ist weniger die prozessorientierte Sichtweise, die fuer diesen Prozess verantwortlich ist; vielmehr haben wir heute Methoden und Techniken, die aus der wissenschaftlichen Disziplin des Software- Engineerings sozusagen rueckwaerts erwachsen sind und heute auf die Restrukturierung von Unternehmen angewendet werden. In der Software-Entwicklung haben sich ingenieurmaessige Methoden zur Erstellung von Informationssystemen durchgesetzt. Zum Business Process Redesign besteht eine Analogie, dieser Bereich entwickelt sich ebenfalls von einer Kunst zu einer Ingenieurdisziplin.

Das St. Gallener Institut fuer Wirtschaftsinformatik spricht in diesem Zusammenhang von Business Engineering. Erst seit kurzer Zeit koennen wir das Geschaeft, ausgehend von einer fixierten Unternehmensstrategie, ingenieurmaessig entwerfen. Dies ist der eigentliche Durchbruch: weg von der intuitiven Reorganisation von Strukturen und Ablaeufen, hin zu einem ingenieurmaessigen Entwurf des Geschaeftssystems.

Aus diesem Grund ist es leicht nachzuvollziehen, dass Promotoren und Exponenten der Arena des Business Process Redesigns wie beispielsweise Michael Hammer, August-Wilhelm Scheer oder Hubert Oesterle erstens aus dem universitaeren Bereich kommen und zweitens einen Informatikhintergrund haben.

Dass wir heute mehr Meldungen ueber Flops von Business-Process- Redesign-Projekten als Erfolgsberichte vernehmen, hat viele Gruende. Auswertungen gescheiterter Redesign-Projekte ergeben, dass ein zu starkes Festhalten am Ist-Zustand, schlechte Informationspolitik waehrend des Transformationsprozesses, mangelndes Management Commitment, ungenuegende Analyse der Kundenbeduerfnisse, ausufernde Analysen von Prozessketten, mittelmaessige Projektmitarbeiter und andere Probleme vorliegen.

Die meisten Projekte verlaufen chaotisch

Dabei ist der Schluesselfaktor fuer das Gelingen eines solchen Vorhabens im Zeitalter von ISO 9000 und Humphreys Prozess- Reifeschema ganz eindeutig: Der Prozess des Business Process Redesigns selbst muss beherrscht werden. Dies ist leider oft nicht der Fall. Wuerden alle Projekte anhand von Humphreys Prozess- Reifeskala bewertet, kaemen wir zu dem Schluss, dass sich die meisten Projekte auf der initialen, unorganisierten, sogenannten chaotischen Ebene bewegen. Der Projekterfolg wird zu einem Lotteriespiel und haengt weitgehend von den Persoenlichkeiten ab, die daran mitarbeiten. Verschiedene universitaere Einrichtungen und Unternehmensberatungen haben diesen Mangel erkannt und arbeiten heute an Projektprozessmodellen, die den Redesign-Prozess ingenieurmaessig strukturieren. Handelt es sich dabei um Methoden, die in der Projektarbeit mehrfach validiert und optimiert wurden, geraten Redesign-Projekte wesentlich sicherer.

Ein methodisch fundiertes Business Process Redesign fuehrt zu einer konsequenten, ingenieurmaessigen Implementierung der Unternehmensstrategie. Letztere definiert im wesentlichen, welche Produkte auf welchen Maerkten an welche Zielgruppen vermarktet werden. Die Kombination aus Produkt, Markt und Zielgruppe wird "strategisches Geschaeftsfeld", "strategische Geschaeftseinheit" oder aehnlich genannt.

Ein Geschaeftsprozess laesst sich seinerseits durch ein homogenes Buendel von Leistungen identifizieren, das fuer einen externen oder internen Kunden erbracht wird. Eine Leistung ist eine Interaktion zwischen Kunde und Prozess (zum Beispiel ein Prospekt, ein elektronischer Produktkatalog, eine Auftragsbestaetigung, die Ware selbst, ein Service etc.). Der Leistungsaustausch im Rahmen der Kundenbeziehung ist das, was einen Geschaeftsprozess charakterisiert und nicht, wie oft irrtuemlich angenommen wird, die Prozesskette.

Die Leistungen definieren das Was, die Prozesskette schliesslich das Wie. Im ersten Fall sprechen wir von der Prozessmakroebene, im letzteren von der Mikroebene. Dabei kann ein Makroprozess durchaus in mehrere Mikroprozesse zerfallen, die jeweils unterschiedliche Abwicklungsvarianten darstellen. Makroprozesse sind grundsaetzlich zur Fuehrung strategischer Geschaeftsfelder zu etablieren. Dies ist insofern wichtig, als bei einem Prozess-Redesign Geschaeftsfeld- und Prozessfuehrung unbedingt kongruent sein muessen - so wird vermieden, dass sich die Fuehrungsstruktur unnoetig verkompliziert.

Ueblicherweise kommen in mehreren strategischen Geschaeftsfeldern dieselben Prozesse vor, das heisst identische Leistungsbuendel werden unterschiedlichen Zielgruppen durch diverse Geschaeftsfelder erbracht. Die Teile dieser Prozesse, die Gemeinsamkeiten aufweisen, sind zu disaggregieren: Sie lassen sich durch Outsourcing aus den entsprechenden Geschaeftsfeldern zu einem gemeinsamen, "unterstuetzenden Prozess" zusammenfassen.

Kommen wir zur Prozessimplementierung, der Abbildung von Geschaeftsprozessen auf das Informationssystem. Auf der Makroebene sind Geschaeftsprozesse durch die Leistungen charakterisiert, die sie zugunsten ihrer jeweiligen Kunden erbringen. Die Makroebene ist die Fuehrungsebene des Prozesses.

Auf der Mikroebene des Prozessentwurfs interessiert hingegen die Frage, wie die Prozessleistung im Detail effizient erbracht werden soll und, schliesslich, wie die Integration in das computergestuetzte Informationssystem bewerkstelligt wird.

Es geht also um die Gestaltung der Prozesskette und um die Einbindung der administrativen Anwendungen. Die Kette stellt den prozessinternen Ablauf dar. Hier wird im wesentlichen festgelegt, welche Stellen im Unternehmen oder beim Kunden bestimmte organisatorische Aufgaben uebernehmen und in welcher Reihenfolge diese ablaufen.

Das besondere Augenmerk ist hier auf den Entwurf effizienter Prozessablaeufe und auf die optimale Integration in das computergestuetzte Informationssystem zu richten. Fuer die erste Frage ist ein Branchenvergleich beziehungsweise -Benchmarking ein adaequates Instrument. Die zweite Frage laesst sich durch einen sauberen methodischen Ansatz loesen.

Beispielsweise wird in dem St. Gallener Ansatz "Promet SSW" die Strategie verfolgt, Mikroprozesse aus standardisierten, wiederverwendbaren Geschaeftsvorfaellen zu montieren. So lassen sich bei einer Prozessvielfalt auf der Mikroebene maximale Synergiegewinne bezueglich des Informationssystems erzielen. Ein solcher Geschaeftsvorfall ist eine computergestuetzte standardisierte Aufgabe, die jeweils von einem Mitarbeiter zu einem bestimmten Zeitpunkt an einem bestimmten Ort wahrgenommen wird. Es ist auch moeglich, dass ein Geschaeftsvorfall im Batch- Verfahren vollstaendig automatisiert, das heisst ohne Benutzerinteraktion ablaeuft.

Geschaeftsvorfaelle beinhalten selbst mehrere Arbeitsschritte, die manuelle Aktionen, Kontrollverfahren, Formulare, Belege, Listen, Berichte, Online-Transaktionen, Batch-Ablaeufe oder Buerokommunikations-Produkte und anderes kombinieren. In der Modellierung ist darauf zu achten, dass sich ein hoher Grad an

Wiederverwendbarkeit von Geschaeftsvorfaellen erreichen laesst. Die Geschaeftsvorfaelle selbst sind die "Building Blocks", aus denen Prozesse montiert werden. Sie sind auch die Einheiten, auf denen Mitarbeiter, die das Geschaeft spaeter operativ betreiben, ausgebildet werden.

Welche Beziehung besteht nun zwischen Prozess und Informationssystem? Wie bereits erwaehnt, beinhalten einzelne Geschaeftsvorfaelle bestimmte Online-Transaktionen oder Batch- Ablaeufe. Diese sind Bestandteil administrativer Anwendungen, die im bestehenden Informationssystem existieren und gegebenenfalls modifiziert werden muessen, neu im Rahmen eines Entwicklungsprojekts erstellt werden oder im Rahmen einer Standardsoftware-Einfuehrung, zum Beispiel mit SAP R/3, parametrisiert werden.

Prozesse bestehen aus Geschaeftsvorfaellen

Wir muessen die Betrachtung in Zukunft aber noch weiter spannen: Fuer bestimmte hochstandardisierte und hochvolumige Mikroprozesse werden wir elektronische Formulare, Document Image Processing mit Intelligent Character Recognition, Dynamic Data Exchange, Screen- Scrapping etc. im Rahmen der Geschaeftsvorfall-Bearbeitung einsetzen sowie die Prozessabwicklung mit Workflow-Management- Systemen unterstuetzen.

Wie bereits ausgefuehrt, bestehen Prozesse aus Geschaeftsvorfaellen, die ihrerseits Online-Transaktionen und Batch-Ablaeufe verwenden. Drei Arten der Implementierung von Transaktionen, die im Rahmen der Geschaeftsvorfall-Bearbeitung verwendet werden, sind zu unterscheiden:

- die Verwendung oder Weiterentwicklung des bestehenden Informationssystems;

- die Neuentwicklung von Transaktionen mit einer entsprechend neuen darunterliegenden Datenbasis oder

- der Einsatz administrativer Standardanwendungssoftware.

Wesentlich ist dabei, dass es sich eigentlich nicht um die Implementierung des Prozesses, sondern von Online-Transaktionen und Batch-Ablaeufen dreht, die im Rahmen von Geschaeftsvorfaellen in einen Mikroprozess eingebunden sind. Daher ist es aus prozessorientierter Sicht nicht legitim, generell gegen Standardanwendungssoftware zu argumentieren. Im Prinzip geht es in dieser Diskussion nicht um Prozesse, sondern um die Bereitstellung optimaler Online-Transaktionen und Batch-Ablaeufe. Die Standardsoftware selbst liefert keine fertigen Prozessablaeufe, denen man sich unterwerfen muss. Diese Argumentation waere nur dann korrekt, wenn die Anwendungssoftware keine Parametrisierungs- Moeglichkeiten fuer das Customizing von Transaktionen bietet. Ist das der Fall, dann wurde die Software zu spezifisch entwickelt - mit irgendeinem Geschaeftssystem im Hintergrund, fuer das man die Software konzipiert und realisiert hat. Es ist ein Irrglaube, mit einer hoch parametrisierbaren Standardsoftware wie R/3 wuerden Prozessablaeufe und Geschaeftsvorfaelle vorgeschrieben.

Unsere Erfahrungen in der Diskussion um Standardanwendungssoftware gehen in eine ganz andere Richtung. Wir coachen umfassende Business-Process-Redesign- und -Implementierungs-Projekte, in denen die Prozesse - ausgehend von einer Neudefinition der Unternehmensstrategie - neu strukturiert und implementiert werden. Die "Strategieentwicklung" beansprucht zirka drei Monate. Fuer die Prozessentwicklung, das heisst Prozessmakro- und -mikroentwurf, und die anschliessende Implementierung der Prozesse werden nochmals rund zwoelf Monate veranschlagt.

Nach ungefaehr 15 Monaten kann also eine "neue Firma" implementiert sein. Aus der Sicht der Geschaeftsleitungen ist ein schneller Implementierungsprozess wichtig, da sich das Unternehmensumfeld rasch wandelt. Die organisatorische Transitionsphase, die Unsicherheiten fuer alle Mitarbeiter bringt, soll so kurz wie moeglich gehalten werden. Wir wissen, dass wir das Zeitziel mit einer Neuentwicklung des Informationssystems auch mit der besten CASE-Technologie oder objektorientierten Werkzeugen niemals erreichen koennen, wenn wir "from Scratch" anfangen.

Wir muessen fast zwangsweise auf Standardsoftware zurueckgreifen, und zwar auf eine mit hervorragenden Customizing-Faehigkeiten und einer angemessenen Entwicklungsumgebung, um individuelle Transaktionen, Belege, Listen und Berichte selbst zu erstellen. Auch in aeusserst schwierigen Faellen ist es uns immer wieder gelungen, unpassende Funktionalitaet zu isolieren und mit den Entwicklungswerkzeugen der Standardanwendungssoftware diese Funktionalitaet entsprechend den Beduerfnissen neu zu bilden.

Durch dieses Verfahren, das Modifikationen an der Software verhindert, bewahrt man sich die Release-Faehigkeit. In Industrie und Handel, wo die Software haeufig zum Einsatz kommt, hat sie meistens die Funktion einer Werkbank. Geschaeftsvorfaelle lassen sich rasch implementieren, um sie spaeter im Rahmen des Prozess- Prototypings zu integrierten Prozessen zu montieren.

Die Erfahrung zeigt, dass es keinen Sinn macht, den Prozessmikroentwurf und die Geschaeftsvorfall-Modellierung im Detail anzugehen, bevor das Projektteam Kenntnisse ueber die moegliche Funktionalitaet und die Customizing-Faehigkeiten der einzusetzenden Software besitzt. Hier lauert die Gefahr, dass Geschaeftsvorfaelle konzipiert werden, die sich nur mit einem ueberproportionalen Aufwand auf das Standardsoftwaresystem abbilden lassen, und andere, wesentlich einfachere Wege unentdeckt bleiben. Aus genau diesem Grund haben sich schon manche Projekte grosse Zeitverluste eingehandelt.

Zusammenfassend laesst sich sagen, dass eine hochparametrisierte Standardsoftware das gegenwaertig geeignetste Vehikel zu sein scheint, um eine "neue Firma" gemeinsam mit dem Kunden und innerhalb kuerzester Zeit im Rahmen eines umfassenden Business Process Redesigns zu implementieren. Dass das Werkzeug dabei oft R/3 heisst und Abap/4 zu den proprietaeren Sprachen gehoert, ist im Prinzip sekundaer - auch wenn es fuer den Informatiker hart ist.

Wichtig scheint uns, ein adaequates Vehikel zu haben, mit dem sich der Wandel auch auf der Ebene des Informationssystems schnell vollziehen laesst, so dass sich eine ausreichende Nutzungsdauer ergibt, bis sich die Firma aus marktbedingten Entwicklungen wieder transformieren muss.

Wir leben heute im Zeitalter von ISO 9000 und der Prozessorientierung. Die Entwicklung ist positiv, bringt sie doch sehr viel Transparenz ins Geschehen. Es ist deshalb erschreckend, mit welcher Naivitaet und mit wie wenig Verstaendnis die Abwicklung solch ehrgeizige Projekte oft in Angriff genommen werden. Generelle Projekt-Management-Prinzipien zu beherrschen reicht nicht aus. Eine umfassende Prozessimplementierung mittels Standardanwendungssoftware ist (fast) so anspruchsvoll wie ein grosses Neuentwicklungsprojekt.

Fuer den letzteren Fall haben wir in der letzten Dekade mit dem Aufkommen von integrierten Entwurfsmethoden und -werkzeugen erhebliche Fortschritte erzielt. Denselben Massstab muessen wir auch fuer den Business-Process-Redesign- und den Standardsoftware- Einfuehrungsprozess anlegen. Der Misserfolg vieler Projekte laesst sich darauf zurueckfuehren, dass dieser Tatsache heute noch nicht genuegend Rechnung getragen wird.

Hierzu ist in aller Deutlichkeit festzuhalten: Die Standardsoftware trifft am Scheitern der Projekte die geringste Schuld. Vielmehr gilt es heute, das Redesign-Projekt auf Basis von Standardsoftware zu beherrschen. Die Antwort sind klare, validierte und selbstoptimierte Projekt-Prozessmodelle.

Literaturhinweise

[1] Hammer, M., Champy, J.: Reengineering the Corporation. Harper Business, New York, 1993.

[2] Scheer, A.-W.: Wirtschaftsinformatik: Referenzmodelle fuer industrielle Geschaeftsprozesse. 4. Auflage, Springer, Berlin e. a., 1994.

[3] Oesterle, H.: Business Engineering: Prozess- und Systementwicklung. Band: Entwurfstechniken. Springer, Berlin e. a., 1995.

* Privatdozent Dr. Thomas Gutzwiller ist geschaeftsfuehrender Partner der IMG - Information Management Gesellschaft, St. Gallen und Muenchen, sowie Dozent fuer Betriebswirtschaftslehre an der Hochschule St. Gallen.