Vorteile und Herausforderungen von Business Engineering

"Die Welt steht nicht still."

Mirko Schrempp

Professor Dr. Robert Winter ist Ordinarius für Wirtschaftsinformatik an der Universität
St. Gallen, Direktor des Instituts für Wirtschaftsinformatik und Gründungsdirektor des
Executive Master of Business Engineering. Er lehrt und forscht seit 1996 an der Universität St. Gal-len. Neben Grundlagenforschung zur situativen Methodenkonstruktion arbeitet er auf den Gebieten Informationslogistikmanagement, Unternehmensarchitekturmanagement, Integrationsmanagement und Unternehmenssteuerung. Business Technology hatte die
Gelegenheit, mit ihm über die Vorteile und Herausforderungen von Business Engineering als über-greifender Methode des Prozessmanagements zur Bewältigung der Komplexität
einer Gesamtorganisation zu sprechen.

Im Titel eines Ihrer Forschungsprogramme steht die Bezeichnung „Business Engineering“, das ist – ähnlich wie Business Technology – ein Begriffspaar, das auf den ersten Blick nicht zusammenpasst, was verbirgt sich dahinter?

Dr. Robert Winter: Wir haben den Begriff „Business Engineering“ gewählt, weil wir der Mei-nung sind, dass heutige Organisationen so komplex und dynamisch sind, dass man die Konstruktion und den Um-bau nicht mehr intuitiv und aus dem Bauch heraus bewältigen kann. Auch ein einzelner Kopf reicht dazu nicht mehr aus. Heute braucht man dazu ingenieurmäßiges, systematisches modell- und methodenbasiertes Vorgehen. Darum der Begriff „Engineering“, denn dieser steht genau für dieses modell- und methodenbasierte Vorgehen. Und Business Engineering, weil wir keine Informationssysteme oder Software bauen wollen, sondern Organisationen, Geschäftsarchitekturen oder Prozessarchitekturen. Man kann auch versuchen, es auf Deutsch zu übersetzen, dann kommt allerdings betriebswirtschaftliche Konstruktionslehre heraus – das klingt schon ein bisschen schwerfällig -, aber es sagt doch, worum es geht, Konstruieren und systematisches Bauen in der BWL. Business Engineering ist zwar ein Anglizismus, drückt aber doch sehr viel kompakter und eleganter aus, was wir wollen.

Im Allgemeinen stellt man sich unter Prozess etwas vor, das geordnet abläuft – auch wenn die Fragen daher trivial erscheinen mögen: Was ist eigentlich ein Prozess genau? Was unterscheidet ihn von Ritualen, All-tagshandlungen oder mechanischen Vorgängen, die auch regelmäßig oder geordnet ablaufen – was ist das Spe-zifische eines Prozesses?

Winter: Auf diese Frage bekommen Sie natürlich unterschiedliche Antworten, abhängig da-von, wen Sie fragen. Ich denke, die Antworten lassen sich in drei Hauptgruppen einteilen. Wenn Sie die Kollegen von der Soziologie bzw. der Organisationspsychologie fragen, dann werden sie sagen: Ein Prozess ist eine emer-gente Struktur in einem sozialen System, in dem sich ein bestimmtes Verhalten und Einstellungen zeigen, die sich entwickeln und damit zu einer Veränderung dieses sozialen Systems führen. Diese Sichtweise der Dinge hat si-cher ihre Berechtigung, denn organisatorische Veränderungsprozesse laufen durchaus „emergent“ ab. Es ist aber auch möglich und sinnvoll, Veränderungen, zumindest soweit möglich, zu planen und zu konstruieren. Wir wol-len eben nicht darauf hoffen, dass die Dinge sich schon in die richtige Richtung entwickeln werden und die Leute sich in ihren Einstellungen so verändern, dass auch etwas Vernünftiges dabei herauskommt. Aber auch die ges-taltende (und nicht allein verstehende) Sicht hat zwei „Prozess“-Ausprägungen: Zum einen gibt es eine Gruppe von Antworten, die sich sehr gut mit der Informatik korrelieren lässt. Für diese ist der Prozess letztendlich ein Workflow, im Prinzip eine strukturierte Ablaufkette von Aktivitäten mit einer gewissen Ablauflogik, die man instanziiert, und die koordiniert, wie diese Aktivitäten ablaufen und Leistungen erbracht werden. Dieses Prozess-verständnis der Informatik passt ebenfalls nicht gut zu unserer Sichtweise, weil die Steuerungslogik im Vorder-grund steht und diese eigentlich nicht die Businesssicht ist. Im Business Engineering haben wir eher eine be-triebswirtschaftliche Sichtweise und das ist wiederum etwas ganz anderes, also weder eine emergente Struktur noch ein Workflow. Aus betriebswirtschaftlicher Sicht ist ein Prozess die Strukturierung der Leistungserstellung in einer Form, die sicherstellt, dass die richtigen Ergebnisse erzeugt und dabei die relevanten Ziele verfolgt wer-den. Im Prinzip heißt das, das Richtige tun – Effektivität – und es dabei richtig tun – Effizienz. Hierbei steht dann nicht der Workflow im Vordergrund, denn was da wann und in welcher Reihenfolge passiert, ist nachran-gig. Das Wichtige ist eigentlich die Qualität der Prozessleistung, also der Aspekt, ob die Prozessleistung dem entspricht was rauskommen soll, sowie die Führbarkeit, d. h. kann ich den Ablauf so steuern, dass ich meine Ziele erfüllen kann.

Das sind nach meiner Wahrnehmung die drei großen Gruppen von Prozessdefinitionen, also erstens emer-gente soziale Systeme, zweitens die Fokussierung auf die Workflowsteuerung und die dritte Sichtweise ist die betriebswirtschaftliche, die an Effektivität und Effizienz orientiert ist. Wir fühlen uns im Business Engineering primär der betriebswirtschaftlichen Sichtweise verpflichtet – eben Business Engineering und nicht Systems En-gineering oder Organizational Behaviour. Prozess ist für uns etwas, das bestimmte definierte Leistungen unter Beachtung eines bestimmten Zielsystems erzeugt.

Was sind Beispiele für diese Leistung und diese Zielsysteme die Sie ansprechen, wo und wie kommen die Prozesse des Business Engineering zum Einsatz?

Winter: Im Business Engineering haben wir die Methodik, aus der die Reihenfolge resultiert, in der ein Prozess gestaltet bzw. analysiert wird. Dazu muss ich mir darüber klar werden, was die Leistungen sind, die erbracht werden sollen und was die wichtigen Ziele und welche die richtigen Hebel sind, die ich habe, um das alles zu steuern. Wenn ich die Leistung spezifiziert und die Hebel gefunden habe, kann ich davon ausge-hend den Prozessablauf strukturieren. Wichtig ist die Reihenfolge: zunächst Leistungen, dann Ziele und dann erst die Ablauflogik, denn der Ablauf folgt dem Was-ich-machen-will und dann erst, Wie-ich-es-machen will.

Die Ziele, die da umgesetzt werden sollen, sind vermutlich Ziele, die normalerweise ein Unternehmen hat.

Winter: Richtig, und da haben wir auch das Rad nicht neu erfinden müssen, denn wir können Methodenbausteine und Techniken verknüpfen, die es schon gibt. Für die Findung von Zielen, Erfolgsfaktoren oder Führungsgrößen kann man sich beispielsweise an Ansätzen wie Balanced Scorecard orientieren. Auch dabei geht es darum, dass man am Schluss die Stellhebel findet, mit denen man die Organisation steuern will, und das sind dann natürlich genau die Stellhebel, die auch für die Prozessgestaltung wichtig sind. Es gibt also schon etablier-te Ansätze, um systematisch zu solchen Zielen und Stellhebeln zu kommen. Und auch bei der Leistungsdefinition gibt es vieles aus dem Qualitätsmanagement, beispielsweise das House of Quality, womit man systematisch Pro-dukt- und Leistungseigenschaften oder Leistungskomponenten spezifizieren kann. Diese Ansätze binden wir dann auch in unser Business Engineering ein. Und zudem natürlich Informatikmethoden wie Workflowanalysen, um sinnvolle, vielleicht sogar optimale Abläufe zu finden. Also alles Dinge, die es schon gibt, und die wir aus einer betriebswirtschaftlichen Sichtweise versuchen zu verbinden.

Bei den hier angesprochenen Abläufen zeigt sich das große Problem, dass man oft mit einer hohen und un¬übersichtlichen Komplexität konfrontiert ist. Zumindest in der IT gibt es daher die Überlegung, Diagramme als Planungsmittel und Kommunikationsvermittler zu nutzen, die auf der BPMN basieren. Diese sollen helfen, einen Workflow, der nach Ihren Ausführungen nur einen kleinen Teil des Gesamten ausmacht, zu strukturieren und für alle Prozessbeteiligten nachvollziehbar zu machen. Wie wichtig sind solche Ansätze und wie weit lässt sich das ausdehnen?

Winter: Business Engineering bedeutet ja nicht nur irgendeine Baumethodik, Engineering er-zeugt die Grundlagen für die Kommunikation und das Verständnis von Veränderungsprojekten. Wenn ich eine Maschine oder eine Brücke baue, habe ich Konstruktionszeichnungen, die eben nicht nur dazu dienen, das Ding wirklich zu bauen. Die Zeichnungen dienen auch dazu, um etwas mitzuteilen, z. B. um Lieferanten zu erklären, was sie zu liefern haben, aber auch um Komponenten einfach zu speichern, damit man sie später für dieses oder für andere Bauprojekte wiederfinden kann. „Bauzeichnungen“ sind nicht nur Teil des Konstruktionsprozesses, sondern auch ein ganz wichtiger Teil der Kommunikation. Daher sind diese Zeichnungen, Notationen oder Hintergrundbil-der ein ganz wichtiger Aspekt des Engineerings. Ich finde persönlich auch, dass BPMN für bestimmte Modellie-rungs- und Kommunikationszwecke in die richtige Richtung geht. Weil die Notation durchaus gut verständlich ist und bestimmte Aspekte damit gut dokumentiert und kommuniziert werden können. Aber ich wehre mich dagegen, diese eine Notationstechnik für fundamental zu erklären und zu sagen, es sei die einzig notwendige. In einer Orga-nisation gibt es viele Stakeholder, die an den Projekten maßgeblich beteiligt sind. Da gibt es die Informatiker, die Systeme bauen und adaptieren müssen, es gibt Sponsoren, die den betriebswirtschaftlichen Sinn verstehen müssen und es gibt die Fachbereiche, die letztendlich den Prozess mit Inhalt füllen müssen. Und wenn die Stakeholder so unterschiedlich sind, dann brauche ich auch unterschiedliche Sprachen, um mit ihnen zu reden. Ich halte BPMN nicht für den Rosetta Stone, der allen Beteiligten gleichermaßen erklären könnte, worum es geht. Daher denke ich, dass BPMN eine hervorragende Sprache ist, um mit Informatikern und Analytikern über Prozesse zu sprechen. Aber wir werden auch andere „Sprachen“ brauchen, um mit Sponsoren und Fachspezialisten zu sprechen. Diese müssen für die unterschiedlichen Stake¬holder verschieden aggregiert sein, z. B. Prozesslandkarten und so etwas wie einen Prozesskompass, der mir erlaubt, in diesen Welten zu navigieren. Manche dieser „Sprachen“ gehen über die Workflowbeschreibung von BPMN hinaus – und diese weiteren Sprachen sollte man in keinem Fall vernachlässi-gen.

Geschrieben von
Mirko Schrempp
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.