Porsche-Manager Ulrich Flatau zum Thema Prozess-Engineering

"Wir betreiben die IT nicht, weil sie uns Spaß macht"

24.03.2000
MÜNCHEN (CW) - Vor zwei Jahren holte die Porsche AG die ausgelagerte Informationstechnik in den Konzern zurück, um ihre Geschäftsziele wieder effektiver unterstützen zu können (siehe CW 31/98, Seite 39). Über die IT-Strategie des Automobilherstellers sprach CW-Redakteurin Karin Quack mit Ulrich Flatau, Leiter Organisation und Datenverarbeitung.

CW: Eines der meiststrapazierten Schlagwörter in Fachartikeln und Konferenzen zum Thema IT-Strategie ist Business Alignment. Wie verstehen Sie diesen Begriff?

Flatau: Nach meiner Auffassung ist die Informationstechnik nur ein Hilfsmittel, um die Probleme einer Organisation zu lösen. Wir betreiben die IT ja nicht, weil sie uns so viel Spaß macht, sondern weil wir einen Geschäftszweck damit verfolgen. In unserem Fall besteht er darin, Autos zu bauen - möglichst zu dem Zeitpunkt, zu dem wir sie dem Kunden versprochen haben, in der Qualität, die er erwartet, und zu Kosten, die es der Firma erlauben, am Leben zu bleiben. IT bekommt einen anderen Sinn, wenn man sie als Mittel zum Zweck betrachtet.

CW: Welchen?

Flatau: Zunächst einmal ist es wichtig, Information und Informationstechnik nicht zu verwechseln. Information ist das Produkt, das wir haben möchten, und die IT ist das Mittel, mit dem wir es transportieren, speichern oder bearbeiten. Viele Unternehmen sind sich gar nicht darüber im Klaren, was ein Mitarbeiter eigentlich an Informationen benötigt, um seinen Job zu tun. Erst wenn diese Frage beantwortet ist, können wir entscheiden, mit welcher Technik die Information bereitgestellt werden soll und ob es überhaupt sinnvoll ist, dafür Informationstechnik einzusetzen. Die IT hat nur dort ihre Berechtigung, wo es um repetitive Tätigkeiten geht oder wo Ort und Zeit zu überbrücken sind.

CW: Gibt es in den Unternehmen möglicherweise eine Überversorgung mit Informationstechnik?

Flatau: Nein, aber das, was da ist, wird oft nicht so genutzt, wie es genutzt werden könnte. Sehen wir uns zum Vergleich einmal an, welchen Aufwand wir treiben, damit der Werker am Band zum richtigen Zeitpunkt das richtige Werkzeug und das richtige Fahrzeug vor sich hat. Das ist Arbeitsvorbereitung! Aber wo ist die Arbeitsvorbereitung für die Informationsverarbeitung? Die wird häufig dem Zufall überlassen. Der IT-Anwender hat eine Holschuld. Er muss sich beschaffen, was er braucht, um seinen Job zu tun.

CW: Wie lässt sich das ändern?

Flatau: Indem wir ordentliche Prozesse und Abläufe schaffen. Mit deren Hilfe wüssten wir ganz genau: Um diese oder jene Entscheidung zu treffen, braucht jemand zu diesem Zeitpunkt diese Information.

CW: Aber der Arbeiter am Band lässt sich doch nicht ohne weiteres mit dem Informationsverarbeiter vergleichen.

Flatau: Das sehe ich anders. Der Informationsfluss muss genauso gesteuert werden wie der Materialfluss. Der Werker hat keine Chance, die Abläufe zu verzögern; wie lange er braucht, um seine Arbeit zu tun, wird ihm von der Refa vorgegeben. Die Information hingegen läuft durch x Hände und bleibt unter Umständen überall einige Zeit liegen. Sie haben Recht, wenn Sie darauf abzielen, dass es sich bei der Montage um repetitive Tätigkeiten handelt. Aber die gibt es auch in den Büros, und nur auf diese Tätigkeiten beziehe ich mich. Je genauer wir die Abläufe analysieren und planen, desto besser können wir sie synchronisieren und von den Totzeiten befreien - genau wie am Fließband.

CW: Die Automatisierung der immer gleichen Abläufe - auch im Büro - passiert doch aber längst.

Flatau: Ja, aber sie geschieht derzeit an verschiedenen Stellen mit verschiedenen Systemen. Bislang wurden die einzelnen Funktionen separat betrachtet und nicht im Hinblick darauf, welche Informationen für eine andere Funktion hilfreich wären. Mit den gewachsenen heterogenen IT-Umgebungen ist es üblich, in einem System die Bestellung auszuschreiben, in einem anderen den Empfang zu quittieren und am Ende alles irgendwie zusammenzubringen. Das bedeutet eine gewisse Flexibilität, an die sich die Mitarbeiter gewöhnt haben. Deshalb empfinden sie die Rigorosität eines integrierten Systems oft als unangenehm. Der einzelne Sachbearbeiter hat davon keinen Nutzen, aber nachgeschaltete Funktionen profitieren davon. Gleichzeitig werden bestimmte Tätigkeiten innerhalb des Unternehmens verlagert.

CW: Das klingt nach einem Plädoyer für integrierte betriebswirtschaftliche Softwarepakete à la SAP - womit wir aber schon bei der Umsetzung wären.

Flatau: Beides hängt miteinander zusammen. Gerade, wenn man ein integriertes System von der Stange einsetzen will, muss man sich vorher Gedanken darüber machen, in welcher Reihenfolge die Tätigkeiten eines Ablaufs erfolgen sollen. Der Begriff Geschäftsprozess-Engineering drückt bereits aus, dass es sich hier um eine erlernbare Disziplin mit festen Regeln handelt. Ob diese Schritte gut oder schlecht sind, also zum definierten Ziel führen oder nicht, lässt sich eindeutig nachweisen.

CW: Über Business Process Reengineering ist in den 90er Jahren viel geschrieben worden. Mittlerweile gilt das als alter Hut.

Flatau: Dann fragen Sie doch einmal nach, welche Firma ihre Geschäftsabläufe klar dokumentiert aus dem Schrank ziehen kann. Sie werden sich sehr schwer tun, eine zu finden. Wenn überhaupt, dann handelt es sich um kleine Teile des Unternehmens, die außerdem nur auf die Ist-, aber nicht auf die Soll-Prozesse abzielen. Aber wenn man tatsächlich die Geschäftsziele unterstützen will, muss man auch definieren, wie die Prozesse im Einklang damit auszusehen haben.

CW: Können Sie das an einem Beispiel deutlich machen?

Flatau: Wenn Sie bei uns ein Auto bestellen, sollten wir in der Lage sein, Ihnen auf den Tag genau zu sagen, wann wir es liefern werden. Bekommen Sie es zwei Tage zu früh, so passt der Termin nicht in Ihre Planung, lässt es zwei Tage auf sich warten, werden Ihre Urlaubspläne durchkreuzt. Und die Qualität muss ebenfalls stimmen. Diese Kundenzufriedenheit lässt sich nur erreichen, wenn wir - im Unterschied zu einer bloßen funktionalen Betrachtung - auch die Leistung eines Prozesses festlegen. Die dafür relevanten Fragen lauten: Was soll der Prozess bewirken? Wie stabil ist er? Liefert er innerhalb einer vorgegebenen Zeit zu den veranschlagten Kosten Ergebnisse in der erforderlichen Qualität?

CW: Und wie manifestieren sich die Antworten auf diese Fragen?

Flatau: Am Ende haben wir quasi eine Blaupause des jeweiligen Prozesses. Die benötigen wir auch und gerade dann, wenn wir eine Software von der Stange einsetzen wollen. Nur so können wir etwaige Änderungen dokumentiert nachhalten. Sonst läuft das, was wir im System haben, und das, wovon wir meinen, dass wir es haben, völlig auseinander.

CW: Ihren Ausführungen entnehme ich, dass die Porsche AG ihre Prozesse vollständig dokumentiert im Schrank stehen hat.

Flatau: Das ist richtig, soweit es sich um unsere Ist-Prozesse handelt, wobei die Detaillierung der Prozesse sehr unterschiedlich ist.

CW: Was ist mit den Soll-Prozessen?

Flatau: Wir schalten vor alle neuen Softwareprojekte eine Phase, in der wir nicht nur die bestehenden Abläufe analysieren, sondern auch Soll-Prozesse definieren. Nur so lässt sich der Projekterfolg später überprüfen.

CW: Wie sorgen Sie dafür, dass das, was im Schrank steht, auch umgesetzt wird?

Flatau: Zusätzlich zur Papierversion wollen wir die Dokumentation der Ist-Prozesse sowie die Arbeitsanweisungen und qualitativen Ziele auch in unser Intranet stellen. Das gilt für jedes Projekt - auch wenn es definitiv nicht in Software implementiert wird, also beispielsweise auch für die Geschäftsjahresplanung. Für die Darstellung der Prozesse setzten wir "Bonapart" von der Berliner Pro Ubis GmbH ein.

CW: Sie führen derzeit die R/3-Software von SAP ein. Da hätten sich doch die "Aris"-Tools des SAP-Partners Prof. Scheer angeboten.

Flatau: Wir haben uns hauptsächlich deshalb für Bonapart entschieden, weil es im Gegensatz zu Aris Hierarchien erlaubt und implementierungsunabhängig ist. Wir können damit die Prozesse auf dem jeweils erforderlichen Abstraktionsgrad beschreiben.

CW: Was hat das mit Hierarchien zu tun?

Flatau: Normalerweise können wir Menschen nicht mehr als sieben bis neun Dinge gleichzeitig im Kopf behalten. Deshalb müssen wir das Gesamtsystem auf einer Abstraktionsebene kondensieren, wo es sich aus maximal neun Blöcken zusammensetzt. Für die Vorstände, die geschäftspolitische Entscheidungen treffen, ist es wichtig, die Zusammenhänge auf einer übergeordneten Ebene zu betrachten. Der Softwareentwickler braucht aber eine viel feinere Darstellung.

CW: Sie sprachen auch den Zusammenhang zwischen der Prozessdarstellung und der Implementierung an. Was bringt es, wenn diese Beziehung weniger eng ist?

Flatau: Wir wollen, dass die Prozesse unabhängig von der Implementierung optimiert werden. Ich möchte vermeiden, dass wir von vornherein auf die Software Rücksicht nehmen. Es soll nicht heißen: Das kann SAP nicht, deshalb dürfen wir es nicht beschreiben. Anderenfalls hätten wir das Problem, dass die Erfordernisse des Geschäfts durch die Informationstechnik limitiert werden. Und ich stehe auf dem Standpunkt: Wir definieren das, was wir vom Geschäft her wollen, die IT muss schauen, dass sie es hinbekommt.

CW: Wenn Sie feststellen, dass das, was Sie wollen, mit der gewählten Software nicht geht, wie reagieren Sie?

Flatau: Im Zweifelsfall entscheiden wir uns dafür, möglichst nah am Standard zu bleiben, auch wenn wir damit nicht jede gewünschte Funktion abbilden.

CW: Widersprechen Sie sich damit nicht selbst?

Flatau: Nein, wir unterscheiden da schon zwischen den Dingen, die für den Ablauf unbedingt notwendig sind, und dem, was lediglich "nice to have" ist.