Small is beautiful

Beschreibung

Grösse führt immer zu Problemen. Das trifft auf Projekte und Programme, aber auch auf

ganze Organisationen zu. Mit steigender Grösse wächst die Komplexität. Eine Aufgabe unter zehn Menschen zu verteilen ist einfach. Die Zusammenarbeit mit 150 Menschen ist schon herausfordernder. Alles darüber gestaltet sich zunehmend schwierig. Der Koordinationsaufwand steigt und das Vertrauen zwischen allen Beteiligten nimmt ab. Letzteres ist vor allem dann in Gefahr, wenn sich die Menschen aufgrund der Organisationsgrösse nicht mehr kennen. Vertrauensprobleme sind häufig und werden häufig falsch gelöst. Das Anti-Pattern Wenn du Vertrauen forderst, hast du schon verloren zeigt die Problematik dahinter.

Grosse Probleme erfordern grosse Lösungen. Erfolg führt ganz natürlich zu Wachstum. Ein Unternehmen will mehr verkaufen, vergrössert seinen Aussendienst und damit auch seine HR-Abteilung, um die zusätzlichen Mitarbeitenden verwalten zu können. Die IT-Infrastruktur wird häufiger benutzt, es treten mehr Fragen auf und der IT-Support steigt. Ein wachsendes Unternehmen erzielt dabei Vorteile wie Skalenerträge und Kostenersparnisse, aber auch Nachteile in Form von Komplexität und erschwerter Kommunikation.

Den Nachteilen lässt sich begegnen, indem aus grossen Einheiten wieder möglichst kleine werden. Wie geht das? Durch die Anwendung des Subsidiaritätsprinzip. Dieses verlangt, Entscheidungen möglichst weit unten zu treffen und funktionsübergreifende Teams zu bilden (siehe auch Follow the Money). LeSS ist ein Rahmenwerk für Scrum mit mehr als einem Entwicklungsteam. Darin finden wir den Ansatz der De-Skalierung, d.h. grosse Einheiten so aufzuteilen, dass sie möglichst wenig Abhängigkeiten haben und die Vorteile kleinerer Einheiten auszuspielen. In kleinen Einheiten lassen sich Kommunikation und Abhängigkeiten einfacher steuern. Epics lassen sich schneller in Ergebnisse transferieren. Durch das sogenannte «Slicing», also das intelligente Auseinandernehmen von Arbeitspaketen in sinnvolle Einzelteile, wird die Zusammenarbeit stark vereinfacht.

Dieses Vorgehen ist jedoch nicht für alle Arbeiten sinnvoll. Wir fokussieren uns hier auf Wissensarbeit in einem komplexen Umfeld. Für einfache Arbeiten bietet sich Outsourcing an. Doch vielschichtige Probleme bedingen einen anderen Lösungsansatz. Das Cynefin-Framework zeigt auf, welche Problemarten es gibt, und wie sich diese am besten lösen lassen. Wissensarbeiter befassen sich häufig mit komplexen Problemen, wie zum Beispiel Softwareentwicklung. Das Problem lässt sich nur mit einer emergenten Praxis (“Herausbildung der Lösung") lösen. Grosse Probleme werden in kleinere Probleme aufgebrochen, die einzeln auf verschiedene Lösungsansätze getestet werden.

Industrielle Arbeit hingegen befasst sich häufig mit komplizierten Problemen, wie der Tunnelbau. Der Berg, also das Problem, kann vorab untersucht werden. Abhängig von Gesteinsart und weiteren Variablen lässt sich ein Zeitplan für die Realisation erstellen. Natürlich kann es auch hier zu chaotischen Situationen wie einem Wasserrohrbruch kommen. Doch im Unterschied zu komplexen Problem, ist die Herausforderung und das Ziel immer bekannt. Bei Wissensarbeitern hingegen lassen sich Probleme nicht per Definition lösen. Zuerst muss herausgefunden werden, was das Problem überhaupt ist. Nutzer können häufig erst zum Ausdruck bringen, was sie brauchen, wenn sie das Produkt oder den Service vor sich sehen. Die Entwicklung einer Software beginnt mit Marktforschung. Was will der Markt? Hier müssen sich die Wissensarbeiter in kleinen Schritten herantasten. Auch Corona ist ein Beispiel für ein komplexes Problem. Zu Beginn wusste man kaum etwas über das Virus. Erst durch viele Forschungsversuche und Tests näherte man sich einer Lösung zur Eindämmung der Krankheit.

Negative Beispiele

Konzerne, die der Muster «Small is beautiful» nicht folgen, haben häufig Silo-Probleme. Ein Beispiel ist der Bau eines Glasfasernetzwerks. Hier kommen viele verschiedene Anspruchsgruppen zusammen. Haus- und Landbesitzer müssen informiert und in Gespräche einbezogen werden. Hat das Engineering-Team, welches für den Bau des Netzwerks verantwortlich ist, nun keinen Rechtsexperten im Team, wird es mühsam. Das Team muss SAP-Formulare mit rechtlichen Anfragen ausfüllen, während es auf die Antwort eines unbekannten Mitarbeiter wartet. Viel einfacher wäre es, einen Rechtexperten ins Team zu platzieren. Mit ihr oder ihm lassen sich kurze Gespräche führen und unkompliziert Formulare austauschen.

Ein anderes negatives Beispiel sind Grosskonzerne mit standardisierten HR-Prozessen. Oft sind diese Prozesse nur für einen Teil der Belegschaft relevant. Der andere Teil muss sich mühsam zu Verantwortlichen durcharbeiten oder nach eigenen Lösungen suchen. Das kostet Zeit und Geld. Statt einen einzigen HR-Prozess für die vielschichtige Belegschaft anzubieten, lohnt es sich, die HR Themen direkt in einzelnen Teams und Abteilungen anzugehen. Jeder bekommt damit das HR, das er wirklich braucht. Kleinere, vollständigere Einheiten lösen den standardisierten Prozess ab.

Motivation

Was klein ist, ist einfach. Darin liegt der Schlüssel zum Erfolg in einer sich immer schneller verändernden Welt der Wissensarbeit mit steigender Komplexität. Kunden verlangen persönliche Angebote, Ansprache und Produkte. In einer Welt der Überfülle zählt einzig die Relevanz. Was relevant ist, erreicht den Kunden. Alles andere geht in der heutigen Informationsflut unter. Je kleinere Einheiten wir bilden, desto relevanter und kundennaher können wir arbeiten. Wir sind schneller, kommunikativer und flexibler.

Methoden

Positive Beispiele

Ein positives Beispiel für die Umsetzung von «small is beautiful» ist eine Regierungsorganisation, welche ihre Produktentwicklung auf ein neues Level brachte. Früher arbeiteten Teams in ihren jeweiligen Funktionen an verschiedenen Produkten. Team «Datenbank» arbeitete beispielsweise an Datenbanken für Produkt A, B und C. Team «Frontend» entwickelte Frontends für Produkt A, B und C. Diese Aufteilung nach Funktionen erforderte einen enormen Koordinationsaufwand. Heute arbeiten die Teams an Produkten, die in sich geschlossen sind. Ein Team arbeitet an Produkt A, ein anderes an B und ein weiteres an C. Damit ist jedes Team eine vollständige Einheit. Der Mehraufwand über verschiedene Teams hinweg konnte dadurch auf null reduziert werden.

Vorteile