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.

17.09.1993 - 

Was die Tools leisten muessen

Die Re-Engineering-Methoden bilden nur den Handlungsrahmen

17.09.1993

Seit Michael Hammer im Sommer 1990 seinen Artikel "Don+t Automate, Obliterate" in der Harvard Business Review veroeffentlichte und damit die Re-Engineering-Welle ausloeste, ist ueber dieses Thema viel geschrieben worden. Dabei ist es nicht nur schwer herauszufinden, wer bei wem abgeschrieben hat, Einsteiger verirren sich auch leicht in der begrifflichen Vielfalt und koennen die Anwendbarkeit der unterschiedlichen Tools kaum richtig einschaetzen. Unter Tools sollen an dieser Stelle diejenigen Werkzeuge verstanden werden, die die Erarbeitung und Dokumentation konzeptioneller Optimierungsloesungen ermoeglichen und beschleunigen. Nicht gemeint sind dagegen Werkzeuge, die eine optimierte Loesung effizient in entsprechende Systeme umsetzen. Solche Tools, wie zum Beispiel CASE-Werkzeuge oder Groupware, sind Hilfsmittel fuer die Umsetzung der eigentlichen Arbeitsergebnisse. Gerade fuer DV-orientierte Mitarbeiter ist der Begriff "Business Process Re-Engineering" in zweierlei Hinsicht problematisch oder vorbelastet. "Re-Engineering" erinnert stark an "Reverse Engineering", also an Techniken der Restrukturierung vorhandener Codes oder vorhandener Datenbanken. Business Process Re- Engineering ist jedoch ein ganzheitlicher Ansatz zur Optimierung funktionenuebergreifender Geschaeftsablaeufe und hat in diesem Sinne nichts mit dem Versuch gemeinsam, "die Zahnpasta wieder in die Tube zu bekommen".Die Charakteristika von Geschaeftsprozessen Auch der Begriff "Process" erscheint besetzt. Konventionell werden unter Prozessen diejenigen Taetigkeiten verstanden, die durch Funktionsdekomposition ermittelt und als kleinste Units of work in Anwendungssystemen implementiert werden. Gerade diese isolierende, hierarchische und Schnittstellen schaffende Sicht auf Taetigkeiten in einem Unternehmen macht zwar aus Sicht der DV-Entwicklung Sinn, widerspricht aber den Grundgedanken des Re- Engineerings.Geschaeftsprozesse sind dadurch charakterisiert, dass sie horizontal Geschaeftsfunktionen und Organisationseinheiten durchlaufen. Sie sind zusammenhaengende Ketten einzelner Taetigkeiten.Die zur Optimierung von Geschaeftsprozessen und die zur Erarbeitung von Anwendungssystemen verwendeten Techniken sind sich aehnlich, die Ergebnisse allerdings nicht immer. Der gemeinsame Kern liegt im Einsatz von Techniken zur Geschaeftsmodellierung, auch wenn die Intentionen beider Ansaetze abweichen.Unterstuetzung der Geschaeftsmodellierung Aus dieser Tatsache laesst sich bereits die erste unabdingbare Forderung ableiten, die man an ein Re- Engineering-Tool stellen muss: Es muss alle Standardtechniken der Geschaeftsmodellierung, wie sie teilweise bereits aus CASE-Tools bekannt sind, integriert, redundanzfrei und intelligent unterstuetzen. Diese Techniken sind insbesondere die Funktionsdekomposition, die Prozesskettenanalyse und Entity-Rela- tionship-Diagramme. Gelegentlich wird versucht, klassische CASE- Tools fuer Re-Engineering-Aufgaben einzusetzen. Ihre Verwendung wird dadurch beschraenkt, dass sie dem Prozesscharakter - der Modellierung funktionenuebergreifender Ketten - nur teilweise gerecht werden. Ausserdem ermoeglichen CASE-Tools im Regelfall nicht die Dokumentation aller relevanten Prozesseigenschaften. In der Praxis zeigt sich dann oft, dass diese Tools nur durch "Verbiegen" ihrer Funktionalitaet sinnvoll eingesetzt werden koennen. Das fuehrt zwangslaeufig zu Wartungs- und Verstaendnisproblemen. Eine besonders hinderliche Beschraenkung liegt auch darin, dass diese Tools aus Konsistenzgruenden nur ueber eingeschraenkte Schnittstellen verfuegen. Auf diesen Punkt werden wir spaeter naeher eingehen.Datenmodellierung wird oft vernachlaessigt Gerade die Datenmodellierung wird in Re-Engineering-Projekten oftmals vernachlaessigt. Nicht nur, dass ihre Bedeutung fuer die Prozessmodellierung ("Welche Informationen benoetigt eigentlich ein Prozess?") unterschaetzt wird. Sie legt auch eine unentbehrliche Grundlage fuer die Erstellung der Systeme, die den optimierten Prozess spaeter einmal unterstuetzen sollen.Weiterhin muss ein Tool in der Lage sein, neben der Ablauf- auch die Aufbauorganisation abzubilden. Die Dokumentation der Verantwortlichkeit und Entscheidungskompetenz der einzelnen Organisationseinheiten fuer den Geschaeftsprozess beziehungsweise dessen Teile sollte in Diagrammform, zum Beispiel in Matrizen, zweifelsfrei dokumentiert werden koennen.Da Re-Engineering-Teams im Regelfall unter starker Einbeziehung der beteiligten Fachbereiche arbeiten, versteht es sich von selbst, dass die Verwendung eines Tools nur ein Minimum an Expertenwissen voraussetzen darf. Insofern gelten fuer die Benutzer-Schnittstelle strengere Anforderungen an die Verstaendlichkeit der Diagramme als bei Verwendung eines CASE- Tools. Alle Eigenschaften muessen abbildbar sein Geschaeftsprozesse definieren sich durch Eigenschaften, die sich zuordnen lassen. Sie besitzen Attribute wie Kosten, Durchlaufzeit, Qualitaet, Frequenz, Wertschoepfung, beteilig- te Organisationseinheiten etc. Selbstverstaendlich muessen diese Eigenschaften sowie deren Einordnung in den betrieblichen Kontext abbildbar sein. Geschaeftsprozesse und ihre Eigenschaften sind allerdings hochgradig unternehmensindividuell (vgl. Abbildung 1). Das gilt um so staerker, je detaillierter das Geschaeftsmodell wird. Wenn man davon ausgeht, dass Geschaeftsprozesse den strategischen Zielvorgaben eines Unternehmens (Kundenorientierung, Kostenfuehrerschaft, Differenzierung) zu folgen haben, diese Ziele jedoch individuell ausgepraegt sind, lautet die logische Konsequenz, dass ein Tool diese individuellen Parameter, die es ja schliesslich zu optimieren gilt, aufnehmen koennen muss. Mit anderen Worten: Der Anwender selbst muss die Moeglichkeit besitzen, benutzerdefinierte Objekte und Prozesseigenschaften hinzuzufuegen.Re-Engineering-Projekte sind kein Selbstzweck. Spaetestens gegen Ende eines Vorhabens sollte man sich die Frage stellen, ob die bestehende DV-Landschaft den Erfordernissen der optimierten Prozesskette gerecht wird oder ob neue Systeme geschaffen werden muessen. Kritischer Blick auf den Modifikationsaufwand Unabhaengig von der zu verfolgenden DV- Strategie muss aus Kosten- und Effizienzgruenden die Forderung nach der Weiterverwendbarkeit der Re-Engineering-Ergebnisse gestellt werden.Bei der Entscheidung fuer neue Systeme stellen sich einige grundsaetzliche Alternativen heraus. Das Unternehmen kann ueberpruefen, inwiefern Standard-software die Prozesserfordernisse erfuellt. Allerdings muss wegen ihres ausgepraegten firmenindividuellen Charakters von einem erhoehten Modifikationsaufwand ausgegangen werden. Dieser muss kritisch evaluiert werden. Eine weitere Alternative bieten neue Methoden, wie sie zum Beispiel durch den Einsatz von Groupware umgesetzt werden. Diese Technologien entsprechen aufgrund ihrer Architektur der oft dezentralen Ausfuehrung und dem funktionenuebergreifenden Charakter der Geschaeftsprozesse. Ob sie allerdings geeignet sind, unternehmensweiten integrierenden Anforderungen zu genuegen, wird die Praxis zeigen muessen. Weiterhin gilt, dass auch Geschaeftsprozesse mitunter ueber starke zentrale und vereinheitlichende Kontrollkomponenten (zum Beispiel Bonitaetspruefung, Monitoring, Zustaendigkeitsregelungen etc.) verfuegen muessen, die der Dezentralisierung naturgemaess Grenzen setzen.In diesen beiden Faellen dienen die redundanzfreien und konsistenten Tool-Arbeitsergebnisse zumindest im Sinne eines Pflichtenheftes der exakten Formulierung der prozess- und informationsseitigen Anforderungen (vgl. Abbildung 2). Diese lassen sich unmittelbar aus den Ergebnissen der Funktionsdekomposition, der Prozess- und der Datenanalyse ableiten.Produktivitaets- und Qualitaetssteigerungen Besondere Produktivitaets- und Qualitaetssteigerungen sind jedoch wegen des individuellen Prozesscharakters im nicht unwahrscheinlichen Fall der Entscheidung fuer Eigenentwicklungen zu erwarten. Insbesondere dann, wenn ein Unternehmen zur Automation der Anwen- dungsentwicklung CASE-Tools verwendet, muessen die Re-Engineering- Ergebnisse unmittelbar weiterzuverwenden sein. Es kann nicht angehen, dass Anforderungen optimierter Prozesse in Re-Engineering- Projekten muehevoll formuliert werden, um anschliessend manuell und fehlertraechtig in CASE-Tools uebertragen zu werden.Entweder man verwendet Tools, die den vollen Entwicklungszyklus ueber Process Re-Engineering bis zur Generierung der Anwendungssysteme integriert abdecken. Oder man stellt mindestens die Anforderung, dass die Ergebnisse ueber eine offene Schnittstelle an CASE-Tools ohne Informationsverlust uebergeben werden.Viele Unternehmen muessen bestehende Altmodelle und neue, optimierte Geschaeftsmodelle in Einklang bringen. Auch hieraus ergibt sich die Notwendigkeit einer offenen Schnittstelle.Zu diskutieren bleibt auf jeden Fall, ob die Ergebnisse der Funktionsdekomposition aus Re-Engineering- und reinen DV-Projekten einander formal entsprechen und ob weitere Ueberarbeitungen erforderlich sind. Da beide Ansaetze unterschiedliche Intentionen verfolgen, kann es nicht verwundern, wenn Ergebnisse aehnlich, aber nicht gleich sind.Aehnliches gilt fuer die Datenmodellierung. Im Normalfall wird am Ende eines Re- Engineering-Projektes kein normalisiertes Datenmodell vorliegen, so dass qualitaetssichernde Massnahmen noetig sind. Bei diesen geistigen Taetigkeiten sind der Automation durch ein Tool natuerliche Grenzen gesetzt.In allen Projekten gewinnt mit der Zunahme der Komplexitaet und der Zahl der beteiligten Analytiker die Sicherstellung der Konsistenz der Arbeitsergebnisse an Bedeutung. Wie kann nun verhindert werden, dass mehrere gleichzeitig an einem Gesamtmodell arbeitende Analytiker untereinander unabgestimmte Arbeitsergebnisse erzielen? Klassisch wird dieses Problem durch die Handhabung manueller Regularien geloest. Da bei Modellaenderungen nicht nur Objekte geaendert werden muessen, sondern auch diejenigen, die darauf referenzieren, laesst sich gut abschaetzen, wie gross man ein Projekt dimensionieren muss, damit es ausschliesslich mit seiner eigenen Verwaltung beschaeftigt ist.Aber auch der Einsatz eines Tools loest dieses Problem nur dann, wenn es die Moeglichkeit bietet, ein Gesamtmodell in mehrere Teile zu zerlegen und diese gleichzeitig zu bearbeiten, um anschliessend die Teile wieder zu einem integrierten Ganzen zusammenzufuegen.Hierbei hat eine Autorisierungsmimik zu gewaehrleisten, dass Analytiker sich nicht gegenseitig Ergebnisse zerstoeren. Deutlich ausgedrueckt: Wenn ein Analytiker Aenderungen an einem Modellteil ausfuehrt, muss das Tool verhindern, dass gleichzeitig ein anderer Analytiker ebenfalls an dieser Stelle Aenderungen vornimmt.Die Abstimmung muss gewaehrleistet sein Die Arbeitsergebnisse der Teamkollegen muessen angezeigt werden koennen, um die Abstimmung untereinander zu gewaehrleisten. So laesst sich auch vermeiden, dass gleiche Sachverhalte in einem Modell mehrfach dokumentiert werden. Nur so sind die Kosten der Modellpflege auf einem vernuenftigen Niveau zu halten. Dass eine derartige Mimik nicht nur die Effizienz steigert, sondern auch unmittelbaren Einfluss auf die Qualitaet des Modells hat, ist offenkundig.Konsistenz- und Integritaetsprobleme werden durch diese Funktionalitaet zu einem Randproblem. Auch entfaellt die Notwendigkeit, Geschaeftsinformationen redundant in verschiedenen Modellen zu halten und zu pflegen. Ausserdem kann von einem Tool Unterstuetzung durch die Bereitstellung formalisierter Konsistenzregeln erwartet werden. Wenn etwa ein Analytiker einen Prozess nicht hinreichend exakt definiert, sollte das Tool eine Warnung geben koennen.Die Moeglichkeit, unterschiedliche Modelle - nicht nur Teilmodelle - zeitgleich zu verwalten, muss als weitere Forderung an ein Tool gestellt werden. In Re-Engineering-Projekten wird es immer mindestens zwei verschiedene Modelle geben. Das eine nimmt den Ist-Zustand auf, dient also der Analyse und der Formulierung der Anforderungen an ein optimiertes System. Das andere Modell dient der Entwicklung der optimierten Geschaeftsprozesse, hat also Soll-Charakter und verfolgt eher "What-if"-Fragestellungen. Es gibt gute Gruende, beide Modelle getrennt zu halten. Andernfalls muesste bei jedem Objekt (beispielsweise Teilprozess) dokumentiert werden, ob es das Ist oder das Soll widerspiegelt. Weiterhin waere ein eindeutiges Entity-Relationship-Diagramm kaum konstruierbar.Offenheit gegenueber weiteren Techniken Die genannten Techniken der Geschaeftsmodellierung bilden vielleicht den Kern von Re- Engineering-Projekten, vollstaendig sind sie jedoch bei weitem nicht. Re-Engineering ist prinzipiell offen gegenueber allen Techniken, die der Sache dienen koennen. Folgerichtig sammeln sich um Re-Engineering-Methoden eine Vielzahl Techniken, die jeweils fuer Analyse und Design einzelner Geschaeftsaspekte - nicht aber aller Facetten - geeignet sind. Die Palette reicht von "Activity Based Costing", "Benchmarking" und Simulationstechniken bis hin zu Kreativitaetstechniken und Ishikawa-Diagrammen. Vielleicht ist die Vielzahl der einzelnen Techniken - jede ist kontextabhaengig berechtigt - einer der Gruende dafuer, dass Automatisierungseffekte, wie man sie aus der methodengestuetzten Entwicklung von Anwendungssystemen kennt, hier nur schwer vorstellbar sind. Tools koennen das Denken nicht ersetzen Re-Engineering-Methoden bilden einen Handlungsrahmen, der durch selektive Verwendung einzelner Techniken unterstuetzt wird. Tools koennen zwar unterstuetzen sowie Produktivitaet und Qualitaet gewaehrleisten, die Ermittlung optimierter Prozesse ist und bleibt aber eine intellektuelle und intuitive Taetigkeit. Es draengt sich die Frage auf, ob ein einziges Tool alle diese unterschiedlichsten Techniken ueberhaupt integriert anwenden kann, oder ob es vielleicht guenstiger ist, ein Tool mit integrierten Kerntechniken zu verwenden, das ueber offene Schnittstellen mit anderen "Best-in-class"-Tools kommuniziert.So ist es zum Beispiel durchaus sinnvoll, alternative Prozessketten Tool-gestuetzt zu modellieren, um dann die Durchlaufzeiten und Ressourcenbelastungen in einem separaten Simulations-Tool zwecks Bestimmung der optimalen Variante zu bestimmen. Der Qualitaet des Geschaeftsmodells ist ein derartiges Vorgehen nicht abtraeglich.Jedes Tool hat seine Staerken und Schwaechen Es sind bereits einige Tools auf dem Markt verfuegbar, so zum Beispiel Workflow Analyzer (C.I.T.), Bonaparte (Ubis), Sparks (C&L) und Business Design Facility (Texas Instruments/James Martin Associates).Die wenigsten erfuellen allerdings die hier geforderten Postulate vollumfaenglich. In der Regel zeigen die Tools entweder hinsichtlich der Weiterverwendbarkeit der Arbeitsergebnisse Schwaechen oder stellen isolierte Inselloesungen mit unzureichender Teamfaehigkeit dar. Da jedes Tool seine Staerken und Schwaechen hat, ist eine sorgfaeltige Evaluierung anhand der geforderten Kriterien unumgaenglich.Reine CASE-Tools bieten zwar gute Ansaetze in der Geschaeftsmodellierung, sind aber fuer die Darstellung ganzer Prozessketten und bezueglich anderer Kriterien unvorteilhaft. Viele der unter der Re-Engineering-Flagge segelnden Werkzeuge leisten nichts anderes als Simulation oder Activity Based Costing und decken somit nur Teilaspekte des Re-Engineering-Ansatzes ab. u* Ralf Borchardt ist Manager bei James Martin Associates, einer Tochter von Texas Instruments. Er leitet in Oesterreich und in Deutschland den Bereich Business Process Engineering

(BPE).

Abb.1: Neben Standardgroessen muessen auch relevante firmenspezifische Werte dokumentierbar sein.