Leistungsprozesse definieren und betreiben

Wachstum muss auf gesunde und schnelle, besser sogar «pfeilschnelle» Prozesse basieren, und Wachstumsinitiativen machen dann besonderen Sinn, wenn sie sich auf die Existenz solcher pfeilschneller Prozesse verlassen können. Dabei kommt es für die Förderung profitablen Wachstums tatsächlich mehr auf Geschwindigkeit der Leistungsprozesse an, als auf deren Perfektion. In diesem Beitrag werden sechs Aspekte beleuchtet, die für die Erarbeitung und den operativen Betrieb einer leistungsfähigen, wachstumsfördernden Prozesse-Landschaft wichtig sind:

1. Basis: Eigenschaften von Leistungsprozessen

2. Unterschied: Kern- und Supportprozesse, Haupt- und Teilprozesse

3. Methodik: Die Prozesse-Landschaft – von oben nach unten

4. Überbewertet: Reengineering

5. Unterbewertet: Schnittstellen

6. Erfolgsentscheidend: Geschwindigkeit und Optimierung

Ein wenig Theorie muss an dieser Stelle erlaubt sein, will man sich mit Leistungsprozessen fundiert auseinandersetzen: Ein Leistungsprozess ist ein Geschäftsablauf, der ein Leistungsobjekt vom Zustand A in einen Zustand B überführt und der dadurch Wertschöpfung betreibt, dass der Zustand B ein leistungsfähigerer Zustand ist, als es der Zustand A war. Zur Transformation des Leistungsobjektes sind definierte Schritte erforderlich, die unter definierter Verantwortung stehen, in einer systematischen Reihenfolge ablaufen und zu dessen Durchführung definierte Ressourcen erforderlich sind wie zum Beispiel der Einsatz von Medien, Maschinen, Zeit oder Geld. Ein Leistungsprozess liefert immer ein definiertes Ergebnis.

Damit ein Leistungsprozess dieses definierte Ergebnis liefern kann, muss zum Start des Prozesses eine definierte Anfangsbedingung vorliegen. Liegt diese nicht vor, kann der Prozess nicht oder nur unzureichend durchgeführt werden. Insofern ist jeder Prozess auf das Vorliegen dieser Anfangsbedingung angewiesen. Da jedes Prozessergebnis gleichermassen auch Anfangsbedingung für einen weiteren Folgeprozess ist, muss die Prozessqualität im Fokus stehen. Prozesse können und müssen aggregiert werden, um sie strukturiert betrachten zu können. Doch dazu an anderer Stelle in diesem Beitrag mehr.

Damit die Arbeit an den Prozessen eines Unternehmens strukturiert erfolgen kann, sind zwei Unterscheidungen zwingend erforderlich:

Der erste Unterschied bezieht sich auf den Beitrag zur Kernleistung: Bei einem Prozess handelt es sich um einen Kernprozess, wenn er wesentlich zur Kernwertschöpfung beiträgt. Klassische Kernprozesse sind zum Beispiel, je nach Branche, Vertrieb (inkl. Kundenservice), Sortimentsdefinition (im Handel), Einkauf, Forschung und Entwicklung (in Produktionsunternehmen), Produktion (im Handel entspricht dies der Kommissionierung). Die Aufgabe der Supportprozesse ist es, die Kernprozesse leistungsfähig zu unterstützen. Marketing, Human Resources, Logistik, IT, Buchhaltung, Controlling, dies sind klassische Supportprozesse, um nur einige zu nennen.

Es ist wichtig, zu verdeutlichen, dass es sehr wohl eine Hierarchie in der Wichtigkeit der Prozesse gibt: Die Kernprozesse sind wichtiger als die Supportprozesse. Auch wenn dies in der Regel zu Unmut führt, spricht man es erst einmal aus, ist die Unterscheidung erfolgsentscheidend, macht sie doch deutlich, dass Supportprozesse keineswegs zum Selbstzweck im Unternehmen betrieben werden, sondern dass ihre einzige Existenzberechtigung darin besteht, den Kernprozessen den bestmöglichen Rückhalt zu geben.

Ein Identifikationskriterium, ob es sich bei einem Prozess um einen Kern- oder einen Supportprozess handelt, ist, ob man den betreffenden Prozess an Externe auslagern könnte, unabhängig davon, ob man dies wollte, ohne seine Kernkompetenzen aufzugeben. Klassischerweise verstehen sich einige Prozesse bereits als Supportprozesse, hier sind vor allem die Verwaltungsabläufe zu verstehen, manche Supportprozess-Eigner erheben aber nicht selten den Anspruch, dass es sich bei dem von ihnen verantworteten Prozess um einen Kernprozess handelt. Hier schafft ein Gespräch Klarheit.

Die zweite Unterscheidung betrifft die Prozesshierarchie innerhalb eines Kern- oder Supportprozesses: Handelt es sich bei einem betrachteten Prozess um einen Haupt- oder einen Teilprozess? An dieser Stelle gibt es keine feste Regel, wie hoch aggregiert ein Prozess sein muss, um einen Hauptprozess darzustellen, ist es wichtig, darauf zu achten, dass man innerhalb eines Unternehmens stets auf derselben Ebene bleibt, wenn man sich über Prozesse unterhält. Eine Prozesshierarchie, beginnend bei recht groben Hauptprozessen über Teilprozesse bis hinunter zu Prozessschritten, muss stets kongruent bleiben.

Hauptprozesse können zum Beispiel folgende sein: Marktanalyse, Abverkaufsauswertung, Wareneingangsabwicklung, Lieferantenreklamationen, Disposition, Auslieferung, Akquisition. Es handelt sich also um noch weiter zu detaillierende Prozesse, will man diese tatsächlich verstehen und verändern.

Als Methodik zur Darstellung der Kern- und ggf. auch der Supportprozesse hat sich in unserer Beratungsarbeit die Prozesse-Landschaft bewährt. Sie bezieht sowohl die Kunden, also die externen Abnehmer der Produkte und Leistungen, als auch die Lieferanten mit ein und sorgt für eine visuelle Darstellung der Prozesse auf einem hoch aggregierten Niveau – in der Regel werden in der Prozesse-Landschaft nur die Hauptprozesse der Kernprozesse, maximal aber zusätzlich auch die Hauptprozesse der Supportprozesse dargestellt. Der Vorteil besteht darin, dass das prozessuale Wirkgefüge des Unternehmens auf einer Seite darstellbar ist.

Die Prozesse-Landschaft hat neben der enormen Wirkung, die das gemeinsame Erarbeiten mit sich bringt, einen kommunikativen Vorteil. Einer unserer Klienten, Vorstand eines börsennotierten Unternehmens, sagte einmal, als wir gemeinsam mit ihm und seinem Team eine Prozesse-Landschaft erarbeitet hatten: «Jetzt haben wir endlich ein einziges Bild, anhand dessen wir unser ganzes Unternehmen auf einen Blick erklären können.»

Unabhängig davon, welche Methodik herangezogen wird – schliesslich ist Methodik stets nur Mittel zum Zweck – muss berücksichtigt werden, sich streng von oben nach unten durch die Prozesse zu bewegen. Dies kann nicht oft genug betont werden, gerät dieses streng hierarchische Vorgehen doch gern in Vergessenheit, wenn die Experten am Tisch um eine bestimmte Lösung ringen. Zu schnell ist man in Details, die noch gar nicht diskutiert werden müssen, mehr noch: die noch gar nicht diskutiert werden dürfen. Auch hier mag ein Beispiel hilfreich sein, das ein Projektteam-Mitglied eines Klientenunternehmens seinerzeit lieferte.

Die Dame fragte, wie sie die über 400 Detailprozesse, die sie im Rahmen ihrer Prozessdokumentationsarbeit vor unserem gemeinsamen Projekt erarbeitet hätte, «oben wieder zusammenbringen» solle. Meine Antwort lautete: «Gar nicht.» Das Zusammenführen von einigen Hundert Detailprozessen und Prozessschritten zu einem grösseren Ganzen ist die falsche Reihenfolge. Man kann es vergleichen mit einem Mobile, das man, liegt es auf dem Tisch, von der Spitze beginnend aufhebt und nicht vom Ende, will man es an der Decke aufhängen.

Wesentlich bei der Erarbeitung der Prozesse-Landschaft ist es – und dies zieht sich durch die gesamte Prozesserhebung hindurch – dass stets vom zu erzielenden Ergebnis aus gedacht wird. Die erste Frage muss also sein: «Welches Ergebnis soll der Prozess liefern?» Die zweite Frage ist: «Welche Voraussetzung muss zum Start vorliegen, damit der Prozess dieses Ergebnis produzieren kann?» Erst die dritte Frage beschäftigt sich mit dem Ablauf: «Welches sind die Schritte, die es zu gehen gilt, um die Wertschöpfung zwischen der Voraussetzung und dem angestrebten Ergebnis zu ermöglichen?» Diese drei Fragen sind – in dieser Reihenfolge – sowohl auf der Haupt- als auch auf der Teilprozess­ebene zu beantworten. Die Fragen nach der Verantwortlichkeit, den erforderlichen Dokumenten, Ressourcen, Spielregeln, und so fort sind sämtliche nachrangig. Dies ist insofern bemerkenswert, als dass regelhaft zu beobachten ist, dass diesen nachrangigen Fragen zu früh eine zu hohe Bedeutung beigemessen wird.

«Reengineering», «Business Process Reengineering», «Business Process Redesign», wie auch immer die Überschriften sind, die eine Reorganisationsmethodik für Geschäftsprozesse bezeichnen sollen: Es ist geschärfte Aufmerksamkeit geboten, denn vielen der Methoden ist gemein, dass sie nichts als ein Platzhalter sind, vielen von ihnen ist gemein, dass sie vor allem ihren Erfindern in Form von hohen Beratungshonoraren genutzt haben und vielen von ihnen ist gemein, dass sie zwar interessante Aspekte enthalten, aber nicht seriös genug durchdacht sind.

Zahlreiche Leser des vorliegenden Beitrags werden sich an den Bestseller «Reengineering» von Hammer und Champy erinnern. Dieses Buch ist ein prominenter Beitrag dafür, wie Arbeit an den Geschäftsprozessen meiner festen Auffassung zufolge nicht erfolgen sollte.

Das gesamte Reengineering-Denken, das in dem Werk propagiert wird, klingt ausgezeichnet, würde es nicht einen wesentlichen Faktor ausser Acht lassen: Den Menschen. Es ist aber genau der Mensch, an dem es liegt, ob die Geschäftsprozesse eines Unternehmens leistungsfähig sind oder nicht. Eine noch so perfekte Prozessdefinition mit noch so ansprechend scheinenden wirtschaftlichen Verbesserungspotenzialen bringt nichts, wenn es «menschelt». Prozesse scheitern nicht auf dem Papier. Prozesse scheitern in der Realität. Damit haben sie etwas gemeinsam mit Strategien, bei denen es sich genauso verhält. Es darf also denjenigen Mut zugesprochen werden, die sich der Mühe unterziehen, ihre Geschäftsprozesse unter Einbezug der Mitarbeiter zu definieren, auf den Prüfstand zu stellen und zu implementieren und nicht aus falsch verstandenem Perfektionsstreben heraus Prozesse zu definieren, die auf dem Papier zwar gut aussehen, in der Realität aber den Beweis der Leistungsfähigkeit schuldig bleiben. Man halte fest: Reengineering ist über­bewertet.

Unterbewertet hingegen werden regelmässig die Schnittstellen zwischen Prozessen, insbesondere dann, wenn es sich um Schnittstellen zwischen organisatorischen Bereichen handelt, oder – noch wichtiger – wenn es sich um Schnittstellen zwischen unterschiedlichen Unternehmen oder Partnern handelt.

An den Schnittstellen sind die wesentlichen Produktivitäts- und damit Wachstumsverluste festzustellen. Unabhängig davon, ob es sich um interne Schnittstellen, wie zum Beispiel die zwischen Marketing und Vertrieb oder die Schnittstelle zwischen Forschung und Entwicklung und Marketing oder gar um die Schnittstelle zwischen Produktion und Einkauf handelt oder ob es sich um Schnittstellen zwischen Lieferanten und dem eigenen Unternehmen oder gar um die Schnittstelle zwischen dem eigenen Unternehmen und seinen Kunden handelt: die Millionen werden zwischen den Prozessen vergraben, nicht in ihnen, um es einmal umgangssprachlich auszudrücken.

Der Grund dafür liegt auf der Hand: Während es noch vergleichsweise einfach erscheint, den eigenen Bereich prozessual zu ordnen, untersteht er doch sämtlich disziplinarisch der eigenen Kontrolle, fällt es vergleichsweise schwer, Einigkeit zwischen mehreren Bereichen oder gar mehreren Unternehmen herzustellen, um einen Gesamtprozess zu optimieren. Genau dies ist aber erforderlich, will man tatsächlich über Wertschöpfungsketten und nicht nur über einzelne Prozesse sprechen. Auch Schlagworte wie Supply Chain Management (SCM) oder Supply Chain Integration mutieren zu Platzhaltern, ist man nicht gewillt, über die Grenzen des eigenen Bereichs und des eigenen Unternehmens hinaus zu denken.

Es lohnt sich also, eine wesentliche Zeit im Rahmen der Konfiguration eines leistungsfähigen Prozessgefüges darauf zu verwenden, sich über die Schnittstellen Gedanken zu machen und sie aus Sicht des externen Leistungsabnehmers ziel­gerichtet zu gestalten.

Bei allem Perfektionsstreben: Es ist ausgesprochen unwahrscheinlich, dass die Definition eines konzeptionell leistungsfähig erscheinenden Prozessgefüges, einer leistungsfähigen Prozesse-Landschaft, sofort zum optimalen Ergebnis führt. Die gute Nachricht dabei: Dieses optimale Ergebnis ist auch gar nicht erforderlich, denn bereits die im Rahmen der Erarbeitung der Prozesse-Landschaft erfolgten Diskussionen werden dazu beitragen, dass sich die Prozessqualität und die Leistungsfähigkeit dramatisch erhöhen. Um den Lackmus-Test zu bestehen, ist der Über-Konzeption die Geschwindigkeit der Implementierung deutlich vorzuziehen. Es lohnt sich also, Prozesse, wenn alle Beteiligten sie verabschiedet haben, unmittelbar in die Realität umzusetzen, um sie zu testen und aus diesem Test zu lernen. Profitabel wachsende Unternehmen haben dies zu einer Maxime erhoben.

Wird dieses Lernen in einen regelhaften Prozess übersetzt, der sich mit der permanenten Optimierung im Sinne des externen Leistungsabnehmers beschäftigt, ist eine wesentliche Basis für das eigene unternehmerische Wachstum gelegt. «