Direkt zum Hauptbereich

Wie adaptiv sind Ihre Prozesse? Teil 2: Die Adaptivität

Heute früh habe ich die verschiedenen Strukturierungsgrade von Prozessen dargestellt und mich dabei des Cynefin-Modells von Snowden bedient. Aber Prozesse sind nicht nur unterschiedlich strukturiert, sondern auch in verschiedenem Maße adaptiv. Beide Begriffe werden oft verwechselt. Die Adaptivität von Prozessen ist aber entscheidend für Organisationen in einem bewegten Umfeld. Zum Beispiel für Unternehmen, deren globale Märkte disruptiven Änderungen unterworfen sind. Oder werteorientierte Organisationen in einer Welt heftigen Wertewandels.
(Artikel von heute früh: http://www.teamworkblog.de/2015/05/wie-adaptiv-sind-ihre-prozesse-teil-1.html )

Adaptivität von Prozessen

 

Statt langer Erklärungen ein Bericht aus der Praxis und zwar aus dem Buch von Detlef Lohmann. Lohmann hat nach einigen Erfahrungen mit herkömmlichem Prozessverständnis sein Unternehmen völlig umgekrempelt. Er berichtet über eine seiner ersten Erfahrungen als frischgebackener CEO:

"Mit raschen Schritten bin ich unterwegs in die Produktionshalle. Über Nacht ist mir eine gute Idee gekommen, wie ich die Arbeitsabläufe verbessern kann. (...)
'Herr Büttner, Sie machen doch die Qualitätskontrolle der fertigen Produkte. Wenn Sie in Zukunft Ihre Ergebnisse immer sofort an die Kollegen von der Produktion weitergeben, können die sie gleich berücksichtigen. So vermindern wir Ausschuss.'
'Das geht nicht, das steht nicht auf meinem QUBIS-Sheet', antwortet Herr Büttner. 'Laut QUBIS muss ich das Kontrollergebnis erst von Herrn Wenzinger von der Abteilung Interne Prüfung freigeben lassen, bevor ich es weiterleite.'
Ich drehe mich zum leeren Arbeitsplatz von Herrn Wenzinger um und dann wieder Herrn Büttner zu.
'Aber Herr Wenzinger ist doch nur halbtags da! Während Sie auf seine Freigabe warten, entstehen in der Produktion vielleicht weitere mangelhafte Teile.'
Herr Büttner macht zwei Schritte zurück. 'Ich kann nichts machen, was nicht im QUBIS steht', beharrt er. (...)
Immer dieses QUBIS! (...)
Herr Büttner beugt sich wieder über seine Listen mit den Prüfergebnissen. Ich gehe langsam in mein Büro zurück." /1/

Stellen Sie sich einen Koch vor, der arbeiten wollte wie Herr Büttner. Jeder Pizzabäcker hat ein ganz anderes Verständnis von seinen Pizzarezepten als Herr Büttner von der Rolle seiner Prozessbeschreibung. Ein Pizzarezept ist keine Vorschrift, sondern ein Ratgeber. Und es ist gleichzeitig eine Aufforderung zum Experiment. Pizzabäcker Giovanni will sich dem deutschen Geschmack anpassen und legt Ananas auf seine Thunfischpizza. Brrh! das Pizzaverständnis mangelt noch, aber sein Prozessverständnis ist gut. Als guter Koch gilt nicht jemand, der alles streng nach Rezept kocht, sondern einer, der viel ausprobiert und so die Rezepte entwickelt.

Wir nennen Prozesse, wie von Detlef Lohmann beschrieben, niedrig adaptiv. Sie können nur schwer oder gar nicht an neue Herausforderungen oder an neue Ideen angepasst werden. Der Pizzaprozess von Koch Giovanni hingegen ist hoch adaptiv. Er probiert dauernd Neues aus.

Entwurf einer Stufenleiter

 

Versuchen wir es mit ein bisschen System.
Wir nennen einen Prozess hoch adaptiv, wenn die verantwortlichen (Vorgangs-)Teams die Abläufe der einzelnen Vorgänge oder auch der Prozesse schnell und effizient anpassen (adaptieren) können. Ein Prozess ist niedrig adaptiv, wenn vor eine Anpassung hohe Hürden aufgebaut sind.

Diese Hürden können sein:
  • starre Vorschriften
  • starre, in nur schwer anpassbare Software gegossene Workflows
  • Unternehmenskulturen, die bestimmte traditionelle Arbeitsweisen bevorzugen und z. B. eine Abneigung gegen Experimente stützen.

Wir schlagen folgende Stufen der Adaptitivät von Prozessen vor:

Tabelle 1: Stufen der Adaptivität

Mit diesen Stufen wird in Kombination mit der Cynefin-Skala ein zweidimensionales Modell, das „Fadenkreuz der Prozesse“. Ein Prozess wie die Rechnungsverbuchung /2/ kann zwar stark strukturiert sein, aber unterschiedlich adaptiv.

Abb. 1: Unterschiedliche Adaptivitätsgrade von Prozessen
Abbildung 1 zeigt das an zwei Beispielen. Im vorhergehenden Blogartikel war vom Prozess „Rechnungen verbuchen“ die Rede. Es ist ein stark strukturierter Prozess. Aber auch dieser kann „gestört“ werden. Z. B. kann der Mitarbeiter, der die Rechnung als richtig abzeichnen muss, in Urlaub oder krank oder ausgeschieden sein. Was kann die Poststelle machen, die die Rechnung ihm eigentlich zustellen muss?

Möglichkeit 1: Sie macht gar nichts. Weil sie nichts machen darf, oder nur auf eine Gelegenheit wartet, ihre „Nicht-Zuständigkeit“ zu demonstrieren. Oder weil die verwendete Workflow-Software diese Art der Störung nicht vorsieht und nicht angepasst werden kann. – Diese Stufe der (Nicht-) Adaptivität bezeichnen wir als „blockiert“.

Möglichkeit 2: Die Poststelle kann und darf eine Einzelfalllösung suchen, also im Haus herumtelefonieren, ob sich jemand der Rechnung erbarmt. – Das nennen wir „Workaround“.

Möglichkeit 3: Die Poststelle kann (vielleicht zusammen mit einem Superuser) die Workflow-Software schnell und unkompliziert anpassen. In diesem Falle sprechen wir von Prozessbeherrschung“.

Diese verschiedenen Stufen der Adaptivität gibt es auch bei komplexen Prozessen, z. B. im Krankenhaus bei der Behandlung von Patienten. Die seit ein paar Jahren geltende Regelung der Fallpauschalen (nach Diagnosegruppen, sog. DRG’s) enthält sehr starre Vorschriften. Wenn der Fall eines Patienten in keine DRG-Schublade passt, steht das Krankenhauspersonal bisweilen vor der Wahl: entweder Geld zu verlieren oder den Patienten unsachgemäß zu behandeln.
Was tun die Verantwortlichen in einem konkreten Krankenhaus? Machen sie „Dienst nach Vorschrift“ (blockiert)? Erfinden sie kreativ eine DRG-Zuordnung, die eigentlich nicht ganz legal ist, aber sie aus der Zwickmühle befreit? Oder ist der Patient Selbstzahler und nicht den DRG-Regeln unterworfen, so dass das Krankenhaus den Behandlungsvertrag jeweils frei verhandeln kann? Drei ganz verschiedene Stufen der Adaptivität!

Mit dem Fadenkreuz der Prozesse lassen sich auch die Ziele von Organisationsentwicklungen plastisch darstellen.

Abb. 2: Was sind die Ziele unserer OE-Maßnahmen?

Viele Organisationen streben nach Standardisierung ihrer Prozesse oder von Teilen davon. Dagegen ist auch gar nichts zu sagen, denn damit werden ja potenziell unproduktiv gebundene Ressourcen für produktive Zwecke freigesetzt. Gerade bei Software-Projekten ist aber die unangenehme Nebenwirkung, dass die Adaptivität sinkt. Diesen Fall zeigt die Abbildung 2 als „Zielsituation 1“. Die Organisation gießt ihre Prozesse in eine relativ starre Software und vermindert ihre Adaptivität.

In der aktuellen Situation aber, in der z. B. die Volatilität der Märkte zunimmt und Unternehmen immer schneller ihre Prozesse umstellen müssen, kann das extrem schädlich sein. Deshalb ist bei der Zielbestimmung von OE-Projekten immer darauf zu achten: erkaufe ich mir vielleicht eine (erwünschte) Zunahme an Strukturierungsgrad mit einer (gefährlichen) Abnahme meiner Adaptivität?


Vielleicht wäre es ja besser, künftig mehr Organisationsentwicklung in Richtung "Zielsituation 2" in der Abbildung zu verfolgen: Also stärkere Strukturierung mit höherer Adaptivität zu verbinden. (Aber vielleicht braucht es dazu eine andere Software-Architektur.)

Wie ist es bei Ihnen? Wie adaptiv sind Ihre Prozesse?

Anmerkungen

  • /1/ Detlef Lohmann: „... und mittags geh ich heim. Die völlig andere Art, ein Unternehmen zum Erfolg zu führen.“ Linde Verlag Wien, 2012, Seite 38
  • /2/ Siehe Post von heute früh.

Kommentare

Beliebte Posts aus diesem Blog

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Erfahrung mit Vibe-Coding - und warum das keine Teamprobleme löst

Die KI-Werkzeuge zum Erstellen von Werkzeugen für die tägliche Arbeit werden immer besser. Die selbstgestrickten Tools erleichtern die eigene Arbeit. Aber für den Einsatz im Team fehlt noch etwas.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Wenn Leisten Leistung kostet

Immer. Immer "on". Immer mehr. Immer schneller. Und natürlich: Immer besser. Das ist die Welt, in der wir heute leben. Eine Welt der Dauerleistung. Und die hat ihren Preis: Wir werden schwächer. Sofern wir nicht die Grundlagen guten (Selbst-)Managements beherzigen und Pausen machen. Also zur richten Zeit das wirklich Wichtige tun.

A shared file storage is not a library

In over 90% of cases where we advise organizations on filing systems, we find that they are organized by topic. This system quickly leads to chaos because outdated documents are not disposed of quickly enough. So why does everyone think to structure their filing system by topic? I believe we have the wrong idea.

From False Starts to Precision Landing: The Evolution of Requirements Management

Requirements management originated in U.S. rocket programs between 1945 and 1970. A small management trick contributed to the success of the Apollo program.

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Wie läuft ein Projekt zum Entwickeln von Szenarien ab?

Seit 2016 beschäftigen Edgar und ich uns intensiv mit der Szenariotechnik. Szenarien sind ein wirkungsvolles Werkzeug, um Projekte oder ganze Geschäftsmodelle auf ihre Zukunftstauglichkeit zu testen.