Agilitäts-Hype? Cool bleiben!
Agile ist nicht immer eine Lösung
Daniela Kudernatsch ist Inhaberin der Unternehmensberatung Kudernatsch Consulting & Solutions. Sie ist Autorin des Buchs "Hoshin Kanri - Unternehmensweite Strategieumsetzung mit Lean-Management-Tools".
Bereichsübergreifende Collaboration als Manko
Und wie sieht es mit der bereichs- und funktionsübergreifenden Zusammenarbeit aus, um übergeordnete Ziele zu erreichen? Viele Studien zeigen, dass diesbezüglich oft ein großes Manko in Unternehmen besteht. Managementsysteme wie Hoshin Kanri fordern eine solche interdisziplinäre Zusammenarbeit, in den meisten Unternehmen beschränkt sich diese aber weitgehend auf Abteilungen und Bereiche. Aus den Schnittstellen zwischen den Abteilungen wurden - anders als oft postuliert - eben doch keine Nahtstellen. Es sind harte Grenzen geblieben, die das Bereichs- und Silodenken unterstützen.
In der cross-funktionalen Zusammenarbeit ruhen daher noch jede Menge ungenutzte Potenziale, wenn es etwa um schnellere Reaktionen auf Marktanforderungen, mehr Effektivität oder auch neue Geschäftsideen geht. Daran sollten die Betriebe denken, wenn sie neue Führungskräfte berufen: Handelt es sich um Teamplayer und Networker, die sich von Abteilungsgrenzen nicht aufhalten lassen?
Wenn inkrementelles Vorgehen nicht möglich ist
Kommen wir zur inkrementellen Arbeitsweise, bei der im Prozess- beziehungsweise Projektverlauf regelmäßig Inkremente an Kunden ausgeliefert werden. Sicher wäre ein solches Vorgehen bei komplexeren Vorhaben erstrebenswert. Doch ist es wirklich in allen Branchen und Unternehmensbereichen realisierbar?
Was die Entwicklung und Produktion von Software angeht, lautet die Antwort: ja. Ein Softwareunternehmen oder der IT-Bereich eines Unternehmens kann an seine Kunden die Alpha-Version einer Software ausliefern - zumal diese als digitales Produkt leicht distribuierbar ist - und sagen: "Arbeitet schon mal damit und sammelt Erfahrungen. Die Beta-Version wird dann auch die Funktionen a, b und c enthalten." Und wenn dann im laufenden Betrieb bei den Kunden schwerwiegende Bugs auftreten? Oft ist das kein allzu großes Problem, da vor allem Großunternehmen alte und neue Software meistens für einige Zeit im Parallelbetrieb laufen lassen. So vermeiden sie, dass ein folgenschwerer Bug den gesamten Betrieb lahmlegt.
Anders verhält es sich bei der Produktion von - zum Beispiel - Tütensuppen. Ein Hersteller kann zu seinen Kunden nicht sagen: "Ich liefere euch heute schon mal den Suppenextrakt, die Verpackung bekommt ihr in ein paar Wochen." Und ein Autoproduzent? Er kann nicht schon mal den Motor liefern - zum Ausprobieren. In drei Monaten folgen dann die Kupplung und Bremse und in sechs Monaten die Karosserie. Ebenso wenig kann er sich Bugs im Betrieb leisten - zumindest wenn er teure Rückrufaktionen und Schadensersatzklagen vermeiden will. Insofern stellt sich für die Herstellung industriell gefertigter (Massen-)Produkte die Frage,
inwieweit eine inkrementelle Arbeitsweise überhaupt möglich (und nötig) ist und
was agiles Arbeiten in diesem Kontext bedeutet, beziehungsweise in welchen Verhaltensweisen es sich zeigt.
Nur weil sich eine Arbeitsweise in der Entwicklung und Produktion von Software bewährt hat, lässt sie sich noch nicht eins zu eins auf andere Unternehmensbereiche übertragen, auch nicht auf andere Branchen.
Auch iteratives Vorgehen ist nicht neu
Bleibt als letztes Prinzip das iterative, schrittweise Vorgehen, das in komplexen Vorhaben Reflexionsschleifen im Prozess vorsieht, um Erfahrungswissen und auch neue Informationen berücksichtigen zu können. Auch das ist nicht neu. Wozu dienten denn in der Vergangenheit die Meilensteine in Projekten? Wurden sie nicht erreicht, galt es zu prüfen: Sind wir noch auf dem richtigen Weg, um das übergeordnete Ziel zu erreichen, oder sollten wir Änderungen an unserer Planung vornehmen? Ein Projektmanager, beziehungsweise ein Team, das dieser Verpflichtung nicht nachkam, war entweder unfähig oder nahm seinen Job nicht wahr.
Ähnlich verhielt es sich im Vertrieb einer B2B-Organisation, wenn ein Team in monate- oder sogar jahrelanger Detailarbeit versuchte, eine große Anlage zu verkaufen. Selbstverständlich waren in diesen Prozess Reflexionsschleifen eingebaut, in denen sich die Vertriebler fragten: Welche neuen Informationen und Erkenntnisse haben wir aus unserem jüngsten Meeting mit dem Buying-Team auf der Kundenseite gewonnen? Was heißt dies für unser weiteres strategisches und taktisches Vorgehen? Ein Vertriebsleiter, der das mit seinem Team nicht tat, war schlicht unfähig - und gewiss auch nicht erfolgreich.
Mitarbeiter nicht brüskieren, sondern mitnehmen
Nur um den agilen Change voranzutreiben, sollten Manager ihren Führungskräften nicht indirekt unterstellen, ihr Mindset und ihr Führungsverhalten seien antiquiert. Das ist arrogant und kontraproduktiv. Die agilen Evangelisten haben ja Recht, wenn sie sagen: Mehr Agilität im Unternehmen ist nur mit der Unterstützung aller Mitarbeiter möglich. Also müssen sie als Mitstreiter gewonnen werden. Das aber wird kaum gelingen, wenn man ihnen sagt: "Ihr habt bisher alles falsch gemacht - Euer Denken muss sich radikal verändern".
Führungskräfte oder Projektmanager, die sich als Ermächtiger und Befähiger verstehen, werden stattdessen
die bereits vorhandenen Verhaltensweisen loben und verstärken, sofern sie zielführend sind;
die Beschäftigten motivieren und dazu inspirieren, ihre nicht zielführenden Einstellungen und Verhaltensmuster zu überdenken;
Rahmenbedingungen schaffen, unter denen die Beschäftigten neue, zielführende Verhaltensweisen zeigen können.