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

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.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.