2. Prozeßorientierung und Work-FIow-Management

Vertiefen:
!. Vom
Taylorismus zu
Prozeß-
orientierung und Workflow-
Management

2. Prozeßorientierung
und Work-FIow-
Management

3. Resümee

4. Literatur

In einer Broschüre des Phillipskonzerns aus dem Jahre 1993 wird das Problem der funktionalen Organisation gemäß dem vorhergehenden Kapitel auf den Punkt gebracht:

"Customers expect ever higher quality AND ever faster response AND ever lower costs AND ever better service AND ever higher flexibility. The functional organisation is designed to offer customers ONE of these rather than ALL. There is a competitive edge to be gained by the organisation that does all things better and achieves the best all the time, every time."⁵

Um dies zu erreichen kamen viele neue Management- und Verbesserungsmethoden auf. Dabei ist das wohl radikalste Werkzeug ein völliger Neuaufbau der Strukturen, ausgerichtet an den heutigen Bedürfnissen. Eine totale Abkehr von der traditionellen funktionellen Struktur, und die Schaffung einer prozeßorientierten Organisation. Dabei werden alle Tätigkeiten die an den Kunden gerichtet sind nicht mehr als Zusammenspiel von Abteilungen gesehen, sondern als Geschäftsprozeß. Dies bedeutet eine völlige Abkehr von Smith und Taylor.

Dazu heißt es weiter bei PHILIPS:

Verfechter des Process Managements sind auch der Unternehmensberater Dr. Michael Hammer, Präsident von Hammer and Company, Inc., und der Chairman von CSC Index, Inc., James Champy. Sie begründeten Anfang der 90er Jahre den Begriff "Business Reengineering", und zeigten damit einen Weg hin zur "prozeßorientierten Organisation". Sie vertreten in ihrem Buch zu diesem Thema die These:

Bevor wir zur prozeßorientierten Organisation kommen, sollten an dieser Stelle erst einmal die Begriffe Prozeß und Unternehmens- oder Geschäftsprozeß definiert werden, die hier schon oft gefallen sind, deren genaue Bedeutung aber noch wage offen blieb.

Hier ist eine Reihe von Definitionen:

Wir definieren einen Unternehmensprozeß als Bündel von Aktivitäten, für das einen oder mehrere unterschiedliche Inputs benötigt werden und das für den Kunden ein Ergebnis von Wert erzeugt.

Konkrete Beispiele für Unternehmensprozesse sind unter anderem Auftragsabwicklung, Entwicklungsprozeß, Fertigungsprozeß, oder Informationsverarbeitungsprozeß. Eine genaue Vorgabe für Prozesse im Unternehmen gibt es nicht. Jedes Unternehmen muß die Prozesse definieren, wie sie für sich am sinnvollsten erscheinen. So wäre es mit Blick auf die oben genannten Beispiele auch durchaus denkbar, die Fertigung als Unterprozeß der Auftragsabwicklung zu sehen.

Ziel eines übergeordneten Geschäftsprozeßmanagements (Process Management) ist es immer:

- die Durchlaufzeiten zu verkürzen

Der Begründer des Begriffes "Business Reengineering" oder auch "Business Redesign", Dr. Michael Hammer, entdeckte dieses Phänomen in seiner Tätigkeit als Unternehmensberater. Er betrachtete schlicht diejenigen Unternehmen, die es nach einer Unternehmenskrise am erfolgreichsten geschafft haben wieder den Anschluß an die Spitze zu finden. Dabei stellte er fest, daß es überall die gleichen radikalen Ansätze waren, die schließlich zum Erfolg führten. Und überall kam man von der funktionalen Organisation ab, um zur prozessorientierten Organisation überzugehen.

Die beobachteten Ansätze, Denk- und Vorgehensweisen faßte Hammer nach sorgfältiger Analyse zusammen, und schuf damit ein gewaltiges Instrument zur Strukturoptimierung im bzw. von Unternehmen.

Michael Hammer und James Champy, die zusammen das erste Buch über dieses Thema schrieben, definieren Business Reengineering selbst folgendermaßen:

Dabei sind die folgenden vier Begriffe von herausragender Bedeutung:

• fundamental,
• radikal, und
• Unternehmensprozesse.

Beim Business Reengineering gilt es die fundamentalsten Fragen zu stellen. Der Grundgedanke ist die Suche nach der zeitgemäßen Organisation. Dabei steht die Frage im Vordergrund:

Daher auch das Wort "radikal". Es geht nicht darum, an Bestehendem Verbesserungen vorzunehmen, und dabei nur oberflächlich an den Symptomen zu kurieren. Er geht darum, den Dingen auf den Grund zu gehen, es geht darum, eine Trennlinie zu ziehen, alles Alte zu verwerfen, und völlig neue Wege zu entwickeln. Es geht also um Neugestaltung — sowohl in der Ablauforganisation, als auch in der Aufbauorganisation. Der "way to do business" muß völlig überdacht und umgekrempelt werden. Deshalb muß man sich in der Denkweise des Business Redesign völlig von der Vergangenheit und den bestehenden Abläufe lösen.

Die alte Maxime "process follows structure" wird durch die neue Maxime "structure follows process" ersetzt. Das Unternehmen soll also nicht mehr vertikal, sondern horizontal ausgerichtet werden. Spätestens hier wird offensichtlich in welchem Maße Veränderungen herbeigeführt werden sollen.

Deshalb ist Business Reengineering als eine sehr starke Waffe anzusehen, die zunächst eine große destabilisierende Wirkung zeigt. Es ist ein Werkzeug mit dem man nicht feinsteuern kann - was auch gar nicht erwünscht ist. Man kann jedoch durch einen großen Kahlschlag, durch Zerstörung des Alten und Aufbau von etwas Neuem eine Verbesserung um Größenordnungen erreichen.

Daher ist vom Business Reengineering abzuraten, wenn es ausreicht, bzw. nur Ziel ist, durch kleine Effektivitätsverbesserungen den Anschluß an die Konkurrenz zu halten, oder den Vorsprung leicht zu vergrößern. Man würde sonst Gefahr laufen mit Kanonen auf Spatzen zu schießen, und dabei weniger die Spatzen sondern vielmehr das Unternehmen zu treffen. Aus der sogenannten Zehn-Prozent-Klemme (d.h. das Unternehmen liegt 10% hinter seiner Zielvorgabe) kann sich ein Unternehmen auch durch konventionelle Maßnahmen befreien.

Das Business Reengineering ist die Implementierung von prozeßorientiertem Denken und prozeßorientierten Strukturen.

Dabei sollen die bisherigen Probleme durch abteilungsübergreifende Zusammenarbeit minimiert werden, indem durchgängige Prozesse ohne (oder mit minimalen) Schnittstellen vom Lieferanten bis zum Kunden gestattet werden, und ein Prozeßverantwortlicher bestimmt wird. Dabei wird der Focus auf den Kunden gerichtet. Kunde und Lieferant können hierbei auch unternehmensinterne Kunden sein. Man spricht dann auch von "Prozeßlieferanten" und "Prozeßkunden".

Gegenstand des Business Reengineering sind also ausdrücklich Unternehmensprozesse und nicht Abteilungen. Es liegt daher nahe am Anfang erst einmal die Tätigkeiten einer Unternehmung aus der Ferne zu betrachten, und die elementaren Unternehmensprozesse (Haupt- oder Kernprozesse), also die ureigenen geschäftlichen Aktivitäten herauszufiltern und zu definieren.

Dabei untersucht man verschiedene Geschäftsbereiche, und stellt sich dabei die Frage: Warum machen wir das überhaupt?

Folgende Punkte können bei der Identifikation von Kernprozessen eine wichtige Hilfe sein:

Die Identifikation von Prozessen ist meist nicht ganz einfach, da diese durch die Organisationsstrukturen fragmentiert und versteckt sind. Meist wird zu deren Auffindung und Definition ein Work-Shop gebildet, in dem verschiedene Entscheidungsträger unterschiedlicher Hierarchieebenen zusammenkommen.

Sind die Prozesse dann identifiziert und festgehalten, empfiehlt es sich, zu bestimmen, welche Prozesse neu gestaltet werden sollen, beziehungsweise in welcher Reihenfolge die Prozesse neu gestaltet werden sollten. Aufgrund der vehementen destabilisierenden Wirkung von Process Reengineering ist es nicht ratsam, alle Vorgänge neu zu gestalten, da dies ausweglos ins Chaos führen kann.

Die Frage der Prozeßpriorisierung ist nach Ansicht Michael Hammers keineswegs ein trivialer Teil des Redesign-Vorhabens.

Bei der Auswahl können unter anderem folgende Fragen eine Rolle spielen:

• Bei welchen Prozessen ist die Machbarkeit eines Redesigns am größten, das heißt,
• welcher Prozess-Redesign hat die größten Erfolgschancen?

Wenn schließlich ein Prozeß für das Reengineering ausgewählt wurde, gilt es nun den existierenden Prozeß in allen Einzelheiten verstehen zu lernen und herauszufinden, wie er funktioniert und welche Aspekte ihn maßgeblich beeinflussen. Dabei geht es wirklich nur um das Verstehen des Prozesses. Die entscheidenden Fragen sind: "was?" und "warum?‘, nicht: "wie?". Eine Analyse wird ausdrücklich nicht vorgenommen. Der Prozeß soll ja nicht verbessert, sondern durch einen neuen Prozeß ersetzt werden.

Der beste Ansatzpunkt um einen Prozeß zu verstehen ist laut Michael Hammer wie schon bei der Identifikation der Kunde. Um die kritischen Momente in einem Prozeß verstehen zu können, sollte man sich fragen, wo die Bedürfnisse der Prozeßkunden liegen, und wo die Probleme des Prozeßkunden liegen. Außerdem sollte analysiert werden wofür der Kunde den eigenen Prozeß-Output verwendet. Da es das übergeordnete Ziel des Redesigns ist, eine bessere Abstimmung mit den Kundenwünschen zu erreichen, muß das Reengeineering-Team diese Wünsche sehr genau kennen.

Prozeßverständnis bedeutet, die zugrundeliegenden Ziele und Probleme des Kunden zu kennen, und nicht nur die Mechanismen des Prozesses zu betrachten. Um den Zielen und Problemen der Prozeßkunden auf den Grund zu kommen, rät es sich, diese zu beobachten oder am Prozeß des Kunden zeitweise mitzuarbeiten.

Nur wenn man den Vorgang des Kunden besser kennt als dieser selbst, kann man Lösungen finden, die mehr zum Ziel haben als nur den üblichen Wunsch zu erfüllen, das Bestehende schneller, besser oder billiger zu machen.

Durch Befragung der Prozeßkunden kommt man meist nicht zu Denkansätzen, die vom Bestehenden gelöst sind, da hier meist nur an das Naheliegende gedacht wird. Diese Denkweise wird als deduktives Denken bezeichnet. Deduktives Denken Bedeutet, Probleme zu definieren, zu analysieren, verschiedene Lösungsansätze zu bewerten und eine adäquate Lösung zu bestimmen.

Für Business Reengineering muß allerdings jeder konkrete Bezug zu bestehenden Vorgängen, zu bestehenden Annahmen, Leitsätzen und Regeln aufgegeben werden.

Von diesen Dingen gelöst, muß das Reengineering Team anfangen induktiv zu

denken. Darunter versteht man eine komplett konträre Denkweise. Induktiv Denken bedeutet, losgelöst von allen bisherigen Vorgaben und Annahmen eine überzeugende Lösung zu finden, um dann anhand der Lösung festzustellen, wo eigentlichen Probleme liegen, die im Folgenden gelöst werden können.

Um nicht Gefahr zu laufen im Abstrakten das Konkrete zu verlieren, möchten wir an dieser Stelle ein Beispiel anführen, durch das vieles hoffentlich verständlicher wird.

In den frühen 80er Jahren versuchte Ford durch eine Kostensenkung in der Kreditorenbuchhaltung die Gemein- und Verwaltungskosten zu reduzieren. In der Kreditorenbuchhaltung, die für die Begleichung der Rechnungen, die die Zulieferer der Firma einreichten, zuständig war, waren zu diesem Zeitpunkt 500 Mitarbeiter beschäftigt. Die Führungsspitze von Ford glaubte, durch den Einsatz von Computern zur Automatisierung einiger Tätigkeiten Personaleinsparungen von 20 Prozent erreichen zu können. Damit hätte also die Mitarbeiterzahl auf 400 verringert und somit die Kosten gesenkt werden können. Das Ziel einer 20-prozentigen Verbesserung hörte sich ja auch nicht schlecht an. Diese Maßnahme hat jedoch nach unserem Verständnis nichts mit Business Reengineering zu tun. Man kann hier aber klar das Vorgehen mit deduktiver Denkweise verdeutlichen.

Diese Einsparung um 20 Prozent erschien dem Management solange als Erfolg, bis sie zum Vergleich die Kreditorenbuchhaltung der Firma Mazda betrachteten, an der Ford seit kurzem beteiligt war. Überraschenderweise arbeiteten bei Mazda gerade einmal fünf Beschäftigte an der Begleichung der Lieferantenrechnungen. Zwar war Mazda ein kleineres Unternehmen als Ford, jedoch war das Verhältnis 500:5 zu extrem, um es auf Größenunterschiede, Mitarbeitermotivation oder ähnliches zurückführen zu können.

Jetzt entschloß sich Ford den gesamten Prozeß neu zu überdenken, dem die Kreditorenbuchhaltung angehörte. Dies führte bei Ford zu einer ganz neuen Sichtweise. Da jetzt nicht mehr nur eine Abteilung in Frage gestellt werden sollte, sondern ein ganzer Prozeß, bewegte man sich bereits in Richtung Business Reengineering. Der Prozeß der betrachtet werden sollte hieß "Beschaffung". Input dieses Prozesses war die Bestellung, die eine Ford-Fabrik an einen Lieferanten aufgab. Output war die Auslieferung der bestellten Teile an die Fabrik, also den Prozeßkunden. An dem Prozeß waren die Abteilungen Einkauf, Kreditorenbuchhaltung und Wareneingangsabteilung beteiligt.

Der alte Beschaffungsablauf war folgendermaßen organisiert:

Die Abteilung Einkauf schickte eine Bestellung zum Zulieferer. Davon erhielt die Kreditorenbuchhaltung eine Kopie. Beim Eintreffen der Ware wurde durch einen Mitarbeiter im Eingangswarenlager ein Formular ausgefüllt, in dem alle enthaltenen Teile aufgeführt wurden. Diese Liste wurde an die Kreditorenbuchhaltung weitergeleitet, wohin auch der Lieferant parallel dazu seine Rechnung schickte.

In der Kreditorenbuchhaltung mußte jetzt das Wareneingangsformular mit der Bestellung und der Rechnung verglichen werden. Wenn alle drei Dokumente die gleichen Posten auswiesen, wurde ein Mitarbeiter angewiesen die Rechnung zu begleichen.

So umständlich diese Organisation ohnehin schon war: solange keine Unstimmigkeiten auftauchten, lief zumindest alles geregelt ab. Die Praxis zeigte allerdings, daß der weitaus größere Teil der Arbeit in der Abteilung nicht damit verbracht wurde dieser Tätigkeit nachzugehen, sondern sich mit der Nachvollziehung und Behebung von aufgetauchten Fehlern zu beschäftigen. Die Lösungen von Problemen, die auftraten sobald Bestellung, Wareneingang und Rechnung nicht deckungsgleich waren, waren so variantenreich, daß es keinen standardisierten Arbeitsvorgang gab.

Im neuen Prozeß sah die Kreditorenbuchhaltung radikal anders aus. Der Vorgang stellte sich jetzt wie folgt dar:

Der Einkäufer, der eine Bestellung an einen Zulieferer aufgibt, gibt den Auftrag gleichzeitig in eine Online-Datenbank ein. Die Zulieferer senden ihre Ware nach wie vor an das Wareneingangslager. Im Eingangslager werden mittels der Online Datenbank die aufgegebene Bestellung und die eingegangene Ware verglichen. Dabei gibt es nur zwei Möglichkeiten für das Vergleichsergebnis: richtig oder falsch. Stimmt die gelieferte Ware mit dem offenen Auftrag über ein, nimmt der Wareneingangsmitarbeiter die Ware an, bestätigt dies in der Datenbank und löst damit sofort die Zahlung des entsprechenden Betrages an den Lieferanten aus. Stimmt die Lieferung nicht mit der Bestellung überein, verweigert der Lagermitarbeiter die Warenannahme und schickt sie an den Lieferanten zurück.

Die Arbeit der Kreditorenbuchhaltung hat sich damit völlig geändert. Es wurden alle bisherigen komplexen und aufwendigen Tätigkeiten wie Nachforschungsverfahren, Zwischenablage, Wiedervorlage, Handhabung dreier verschiedener Dokumente usw. eliminiert. Es müssen auch keine Rechnungen mehr kontrolliert werden, es gab ja keine Rechnungen mehr. Auch die Anweisung der Zahlung ist nicht mehr Aufgabe der Kreditorenbuchhaltung. Die Kreditorenbuchhaltung ist beinahe überflüssig geworden. Die Zahl der Beschäftigten in dieser Abteilung beträgt nun nur mehr 125. Diese Mitarbeiter beschäftigen sich ausschließlich um besondere Ausnahmefälle.

Am Beispiel Ford können im Folgenden verschiedene Gedanken und Ansätze verdeutlicht werden. Zunächst allerdings zurück zum Thema induktives Denken:

Die Manager bei Ford suchten anfänglich eine Lösung um den bestehenden Prozeß effektiver zu gestalten und verbessern zu können. Schließlich gelang es ihnen sich von bestehenden Strukturen zu lösen, und induktiv den vielleicht optimalen Prozeßablauf zu finden. Nach Erkennung der besten Lösung, wurde ihnen auch bewußt, wo die Schwächen der alten Abläufe lagen. Es konnten sogar (und das ist der wesentliche Punkt) Probleme gelöst werden, die vormals nicht als Probleme, sondern als Vorgaben und Gegebenheiten angesehen wurden.

Beim Business Reengineering ist es, wie schon oft betont wurde, entscheidend vom Alten loszulassen. Progressives Loslassen führt neben induktivem Denken auch sehr häufig zu guten Ideen. Mit progressivem Loslassen meine ich dabei das bewußte und programmatische Hinterfragen aller Regeln, Leitsprüche und verbreiteten Annahmen als Technik zur Findung neuer Ideen.

Die wichtigsten Annahmen und Regeln, die im Beispiel Ford über Bord geworfen wurden, sind:

Das Infragestellen von Annahmen ist nach Michael Hammer eine sehr wichtige Technik um innerhalb der Redesign-Arbeit die Kreativität des Reengineering Teams zu stimulieren. Er nannte diese Technik englisch "question assumptions".

Der "question assumptions"-Technik sehr nahe, steht eine weitere wichtige Methode beim Reengineering. Sie hat auch mit Infragestellung zu tun, beschäftigt sich dabei aber schwerpunktmäßig mit Informationstechnologie. Dabei wird die immense destabilisierende Kraft der modernen Informationstechnologie benutzt, um auf ihr als Basis neue Lösungen zu finden, und damit die alten zu verwerfen. Im Beispiel Ford führten schließlich die Möglichkeiten der Online-Datenbank zur Eröffnung vollständig neuer Wege des Workflows.

Gängige Annahmen auf diesem Bereich, die durch moderne IT widerlegt werden konnten, und zu erheblichem Fortschritt führten, sind:

- "Nur Experten können komplexe Aufgaben übernehmen"

- "Außendienstmitarbeiter benötigen Büros, um Informationen empfangen, aufbewahren, abrufen und übertragen zu können"

- "Entscheidungen trifft das Management"

- "Man muß sich zwischen Zentralisation und Dezentralisation entscheiden"

An diesen Beispielen sieht man schon, daß moderne Informationstechnologien und deren Anwendungen ganz entscheidende Faktoren beim Business Reengineering darstellen.

Um neue Denkanstöße und das auf den Kopf stellen des Smith‘schen Gedanken geht es auch weiterhin bei vielen Hilfsmitteln für Business Reengineering. Wie Michael Hammer und James Champy immer wieder in ihrem Buch betonen, gibt es leider kein Rezept für Business Reengineering in Form eines 10.Punkte Plans oder ähnlichem, sondern nur Hilfen, Techniken und Denkanstöße.

Aus Erfahrungen von Firmen und Unternehmensberatern kann man lernen, daß es für den Prozeß am sinnvollsten ist, wenn so wenig Menschen wie möglich an einem Prozeß arbeiten. Damit soll nicht gesagt sein, daß idealerweise ein Mitarbeiter zum Beispiel für die gesamte Auftragsabwicklung eines Weltkonzerns zuständig sein soll, es soll nur gesagt werden, daß im Idealfall ein Beschäftigter ein Werkstück, eine Information oder eine sonstige Arbeit von Prozeßbeginn bis Prozeßende begleitet und bearbeitet. Es sollen also Generalisten parallel einen Prozeß als ganzes durchführen. Als Bezeichnung für diese Generalisten hat sich in der Fachliteratur der Begriff "Caseworker" gebildet, was wörtlich übersetzt soviel wie "Fall-Bearbeiter" heißt, und die Funktion im Gegensatz zum "Sachbearbeiter" recht gut abgrenzt. Ist ein Prozeß für einen Caseworker zu kompliziert, oder ist es nötig an verschiedenen Orten an einem Prozeß zu arbeiten, so tritt anstelle des Caseworkers ein Caseteam, das die Arbeitsabläufe in Koordination, dem Prozeß folgend, erledigt.

Um prozeßverantwortliche Caseworker einsetzen zu können, muß ein Prozeß konsequenterweise, bzw. als Voraussetzung einfach gestaltet sein. Sollten bisher nach Taylor die einzelnen Arbeitsschritte so einfach wie nur möglich gehalten werden, so stellt man heute diese Anforderung an den Gesamtprozeß.

Dabei spielt natürlich die Organisation und das Ausmaß des dem Prozeß vorstehenden Managements und der Kontrollorgane eine Rolle. Diese waren ja einer der Gründe, weshalb die funktionelle Struktur so überladen war.

In Bezug auf die mitwirkenden Managementorgane haben wir ja schon festgestellt, daß durch moderne Informationstechnologien sowohl eine Entscheidungsfindung in komplexen Fragen in die Hand von "Laien" gelegt werden können, und daß zum anderen die Vorteile der dezentralen Arbeit ohne Kompromisse genutzt werden können. Zudem hat sich das Menschenbild seit der Industriellen Revolution dahingehend geändert, daß man heute von dem Gedanken abgekommen ist, daß die Beschäftigten unmündig und zu eigenständigem Denken unfähig sind. In Konsequenz dazu kann viel mehr Verantwortung an die am direkten Prozeßablauf beteiligten Beschäftigten delegiert werden. Wenn das Management einer Person oder einem Team die Verantwortung für einen vollständigen Unternehmensprozeß überträgt, müssen diese Mitarbeiter auch bevollmächtigt sein, die bei der Erfüllung der Aufgaben nötigen Entscheidungen zu treffen. So wurde es zum Beispiel auch in der Fallstudie Ford gemacht, wo der Lagerist ermächtigt ist Zahlungsvorgänge anzuweisen. Diese Vorgehensweise ist unter dem Begriff Empowerment bekannt geworden.

Die Selbstständigkeit von Caseworkern ist für die Flexibilität und die Geschwindigkeit des Prozesses sehr wichtig. Man bedenke nur wie bremsend es ist, zum Beispiel auf eine Genehmigung von übergelagerter Stelle zu warten.

Zum Thema Kontrollen wird schlicht ein wirtschaftlicher Ansatz zu Rate gezogen. Überwachung und Kontrolle sind demnach keine wertschöpfenden Tätigkeiten im Unternehmen, und werden somit zu lediglich kostenintensiven Unterprozessen, die auf ein Mindestmaß reduziert werden müssen. Dabei sollen ganz einfach alle Kontrollen entfallen, deren wertmäßiger Nutzen weit hinter den Kosten die sie verschlingen zurückbleibt. Anders gesagt: Das Unternehmen soll sich nur soviel Überwachung leisten, wie es wirtschaftlich sinnvoll ist. Somit wird prozeßaufgesetztes Management und Überwachung und Kontrolle nicht mehr im üblichen Maße als notwendig erachtet, wodurch auch die Hierarchien im Unternehmen abgeflacht werden können.

Genauso wie beim Empowerment, wo es heißt: "Entscheidungen müssen dort gefällt werden, wo sie anstehen", gilt es im Business Reengineering, daß die Arbeiten dort ausgeführt werden müssen, wo sie anstehen. Dies führt nicht nur dazu Tätigkeiten von vormals administrativen Abteilungen in den Arbeitsbereich von Caseteams zu legen. Dies kann auch heißen, daß die Mitarbeiter eines Caseteams an unterschiedlichen Orten am selben Prozess arbeiten müssen. Der Prozess bleibt dabei in einer Gesamtverantwortung..

Durch den Einsatz von Caseworkern und Caseteams und der damit einhergehenden Auflösung der vertikalen Abteilungen, konnte auch ein weiterer großer Fortschritt erzielt werden. Die Verständigungs- und Abstimmungsprobleme die durch die Vielzahl von funktionellen Schnittstellen hervorgerufen wurden, konnten beseitigt werden. Somit reduzieren sich die Abstimmungsarbeiten, die früher ein großes Maß an Managementtätigkeiten in Anspruch nahmen, und die an sich ja auch nicht produktiv im Sinne von wertschöpfend sind, auf ein Mindestmaß. Der Process Flow konnte damit erheblich verbessert werden.

Auf ein Minimum an Abstimmungsarbeiten muß man beim Redesign auch bei der Gestaltung der Prozeßschnittstellen (bei der Übergabe des Outputs an den Prozeßkunden) achten. Wie am Beispiel Ford gesehen, konnten die drei Kontaktpunkte mit dem Kunden (Bestellung, Wareneingang und Rechnung) auf zwei reduziert werden. Damit verringerten sich die Fehlerquellen um ein Drittel.

Ein weiterer Vorteil des "structure follows process"-Gedanken ist die Rückgewinnung der eigentlichen Prozeßreihenfolge. Das heißt, der Prozeß wird von seiner funktionalen Linearität befreit, die den Ablauf unter Umständen erheblich verlangsamt hat. Es ist nicht mehr Vorschrift, daß die Arbeitsgänge hintereinander (meist in verschiedenen Abteilungen) ablaufen, es kann auch möglich sein, daß manche Prozeßschritte simultan ablaufen können, und dadurch Zeit gewonnen wird.

Es muß natürlich noch erwähnt werde, daß sich die Caseteams in der Neuen Struktur wesentlich flexibler bewegen können, und somit den wechselnden Anforderungen besser gewachsen sind, und auch für die Lösung außerordentlicher Aufgaben bessere Freiräume haben. Es sind meist außerordentliche Aufgaben, die die Kapazitäten einer "Abteilung" oder eines Prozeßteams beanspruchen.

Zur Flexibilität trägt auch ein noch nicht erwähnter Ansatz bei der Planung von Prozessen bei. Ein hervorragendes Mittel zur Gewährleistung eines schnelleren Work-Flows ist eine Differenzierung des Prozesses, bzw. die Definition von zwei oder drei Prozessen, etwa für wenig, mittel und sehr komplexe Inputs in einen Prozeß. Zum Beispiel könnte in einer Gemeinde bei der Bearbeitung von Bauanträgen zwischen der Vorgehensweise zur Genehmigung eines kleinen Hausanbaus und dem Verfahren zur Genehmigung der Bebauung von Neuland unterschieden werden. Damit könnte der Kunde des wenig komplexen Vorgangs schneller bedient werden.

Das Niveau des Services erhöht sich ebenfalls automatisch mit dem Business Reengineering. Mit der Einführung von durch das Empowerment gestärkten eigenverantwortlichen Prozeßteams (Caseteams), schuf man sogenannte "Unternehmer im Unternehmen". Sie arbeiten selbständig und ergebnisorientiert (nicht mehr aufgabenorientiert) für den Kunden. Ein Caseworker oder ein übergeordneter Casemanager dient dem Kunden als kompetenter und voll verantwortlicher Ansprechpartner für den gesamten Prozeß, so daß die Wünsche oder Probleme des Kunden direkt an entscheidender Stelle angebracht werden können.

Die Organisationsstrukturen ergeben sich direkt aus den definierten Prozessen und der beschriebenen Arbeitsweisen und Stellenbesetzungen. Formell treten im Organigramm (falls so etwas noch nötig ist) Projektteams anstelle von Abteilungen. Die übergeordnete Koordination ergibt sich meist eindeutig aus den Prozeßschnittstellen.

Um nach dem Business Reengineering erfolgreich arbeiten zu können, müssen bei der Umsetzung des Redesigns zwangsläufig auch neue Grundsätze und Wertvorstellungen vermittelt werden.

So ist es bei aller Ausrichtung der Prozesse auf den Kunden unabdingbar, daß auch die Mitarbeiter auf den Kunden ausgerichtet denken. Der Kunde muß sowohl als Auftraggeber und Arbeitgeber, als auch als Brötchengeber angesehen werden. Nicht der Chef zahlt das Gehalt sondern der Kunde. Deshalb muß alles getan werden um den Kunden zufriedenzustellen. Im Zuge des Empowerment hat sich die Rolle des Chefs ohnehin vom Aufseher zum Coach entwickelt, der mit Rat und Tat unterstützend und moderierend wirkt.

Auch die oft in großen Konzernen verbreitete Einstellung der einzelne Mitarbeiter sei nur ein winziges Rädchen ohne Bedeutung muß revidiert und ausgemerzt werden. Vielmehr muß sich der Einzelne als wichtigen Beitragsleister zum Ganzen sehen und als Mitglied eines Teams verstehen. Dabei ist das Bewußtsein der Tatsache, daß der Erfolg oder das Scheitern des Teams von jedem Einzelnen abhängt, besonders wichtig. Die Aufwertung des Einzelnen geschah ja ohnehin offensichtlich durch das Empowerment, und die Arbeit als Caseworker.

Damit ist schon angedeutet, daß sich mit dem Business Reengineering mehr geändert hat, als "nur" die Organisationsstruktur im Unternehmen. Für die Beschäftigten der betroffenen Firma hat sich die gesamte Arbeitswelt geändert.

Durch die Abschaffung von Routinearbeiten im herkömmlichen Sinne wird eine Umorientierung vom Spezialistentum hin zu multidimensionalen Berufsbildern eingeleitet. Durch die Abflachung der Hierarchieebenen stellt sich auch die Frage des Berufsaufstiegs neu. Die Stellung im Unternehmen kann nicht mehr durch das einfache Abzählen der Untergebenen definiert werden. Man muß neue Aufstiegsmöglichkeiten suchen. Auch die Umgestaltung der Tätigkeiten wirft einige weitere ungelöste Probleme auf. Es gilt jetzt neue Arbeitsplatzbewertungssysteme zu finden, und die Löhne und Gehälter gemäß den neuen Anforderungen bzw. dem neuen Wert der Tätigkeit für das Unternehmen neu festzulegen.

Schulungspläne müssen neu entwickelt werden, genauso wie ein Katalog mit Anforderungen und Tätigkeiten an einem bestimmten Arbeitsplatz, um der Personalabteilung Anhaltspunkte für die Rekrutierung neuer Mitarbeiter zu geben.

Es ist also ein gewaltiger Umbruch, der beim Business Reengineering in einem Unternehmen stattfindet. Dieser Umbruch muß von allen Beschäftigten unterstützt und getragen werden, sonst ist er von vornherein zum Scheitern verurteilt.

Die Überzeugungsarbeit, die das Top-Management vor und während des Business Reengineering zu leisten hat ist immens. Um so schwieriger wird diese Aufgabe natürlich, wenn vorauszusehen ist, daß das Redesign Arbeitsplätze gefährdet. Und dies ist sehr oft der Fall, obwohl es keinesfalls das Ziel des Redesigns ist. Business Reengineering ohne die Bereitschaft Opfer zu bringen ist von vornherein zum Scheitern verurteilt. So meinen es jedenfalls Hammer und Champy.