In einem Harvard Artikel wurde letztes Jahr das „Neue-Säue-durchs-Dorf-Treiben-Phänomen“ etwas wissenschaftlicher als Lebenszyklus von Managementkonzepten entlarvt. Das ist an sich ja auch nicht verwerflich denn es folgt unseren marktwirtschaftlichen Prinzipien. Die Beratungsbranche schafft sich so immer wieder neue Nachfrage. Ich greife ja auch immer nach dem Shampoo mit dem Aufkleber „neue Formel“.
Mir tun halt nur die Konzepte leid. Sei es „Lean“, „Six Sigma“ oder „BSC“. Zunächst werden die Managementansätze gehypt und dann in der Entthematisierungsphase sind sie „verbrannt“, „falsch“ oder „old-school“. Fast wie in Beziehungen: am Anfang der Traumpartner, am Ende Rosenkrieg. Was mich an der ganzen Sache wundert beziehungsweise stört ist, dass wir nicht längst durchschaut haben, dass wir immer wieder auf die gleichen Muster hereinfallen. Nicht die Konzepte sind schlecht, die fehlenden Anwendungsvoraussetzungen und inkonsequenten Umsetzungen sind das Problem. (Die Beziehungs-Analogie führe ich jetzt besser mal nicht weiter 🙂 )
Ich greife das Thema heute vorbeugend auf, weil ich mir aktuell Sorgen um das Thema Agilität mache. Dem Lebenszyklus folgend ist das Thema in der Dominanzphase angekommen und so langsam beginnt der Abgesang. Gefühlt mehren sich nach Jahren von ausschließlich euphorischen Berichten über selbstorganisierte Arbeitsformen nun die kritischen Stimmen. Nicht, dass ich falsch verstanden werde. Die Artikel und Bücher, die die Schattenseite von Agilität, Selbstorganisation oder Holokratie näher beleuchten, thematisieren wichtige Risiken, Fallstricke, Tücken, Gefahren, Nachteile oder Misserfolgsstorys der Konzepte.
So werden beispielsweise in dem managerseminare-Artikel „Vorsicht Freiheit – Risiken der Selbstorganisation“ treffend Gruppendynamik, Unternehmensumfeld und der Mensch als wesentliche Risikofaktoren der Selbstorganisation identifiziert. Aber getreu der Reporter-Weisheit „Bad News are Good News“ wird dann beispielsweise etwas länger thematisiert, dass viele Menschen sich mit der Selbstorganisation aufgrund ihres Persönlichkeitstyps schwer tun. Nicht erwähnt wird jedoch, dass viele Menschen seit Jahren auch mit der teilweise willkürlichen Fremdsteuerung in der Hierarchie so ihre Probleme haben.
Die Gefahr solcher gut gemeinten kritischen Artikel ist, dass sie häufig ein gefundenes Fressen für Skeptiker und Bedenkenträger sind. Unter Managern und Mitarbeitern heißt es dann schnell und unreflektiert: „Siehste, Soziokratie klappt nicht“, „Hast du auch gelesen, das mit der Selbstorganisation ist riskant“ oder „Die Holokratie bei Zappos ist gescheitert“ …. Und dann auf zum nächsten Hype. Oh Mann …
Eigentlich würde ich ja jetzt gerne schreiben, dass ich nach dem Agilitäts-Hype als „Next Big Thing“ die organisationale Ambidextrie erwarte. Aber bevor ich selber die Lebenszyklus-Masche von Managementkonzepten befeuere, möchte ich das Muster brechen und mich für einen Evergreen stark machen. Es ist das alte Lied von der Balance von Stabilität und Flexibilität. Denn nichts anderes besingt die organisationale Ambidextrie, wenn sie die Fähigkeit von Unternehmen beschreibt, sowohl ihre Routineprozesse effizient abwickeln zu können als auch sich mit Ad-hoc-Prozessen flexibel auf neue Situationen einstellen zu können. Also stabile und agile Strukturen vereint unter einem Dach?
Letztlich folgt dieser jetzt mit Ambidextrie in Mode kommende Sowohl-als-auch-Ansatz auch wieder einem bekannten Muster in der Organisationslehre. Nämlich dem, zunächst das Gegenteil eines Ansatzes zu hofieren (z.B. divisional-dezentral versus funktional-zentral), um dann für den Mittelweg zu plädieren (Matrixorganisation). Ähnliches beobachten wir ja auch im Projektmanagement, wo aktuell nach dem Scrum-Siegeszug gegenüber dem Wasserfallmodell nun das hybride Projektmanagement angesagt ist.
Unabhängig von den Hype- und Etikett-Aspekten möchte ich im Folgenden einige Überlegungen anführen, wie man die organisationale Ambidextrie konkret gestalten kann.
Bei der organisationalen Ambidextrie unterscheidet man die kontextuelle und strukturelle Ambidextrie. In der kontextuellen Ambidextrie verlangt man von jedem die in seinem Job je nach VUCA-Umfeld und Cynefin-Situationen unterschiedlich einfach, kompliziert, komplex und chaotisch auftretenden Aufgaben mit entsprechend stabilen oder agilen Prozessen abzuarbeiten. Bei der strukturellen Ambidextrie verzichtet man auf die allgegenwertige Beidhändigkeit und bildet Einheiten, in denen entweder routiniert oder agil gearbeitet wird.
Für Unternehmen in Branchen, deren Gros der Prozessauslöser sich eher auf einer Seite des Cynefin-Modells befinden, wird die strukturelle Ambidextrie auch zukünftig sinnvoll sein. Dann bieten sich auf der einen Seite für die einfachen und komplizierten Fälle Bereiche mit hochstandardisierten und automatisierte Prozessen an. Für die komplexen und chaotischen Prozessauslöser auf der anderen Seite eignen sich projektorientierte Teilbereiche, die entsprechend der BIWAK-Prinzipien agil unterwegs sind.
Diese strukturelle Ambidextrie findet man seit jeher in der Industrie und mittlerweile auch immer mehr in industriell organisierten Dienstleistungsbranchen wieder. So konzipieren und bauen Arbeitsingenieure in autonomen Projekten innovative Fertigungsstraßen oder Softwareentwickler programmieren Workflowsysteme für Banken und Versicherungen. In ihren Projekten gehen sie agil vor, das Ergebnis ihrer Arbeit ist aber ein Routineprozess. Dieser wird nicht grundlegend nach kurzer Zeit verändert, er bleibt über Jahre stabil; schließlich hat man viel in die Fertigungsstraße oder das Workflowsystem investiert, das sich erstmal amortisieren muss.
Da es immer üblicher wird in Bereichen mit ausschließlich Routineprozessen, wie Produktion oder Call-Center, selbstorganisierte Teams einzuführen, könnte man ja auch meinen, dass es sich hierbei bereits um eine kontextuelle Ambidextrie handelt. Ich sehe das nicht so. Die Handlungs- und Gestaltungsspielräume der Mitarbeiter in diesen Prozessen sind insgesamt gering. Autonome Entscheidungen haben sie meist nur bei selbstorganisierten Schicht- oder Urlaubsplänen.
Kontextuelle Ambidextrie sehe ich in Zukunft vor allem für Unternehmen und Bereiche, deren Prozessmengen nicht so extrem verteilt sind. Also bei Firmen, die nicht ihr Geld mit Massen- oder Serienproduktion verdienen, aber auch nicht im Cynefin-Sinne vorwiegend im „chaotischen“ Feld tätig sind. Der Löwenanteil der Prozesse befindet sich in solchen tendenziell eher kleinen bis mittelständichen Firmen im Bereich der Regelprozesse. Das gilt sowohl für die eigentliche Wertschöpfung mit Prozessen wie Kundenprojekte, Produktentwicklung, Großkundenvertrieb oder Lieferantenmanagement, als auch für Unterstützungsprozesse wie Rekrutierung, Onboarding oder IT-Bereitstellung. Hier lohnt sich keine weitgehende Standardisierung, aber jedes Mal neu sollte man das Rad auch nicht erfinden.
Bei diesem Prozesstyp der Regelprozesse wundere ich mich immer wieder, wie die beiden Welten Projekt- und Prozessmanagement in Praxis und Wissenschaft nebeneinander her leben. So werden beispielsweise Projekte zur Produktentwicklung wieder und wieder durchgeführt; es werden aber keine wiederkehrenden Muster erkannt, die in einem Masterprozess festgehalten werden, um dann bei der nächsten Produktentwicklung als Blaupause genutzt werden zu können. Dabei liegt die Nahtstelle so offensichtlich auf der Hand. Projekte sind einmalige, Prozesse wiederkehrende Folgen von Aktivitäten.
Der Unterschied von Projekt und Prozess liegt also letztlich nur in der Anzahl der Durchläufe. Aber die ganzen Methoden, Techniken, Bücher, Konferenzen etc. zu Themen aus dem Prozess- und Projektmanagement existieren mehr oder weniger unabgestimmt nebeneinander. So findet man beispielsweise bei der Visualisierung von Projektabläufen Ganttdiagramme, Netzpläne oder Task-Boards. Modelliert man Prozesse nutzt man BPMN, Prozessdiagramme oder Folgepläne. Prozessmanagement-Berater analysieren Prozesse, indem sie Durchlaufzeiten, Prozesskosten und First Pass Yield berechnen. Projektbeteiligte analysieren den Puffer, Critical Path oder Burn-Down. Und dann gibt es noch die unzähligen Rollen und Jobs wie Prozessverantwortliche, Projektleiter oder Product Owner deren Aufgabenprofile sich in weiten Teilen ähneln, aber meist in Parallelwelten agieren.
Ich plädiere nun dafür, die Disziplinen Prozess- und Projektmanagement viel bewusster in den Unternehmen und in der Wissenschaft zu integrieren als das bis heute der Fall ist. Meiner Meinung nach ist das genau die erforderliche Kompetenz, die Unternehmen brauchen, um die Balance zwischen der VUCA-bedingten Flexibilität und der effizienzgetriebenen Standardisierung zu gestalten.
In dem aktuellen zfo-Artikel „Management von Einsatzprozessen“ wird eine interessante Analogie von Einsatzorganisationen wie Feuerwehr oder Rettungsdienst in hochriskanten Situationen zu Unternehmens im VUCA-Kontext hergestellt.
Solche Notfall-Einsätze entwickeln sich jedes Mal anders. Gerade die Reihenfolge der Aktivitäten wird flexibel in der Situation je nach Gefahreneinschätzung gehandhabt. Da es aber im wahrsten Sinne des Wortes häufig existenziell ist, bestimmte Aktivitäten schnell durchzuführen, ist ebenso eine hohe Effizienz durch Standardisierung von Aktivitäten notwendig. In den Einsatzorganisationen wird die Balance von Flexibilität und Stabilität durch Standardisierung von Einsatzprozessen je Schadensszenarioklassen gewährleistet. Dieses Vorgehen kennt man im Projektmanagement, wenn man Projektklassen definiert, die bestimmte Standard-Projektstrukturpläne nach sich ziehen. Der Triage-Ansatz sieht im Prozessmanagement ähnliches für verschiedene Prozessabläufe abhängig vom auslösenden Startereignis vor.
Mir hat in den letzten Jahren das Arbeiten mit Kanban-Boards vor Augen geführt, wie naheliegend und notwendig die Integration von Prozess- und Projektmangement vor allem bei den Regelprozessen ist. So „modelliere“ ich mittlerweile Prozesse wie Rekrutierung, Onboarding, Lösungsvertrieb oder Veranstaltungsorganisation als Master-Board. In der To-Do-Spalte stehen alle bis dato bekannten Tasks dieses Prozesses. Gibt es eine typische Reihenfolge der Aufgaben im Prozessverlauf, wird sie durch die Auflistung von oben nach unten angedeutet. Sie ist aber nicht zwingend vorgegeben, da ja genau die Reihenfolge-Flexibilität durch die Board-Bearbeitung (To Do – Doing – Done) gewollt ist.
Die Tasks auf dem Master-Board untergliedere ich, so weit wie möglich und sinnvoll, in einzelne wiederkehrende Tätigkeiten. Ganz nach der 5. Kaizen-Grundlage der Standardisierung mache ich nach der letzten Prozessdurchführung einen Rückblick (Manöverkritik, Retroperspektive oder Audit sind wieder Beispiele für unterschiedliche Begriffe mit ähnlicher Bedeutung im Projekt- und Prozessmanagement). So fließen KVP-mäßig verbesserte Taskausführungen in den Standard ein. Oder es werden Aufgaben ganz von der Liste genommen oder neue kommen hinzu.
Beispiel Onboarding: Kommt ein Mitarbeiter neu in die Firma, gibt es eine Vielzahl an Aktivitäten, die in den ersten Tagen und Wochen zu tun sind. Das reicht vom „Schlüssel übergeben“ über „Arbeitsplatz einnehmen“ bis hin zu „Adressverwaltung kennenlernen“. Da es häufig von der verfügbaren Zeit der Kollegen abhängt, werden die Tasks in unterschiedlichster Reihenfolge auf dem Board abgearbeitet. Und das ist bei diesem Prozess auch nicht kritisch, da es ja keine geborene Reihenfolge der Einarbeitungsaufgaben gibt. Zu Beginn der Einarbeitung wird das Masterboard Onboarding kopiert und damit ein individualisierter Prozess „Einarbeitung Michael Müller“ angelegt.
Und noch einmal die Analogie zur Einsatzorganisation. Masterboards entsprechen den dortigen Referenzprozessen, in denen für einen vorher definierten Schaden auf generischer Ebene Aufgaben enthalten sind. So gibt es beispielsweise Referenzprozesse für Brand, Brand im Hochhaus, Brand im Chemiewerk etc. Was für Notfälle verschiedene Schadensszenarioklassen sind, sind bei Regelprozesse von verschiedenen Objekten (Produkte, Kundengruppen etc.) ausgelöste Prozessvarianten.
Beispiel Onboarding: Unterscheiden sich die Aktivitäten bei der Einarbeitung je nach Mitarbeitergruppe deutlich, ist es sinnvoll jeweils ein Masterboard für „Onboarding Produktmanager“, „Onboarding Vertriebler“ oder „Onboarding Werkstudent“ anzulegen.
Das, was auf Boards in der Regel mit Tasks bezeichnet wird, nennt man im Prozessmanagement häufig Teilprozesse oder Aufgaben; im klassischen Projektmanagement spricht man von Arbeitspaketen, im agilen Umfeld formuliert man User Stories. Im Artikel zur Einsatzorganisation sprechen die Autoren von Standard Operating Procedures (SOP). Diese Standardvorgehensweisen kennt man bisher vor allem in der Medizin, in der pharmazeutischen Forschung, in der Luftfahrt und beim Militär. Eine SOP wird in § 2 Absatz 15 des Arznei- und Wirkstoffherstellungsverordnung definiert als „schriftliche oder elektronische Anweisung zur Beschreibung der einzelnen Schritte wiederkehrender Arbeitsgänge (Standardarbeitsverfahren), einschließlich der zu verwendenden Materialien und Methoden“.
Übertragen auf die hier im Fokus stehenden Regelprozesse sind SOP Standardvorgehensweisen für Teilprozesse, wie zum Beispiel „Brainstorming durchführen“ im Produktentwicklungsprozess, „Xing-Stellenangebot schalten“ im Rekrutierungsprozess oder „Social Media Accounts pflegen“ beim Einarbeitungsprozess.
Fazit und Ausblick
Im Zuge der Industrialisierung von Dienstleistungprozessen können wir Lean-Ansätze wie Pull-Prinzip, Standard-Reihenfolge und Taktung auf Routine-Büroprozesse anwenden, um diese effizient zu organisieren. Das klappt gut in stabilen Umfeldern und bei großen Stückzahlen. Bei kleineren Losgrößen im volatilem, unsicherem, komplexen und mehrdeutigen Kontext besteht die Herausforderung in der richtigen Balance zwischen Flexibilität und Standardisierung. Meiner Meinung nach besteht in der Integration von Vorgehensweisen, Rollen, Techniken und Tools aus dem Prozess– und Projektmanagement eine große Chance die erforderliche Beidhändigkeit in den Unternehmen erfolgreich zu gestalten. Durch die Kombination von Board-Modellierung auf End-to-end-Prozess-Ebene und Standard Operating Procedures auf Teilprozess-Ebene kann Kombination von Agilität und Stabilität praktisch umgesetzt werden. So kann sowohl flexibel auf Kundenanforderungen, technologische Neuerungen oder sonstige unvorhergesehenen Ereignisse reagiert werden, als auch eine höchstmögliche Effizienz durch maximal sinnvolle Standardisierung der Einzelschritte erreicht werden.
… und dafür braucht man dann auch gar kein neuen Zungenbrecher-Hype-Begriff wie Ambidextrie 😉