On Lean and Agility

Zwölfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Suchen nach einem Schuldigen.

Dass immer dann, wenn irgendetwas schief gelaufen ist, zuerst nach einem Schuldigen gesucht wird, ist ein verbreitetes Phänomen. Wie konnte das passieren? Wer hat da nicht aufgepasst? Wessen Aufgabe wäre es gewesen das zu verhindern? Wer wäre verantwortlich gewesen für einen Prozess der das verhindert? Solche und ähnliche Fragen sind absolute Klassiker, wenn es um die Aufarbeitung geht, und sie alle haben eines gemeinsam: sie sind nicht besonders zielführend.

Zunächst führen sie immer wieder zu einem erstaunlichen Forschungs- und Exegese-Aufwand, um rückwirkend aus irgendeiner Vorschrift oder Abmachung ableiten zu können, wer sich theoretisch oder nach "gesundem Menschenverstand" hätte verantwortlich fühlen müssen, oder wer irgendwann mal eine Zusage gemacht oder eine Aufgabe übernommen hat, aus der sich die Verantwortung für das mittlerweile eingetretene Missgeschick ableiten liesse.

Umgekehrt ergeben sich aus ihnen ähnlich grosse Aufwände, mit denen alle, die für die Schuld in Frage kommen, belegen wollen, dass sie selbst in keinem Fall verantwortlich sind. Auch von ihnen werden alle möglichen Vorschriften, Abmachungen, Protokolle, Pläne, Zuständigkeitsbeschreibungen und sonstigen Dokumente gewälzt werden um mit deren Hilfe nachweisen zu können, zum jeweiligen Zeitpunkt nicht informiert, verfügbar oder zuständig gewesen zu sein.

Und damit endet es nicht. Sind einer oder mehrere Schuldige gefunden worden, werden sie erfahrungsgemäss erhebliche weitere Aufwände in Distanzierungen, Absicherungen und ähnliche Tätigkeiten stecken, um beim nächsten mal nicht mehr Schuld zu sein. Und sollte die Schuldzuordnung unklar gewesen sein, fliessen häufig erhebliche weitere Aufwände inzusätzliche Regeln, Dokumentations-Pflichten und weitere Massnahmen, um das nächste mal die Schuld klarer zuweisen zu können.

Nichts davon erzeugt einen Mehrwert, alles davon verbraucht Zeit und Energie. Es ist Muda in Reinform. 

Um eine Alternative aufzuzeigen: statt den Schuldigen zu suchen könnte man überlegen, wie man Prozesse sicherer oder unbürokratischer gestaltet, Kommunikation einfacher und direkter möglich macht, Qualitätssicherungs-Massnahmen einführt die nicht nur aus Dokumentations-Pflichten bestehen und vieles mehr. Das wären Schritte, die zwar auch Aufwand verursachen, aber einen der sich auszahlt und nicht bloss alle Beteiligten frustriert.

Bild: Unsplash / Glenn Carstens-Peters - Lizenz

Elfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: Inspect ohne Adapt.

In gewisserweise handelt es sich bei dieser speziellen Ausprägung um eine (wenn nicht sogar die) "agile Muda", da sie vor allem im Umfeld von (schlecht laufender) agiler Produktentwicklung anzutreffen ist. Sie liegt vor, wenn zwar regelmässig nach Verbesserungspotentialen oder Dysfunktionen gesucht wird, ein Auffinden einer solchen aber keine Schritte zur Folge hat, die den Zustand verbessern sollen. Ein klassisches Beispiel dafür wären Retrospektiven ohne Action Items.

Der Verschwendungs-Charakter dieses (Nicht-)Vorgehens ist offensichtlich: für das Suchen, Identifizieren, Beschreiben und Besprechen schlecht laufender Dinge ist Arbeitszeit nötig, und Zeit ist im Unternehmenskontext gleich Geld. Das ist in gewisser Weise gleich doppelt fällig - zum einen für die gerade genannten Tätigkeiten, zum anderen für das Nachholen anderer Aktivitäten, die wegen der so bereits vergebenen Arbeitskapazitäten in die Zukunft verschoben werden mussten.

Ein weniger offensichtlicher aber in seinen Auswirkungen nicht zu unterschätzender Effekt ist der in diesem Rahmen eintretende Motivationsverlust der Mitarbeiter, die erkennen, dass ihnen mit ihren Problemen nicht geholfen wird. Zum einen kann die daraus entstehende Frustration zu nachlassender Arbeitsleistung führen, zum anderen dazu, dass neu auftretende Probleme gar nicht mehr addressiert und bearbeitet werden, da mit ihrer Lösung gar nicht mehr gerechnet wird.

Im schlimmsten Fall entsteht zusätzlich zu diesen Effekten nochmal ein weiterer Verwaltungsaufwand, nämlich dadurch, dass die identifizierten aber nicht gelösten Verbesserungspotentiale und Dysfunktionen ggf. aufbewahrt und aktuell gehalten werden müssen. Die damit verbundenen Untersuchungs-, Informations-, Aktualisierungs- und Repriorisierungs-Aufwände überfrachten das ohnehin schon sinnlose Inspect ohne Adapt nochmal mit einer weiteren Muda, der Lagerhaltung.

Ein derartiges Verhalten abzustellen sollte aus diesen Gründen für jedes agile Team (aber auch für jedes andere Team bei dem es auftritt) eine hohe Priorität haben. Notwendig dafür ist es allerdings, den Teufelskreis einmal initial zu durchbrechen und dem Inspect auch ein tatsächliches Adapt folgen zu lassen, in diesem Fall eine Verhaltensänderung. Ist das aber einmal gelungen, kann in dem so gestarteten Verbesserungszyklus kontinuierlich an Fortschritten gearbeitet werden.

Bild: Flickr / Rosenfeld Media - CC BY 2.0

Einer der grossen Unterschiede zwischen den beiden populärsten agilen Frameworks, Scrum und Kanban, war immer, dass Scrum mit dem Scrum Guide ein verbindliches Regelwerk hatte, während Kanban trotz weit verbreiteter und allgemein anerkannter Praktiken eher "Open Source" war, so dass jeder hineindefinieren und -interpretieren konnte was er wollte. Diese Unklarheit hat immer wieder den Wunsch nach einem "Kanban Guide" aufkommen lassen.

Die erste Organisation die versucht hat diese Lücke zu füllen (bzw. den damit verbundenen Zertifizierungs-Markt zu erschliessen) war die Lean Kanban University, die 2016 den trotz seines Namens etwas aufgeblähten Essential Kanban Condensed Guide veröffentlichte, der dann 2021 durch den schlankeren "Official" Kanban Guide abgelöst wurde. Aufgrund seines Namens wird der immer wieder für das einzige und verbindliche Kanban-Regelwerk gehalten.

Da der Begriff und die Idee von Kanan nicht geschützt sind, gibt es aber auch Alternativen, unter denen die vielleicht bekannteste schlicht The Kanban Guide heisst. Selbst wenn seine Verfasser Daniel Vacanti und John Coleman mit ProKanban (einer anderen Zertifizierungs-Organisation) verbunden sind, ist das Dokument bewusst nicht mit deren Brand verbunden oder auf deren Website gehostet, um so seinen universellen Anspruch und seinen nicht-kommerziellen Charakter hervorzuheben.

Von seiner Struktur her organisiert er sich sehr stark am Scrum Guide, bis hin zu dem Punkt, dass mehrere seiner Abschnitte fast identisch benannt sind (Purpose of the Kanban Guide statt Purpose of the Scrum Guide, Definition of Kanban statt Scrum Definition, Kanban Theory statt Scrum Theory, etc.).¹ Lediglich in seinem Mittelteil gibt es Abweichungen, gegen Ende entspricht der Aufbau mit End Note und Acknowledements wieder sehr stark dem des Scrum Guides.

Inhaltlich sind es auch vor allem diese mittleren Abschnitte, die Kanban Practices, das Improving the Workflow und die Kanban Measures die interessant sind.² Den grössten Teil nehmen dabei die Practices ein, es handelt sich bei ihnen um Defining and Visualizing the Workflow, Actively Managing Items in a Workflow, Controlling Work In Progress und  Service Level Expectation.³ Nach Ansicht der beiden Autoren handelt es sich dabei um die unverzichtbaren Kernbereiche der Kanban-Methode.

Mit Actively Managing Items in a Workflow sind im Kanban Guide die Tätigkeiten gemeint, die den reibungslosen Durchfluss von Arbeit durch das System sicherstellen oder wiederherstellen sollen. Im Einzelnen sind das Controlling Work in Progress (d.h. dessen Menge), Avoiding work items piling up in any part of the workflow, Ensuring work items do not age unnecessarily (mit Hilfe von Service Level Agreements) und Unblocking blocked work.

Mit Controlling Work in Progress und Ensuring work items do not age unnecessarily bekommen die erste und letzte der zuletzt genannten Tätigkeiten noch einen eigenen Abschnitt, in dem tiefergehend erläutert wird, was sich dahinter verbirgt, bzw. welche weiteren Konzepte damit verbunden sind. Hier finden sich u.a. auch das Pull-Prinzip und das probabilistische Forecasting, die damit im Vergleich zu anderen Kanban-Auslegungen eine eher wenig prominente Plazierung haben.

Im Vergleich dazu ist das Improving the Workflow relativ knapp beschrieben. Hervorgehoben wird vor allem, dass es überhaupt stattfinden sollte, dass es auf der Grundlage von Zahlen und/oder Erfahrungen erfolgen sollte und dass es Verbesserungen der Effizienz, Effektivität und Vorhersagbarkeit zum Ziel haben sollte. Bemerkenswert ist, dass explizit nicht nur kleine sondern auch grosse Verbesserungen möglich sind, also nicht nur Kaizen sondern auch Kaikaku.

Die Kanban Measures sind schliesslich wieder die grossen Klassiker: Work in Progress-Menge, Throughput, Work Item Age und Cycle Time (Lead Time dagegen bemerkenswerterweise nicht). Neben ihrer kurzen Erklärung wird noch unterstrichen, dass sie nur zum Zweck der Prozessverbesserung erhoben und kein Selbstzweck sein sollen, und dass es möglich ist, sie um weitere Metriken zu ergänzen, wenn man darin einen Mehrwert sieht.

Was der Kanban Guide nicht (bzw. nur als Nennung optionaler Möglichkeiten) enthält, sind Meetings und Rollen. Es wird zwar erwähnt, dass es möglich ist, Dailies und Retrospektiven (die hier nur Reviewing the Definition of Workflow from Time to tTime heissen) abzuhalten, von einer zu starken Formalisierung wird aber abgeraten. Im Fall der Rollen ist nicht mal das gegeben, sie werden an keiner Stelle des Kanban Guide auch nur erwähnt, geschweige denn vorgegeben.

Zur Bewertung, bzw. Einordnung: das auf den ersten Blick Auffälligste am Kanban Guide dürfte die starke Anlehnung seiner Struktur an die des Scrum Guide sein. Die mag ihre Vorteile haben, da jemand der bisher nur Scrum kennt sich leichter zurechtfinden wird, andererseits wirkt sie etwas gezwungen und z.T. sogar un-originell, etwa in den End Note, die in einigen Passagen eine Eins-zu Eins-Kopie ist. Auch die Definition of Workflow wirkt etwas gezwungen.

In Abgrenzung zum "Official" Kanban Guide der Kanban University ist erkennbar, dass die jeweiligen Verfasser jeweils unterschiedliche Elemente für wichtig oder verzichtbar gehalten haben. Während z.B. im "Official" Kanban Guide Aufbau und Nutzung eines Kanban-Boards einen grossen Platz einnehmen, fehlen sie in The Kanban Guide völlig. Das macht einmal mehr die Gestaltungsoffenheit von Kanban deutlich (die dann allerdings mit den Mindestvorgaben der Verfasser kollidiert).

Genau die Offenheit an dieser Stelle, durch die klar wird, dass Kanban zwar in Form eines Boards mit Kartenoder Kacheln dargestellt werden kann, aber keinerswegs dargestellt werden muss, ist übrigens eine, die grossen Teilen der Kanban-Community fehlt (Alternativen sind Ampelfarben, Kontroll-Charts, Kummulative Flussdiagramme, etc.). Alleine in dieser Hinsicht ist Vacantis und Colemans Guide eine wertvolle Ergänzung.

Auffällig ist ausserdem, dass ihr Regelwerk nochmal kürzer und komprimierter ist als die von Scrum und der Kaban University. Einschliesslich Inhaltsverzeichnis umfasst er nur neun Seiten. Aufgrunddessen kann man ihn auch ohne grossen Aufwand als Ergänzung zum nur unwesentlich längeren Guide der Kanban University benutzen, alleine um verschiedene Blickwinkel auf das Thema Kanban zu bekommen, dass sich mit einem Dokument alleine kaum abbilden lässt.

Bild: Pexels / Ketut Subiyanto - Lizenz

Es ist mal wieder Zeit für eine Agile Success Story. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen, das kann man viel zu oft bei Agile Coaches, Scrum Mastern und ähnlichen Rollen erleben. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich selbst erlebte "agile Erfolgsgeschichten" veröffentliche, heute eine zum Thema Kanban.

Eigentlich hatte ich den Auftrag gar nicht annehmen wollen. Insgesamt sieben verschiedene Abteilungen eines Kunden wollten "ihre Zusammenarbeit agiler machen", davon drei Fachabteilungen, zwei aus der IT, eine aus Operations und eine aus dem Einkauf. Das klang als Herausforderung durchaus spannend, das Problem war aber das Budget - für eine Woche in Vollzeit würde es reichen, danach nur noch für vier Tage pro Monat während des restlichen Jahres. Im Grunde viel zu wenig.

Am Ende liess ich mich darauf ein, wenn auch mit einer klaren Einschränkung: in dieser knappen Zeit würde zu Beginn kaum mehr möglich sein als die Ermittlung und Visualisierung des Value Streams, und in späteren wöchentlichen Terminen ein Inspect & Adapt in kleinen Schritten. Die urspünglich vom Kunden gewünschte Einführung eines agilen Skalierungsframeworks wäre mit diesem geringen Aufwand illusorisch gewesen. Das wurde angenommen, also legten wir los.

Bereits das Value Stream Mapping war dann anspruchsvoll genug. Es handelte sich um eine geschäftskritische Anwendung, die auf Wunsch interner und externer Stakeholder ständig weiterentwickelt wurde. Neue Features wurden jeweils von einer der drei Fachabteilungen beauftragt und entweder von einer der beiden internen IT-Abteilungen oder durch externe Dienstleister (koordiniert durch den Einkauf) entwickelt.

Das, was dieses Vorgehen schwierig machte, waren Unübersichtlichkeit und Intransparenz. Es gab so viele Feature Requests (die natürlich alle dringend waren), dass niemand einen Gesamtüberblick darüber hatte, welche internen oder externen Entwickler gearde im Auftrag welcher Fachabteilung etwas umsetzten. Das Ergebnis waren redundante Arbeiten, die Entwicklung inkompatibler Features, ständige Nacharbeiten, zu hohe Arbeitsbelastung und ständig gerissene Deadlines.

Nach einer Woche intensiven Nachforschens gab es dann ein erstes Ergebnis: abhängig von den beiden Variablen bestehendes/neues Budget und interne/externe Entwicklung liessen sich drei Varianten des Value Streams identifizieren, eine mit 10 Stationen, eine mit 15 und eine mit 19 (!). Da das bei weitem zu viel war um auf einem Bildschirm überblickbar zu sein, fand die Visualisierung in Form eines physischen Kanban-Boards statt - Drei Zeilen mit jeweils 10, 15 und 19 Spalten.¹

Bis zu unserem ersten Einzeltermin hatten die verschiedenen Einheiten sich dann die Aufgabe mitgenommen, alle grösseren Arbeitspakete an denen sie gerade sassen auf dieses Board zu bringen. Als ich nach einer Woche zurückkam war ich erstmal erschlagen - mehr als 60 verschiedene Zettel hingen über das ganze Board verstreut, jeder einzelne davon als Symbolisierung eines Gesamtaufwandes von mindestens einer Personenwoche. Kein Wunder, dass bisher die Übersicht gefehlt hatte.

Eigentlich hatte ich als nächstes vor diesem Board ein Daily etablieren wollen, was aber in einem lauten Proteststurm unterging ("Nicht noch mehr Meetings", wurde gefordert). Worauf sich alle einlassen konnten war aber ein wöchentlicher Termin, in dem Vertreter der sieben Abteilungen alles was in den letzten Tagen stattgefunden hatte auf dem Board aktualisierten, egal ob es neue Requests, Entwicklungsfortschritte, Budget-Zusagen oder sonst etwas waren.

Was in diesen Terminen auffällig war, war, dass nahezu jede Aktualisierung eine mittelgrosse Diskussion auslöste. Deren Inhalte reichten von Überraschung und Interesse über Zustimmung und Feedback bis hin zu Protest und Sinnfragen. Nahezu jeder der teilnahm hatte irgendetwas zu irgendeinem Thema beizutragen, so dass es regelmässig mehr als zwei Stunden dauerte, bis auf dem Board alles auf den aktuellen Stand gebracht war.²

Das wirklich Bemerkenswerte an diesen "Kanban Weeklies" war aber nicht ihre Länge. Anders als man es hätte erwarten können gab es kaum Beschwerden darüber, dass in sie so viel Zeit investiert werden musste oder dass in ihnen so viele Themen diskutiert wurden. Stattdessen wurde regelmässig hervorgehoben, wieviel grösser durch sie Transparenz, Übersichtlichkeit und als Folge dessen auch Planbarkeit und Reaktionsfähigkeit geworden wären.

Gleich mehrfach konnten neue Feature Requests einzelner Fachabteilungen bereits im Anbahnungsstatus gestoppt werden, weil eine der anderen darauf hinwies, etwas Vergleichbares bereits beauftragt zu haben. Die Entwicklungsabteilungen konnten besser absehen, wann grössere Arbeitspakete bei ihnen einschlagen würden und sich entsprechend Zeit einplanen. Die Operations-Abteilung konnte sich auf Lastspitzen durch neue Features besser einstellen. Etc, etc, etc.

Selbst wenn es WIP-Limits, Service-Klassen, Durchlauf-Metriken und viele andere Ideen die ich hatte aufgrund des beschränkten Zeitbudgets nicht mehr in dieses Kanban-System geschafft haben, wurden das Board uns seine Benutzung von allen Beteiligten als eine spürbare Verbesserung gesehen, durch die die meisten der oben genannten Probleme (redundante Arbeit, Intransparenz, ständige Nacharbeiten, etc.) spürbar zurückgegangen waren.

Auch ich habe aus diesem Einsatz eine Lehre mitgenommen: auch eine punktuelle Begleitung kann unter Umständen völlig ausreichend sein. Es braucht nicht immer einen Scrum Master, Kanban Coach oder sonstigen Methodiker, der in Vollzeit ein Team begleitet, manchmal kann es genügen, den Arbeitsfluss zu visualisieren, alle Beteiligten dazu zu bewegen ihn sich regelmässig gemeinsam anzusehen und darauf zu vertrauen, dass sich daraus die richtigen Dinge ergeben werden.

Bild: Pexels / Thirdman - Lizenz

Zehnter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann, kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Overthinking.

Zuerst ein Übersetzungsversuch. Für den Begriff Overthinking gibt es keine exkte Entsprechung in der deutschen Sprache, eine sinngemässe Übersetzung wäre "länger über etwas nachdenken als sinnvoll ist" oder "unverhältnismässig lange über etwas grübeln". In beiden Übersetzungs-Varianten ist die Muda-Natur bereits offensichtlich enthalten, bei näherer Betrachtung lassen sich aber ausserdem noch verschiedene Problem-Dimensionen erkennen.

Zum einen kostet ein unnötig langes Nachdenken die Beteiligten (Arbeits-)Zeit und damit ihr Unternehmen auch Geld. Das führt entweder dazu, dass sie nicht mehr für andere Tätigkeiten verfügbar sind (dazu gleich mehr) oder es hat zur Folge, dass zur Kompensation dieser Ausfälle weitere Menschen eingestellt werden müssen. Der zweite Fall wird nochmal schwerwiegender dadurch, dass diese Einstellungen (plus Koordination, Bezahlung etc.) weitere Verwaltungsaufwände erzeugen.

Zum anderen kann es zum Phänomen der Verzögerungskosten (Cost of Delay) kommen. Wird die durch das Overthinking entstehende Mehrarbeit nicht durch zusätzliches Personal kompensiert, schieben sich andere Tätigkeiten zwangsläufig nach hinten, wodurch sich Einnahmen verzögern (und dadurch kleiner ausfallen) können, Geschäfts-Chancen verschwinden können oder zusätzliche Zinsen auf alte oder neue Kredite anfallen können, die zur Kompensation ausfallender Einnahmen nötig werden.

Angesichts dieser Nachteile stellt sich die Frage, warum das Overthinking in vielen (vor allem grossen) Organisationen so weit verbreitet ist. Die Antwort kann natürlich je nach Einzelfall eine andere sein, häufige Gründe sind meiner Erfahrung nach aber Perfektionismus, Machbarkeits- und Steuerbarkeits-Illusionen, Risiko-Aversion (häufig verbunden mit knappen Budgets, deren Verwendung man unter Kontrolle halten will) und fehlende Systemsicht.

Um die nicht gewinnbringende, aber ressourcenverbrauchende Muda des Overthinking in den Griff zu bekommen, ist es daher erfolgsversprechend, zu untersuchen ob eine diese zugrundeliegenden Ursachen gegeben ist, um diese zu thematisieren und möglichst zu beseitigen. Selbst dann wenn das nicht gelingt, kann aber alleine die Erkenntnis der problematischen Effekte ausreichend sein, um ein Zurückfahren der Grübel-Aufwände auf ein sinnvolles Mass zu verursachen.

Zu meinen Lieblingsbeispielen für kontinuierliche Verbesserungsbemühungen zählen Einrichtungen, die man damit nicht sofort assoziieren würde: deutsche Behörden. Optimiert wird auch in ihnen, und da man sie nur in relativ grossen Abständen aufsucht, ist die Chance gross, dass einem jedesmal irgendetwas auffällt, das anders ist als beim letzten mal. In meinem Fall sind es die Bürgerämter meiner Wohnorte (z. Zt der Stadt Bonn), in denen ich etwa einmal pro Jahr erscheinen muss.

Bevor wir zu meinen Beobachtungen kommen, macht zuerst eine kurze Erläuterung zu dem "Verbesserungsgegenstand" Sinn: das was im Bürgerzentrum regelmässig optimiert wird, ist der Durchfluss von Kunden, also Bürgern, die für irgendeinen Verwaltungsakt dort vorstellig werden müssen. Um diesen eine möglichst gute Service-Erfahrung zu geben, und um die Servicekräfte optimal auszulasten, sollten Staus und Wartezeiten so gering wie möglich sein.

In der weit zurückliegenden Anfangszeit der Optimierungen war das noch nicht der Fall. Jeder der mit einem Termin oder als Laufkundschaft zur Stadt kam meldete sich an, setzte sich in einen Warteraum und wartete dort darauf, dass der eigene Name aufgerufen wurde. Wie lang das dauern würde liess sich nicht absehen, Wartezeiten von über einer Stunde waren nicht selten. Diese Unklarheit über die verbleibende Wartezeit war das erste, das durch eine Prozessanpassung behoben wurde.

Irgendwann wurden Wartenummern eingeführt, zu Beginn noch solche in Papierform, die man sich aus einem vor Ort stehenden Automaten ziehen musste. Aufgerufen wurden jetzt nicht mehr die Namen sondern die Nummern, wodurch sich erkennen liess, wie viele andere Personen vor einem selbst bedient werden würden. Liess sich so erkennen, dass es noch dauern würde, konnte man kurz vor die Tür gehen, Geld in die Parkuhr werfen, etwas rauchen oder sonstige kurze Erledigungen machen.

Der nächste Verbesserungsschritt war die Einführung grosser Bildschirme, auf denen die zuletzt aufgerufenen Nummern angezeigt wurden. Für den Fall, dass man verspätet eintraf oder den eigenen Aufruf überhört hatte, konnte man dort sehen, dass man bereits an der Reihe war. Eine darauf aufbauende Verbesserung bestand daraus, dass dort auch die Tischnummer der nächsten freien Servicekraft angezeit wurde, wodurch der bis dahin nötige Gang zum Zentralschalter entfiehl.

Die hinter der Anzeigetafel arbeitende Software wurde später mit einer weiteren verbunden, mit der man Terminbuchungen online vornehmen konnte. Sobald man einen Termin gebucht hatte erhielt man eine Mail. in der nicht nur die Terminbestätigung stand, sondern auch die Wartenummer. Vor Ort musste man dadurch nicht mehr eine Nummer ziehen und warten, sondern konnte direkt überprüfen, ob man bereits aufgerufen wurde.

Die vorerst letzte Optimierung, die mir bei meinem letzten Besuch aufgefallen ist, besteht darin, dass man jetzt vor Ort grosse Touch-Displays hat, auf denen man durch Eingabe seiner online gebuchten Wartenummer mitteilen kann, dass man angekommen ist und aufgerufen werden kann. Verspätungen sind dadurch kein Problem mehr, man rutscht stattdessen weiter nach hinten in die Reihenfolge, aus der zuerst andere Nummern aufgerufen und bedient werden können.

Weitere Prozessverbesserungen dürften in diesem Zeitraum auch ausserhalb des für die Kunden sichtbaren Bereichs stattgefunden haben, alleine im Bereich der Digitalisierung kann man sich so einiges vorstellen. Über die Jahre wird es so zu einem ingesamt beachtlichen Umfang von Veränderungen gekommen sein.

Diese Art der nach und nach stattfindenden Optimierung hat mehrere Vorteile gehabt: grosse, disruptive Veränderungen wurden unnötig, die Folgen der jeweils letzten Umstellung liessen sich aufgrund der kleinen Umfänge besser identifizieren und bewerten, und in Summe ist es so zu einem Prozess gekommen, der nicht nur gut funktioniert, sondern auch einer ist, auf den beim Versuch alles im Voraus zu planen vielleicht niemand gekommen wäre.

Zuletzt hat der KVP (Kontinierliche Verbesserungsprpzess) im Bürgeramt noch einen Vorteil auf der Meta-Ebene: er hat an einem Ort stattgefunden, den jeder Mensch in Deutschland kennt, ins Bürgeramt muss früher oder später jeder. Es ist damit ein Praxisbeispiel das sofort jeder nachvollziehen kann und anhand dessen man Prozessoptimierungen auch für Menschen, die selten damit zu tun haben, nachvollziebar erklären kann.