Changemanagement mit Wissensarbeitern

Während sich innerhalb der Informatik bzw. Software-Entwicklungsfirmen Agile Arbeitsmethoden, wie Scrum, Kanban o.ä. Derivate etabliert haben, kämpfen viele klassische Berufe, wie z.B. Ärzte, Ingenieure, Architekten usw. mit veralteten Organisationsmodellen. Je größer die Firma, desto eingestaubter sind oft die angewandten Hierarchiemodelle. Es ist Zeit damit zu brechen und einem agilen Mindest (das jeder Mensch hat) auch ein agiles unternehmerisches Handeln folgen zu lassen. 

Jeder der schon einmal innerhalb eines Krankenhauses, der Prozessindustrie, dem Automotive Sektor oder der Energiebranche gearbeitet hat, wird wissen, wovon ich in der Einleitung gesprochen habe. Hierarchien selbst sind in den verschieden Firmen über Jahrzehnte bzw. teilweise sogar Jahrhunderte gewachsen. Die Hierarchie selbst ist nichts Böses. Sie gibt einem jedem der in dieser Organisation tätig ist, Struktur. Und Struktur ist das, was auch viele Menschen in ihrer täglichen Arbeit benötigen. Ohne Struktur würden viele Menschen den Sinn der eigenen Tätigkeit hinterfragen und sich selbst nutzlos vorkommen. Wenn man jedoch ein kleines Zahnrad innerhalb des riesigen Uhrwerks darstellen kann, ist das genau das, was einen Mitarbeiter motiviert bzw. dieses kleine Zahnrad zum Optimum zu führen ist genau die Aufgabe, mit der der Mitarbeiter seinen Seelenfrieden finden kann. Was ist aber, wenn der Mitarbeiter sehr schnell feststellt, dass egal wie er das Zahnrad auch verbessert, er wird weder befördert, noch werden seine Ideen in die neuen Produkte integriert. Der Mitarbeiter resigniert und das Zahnrad wird dem Status quo gerecht, jedoch nie besser. Und genau hier setzen neue Organisationsmodelle an. 

Der CxO kann weiterhin sein „Teile-und-Herrsche“ praktizieren. Hier ändert sich auf den ersten Blick wenig. Jedoch wird das herzustellende Produkt bzw. die Dienstleistung in unterschiedliche logische Teile geschnitten; abhängig vom Produkt. Das Produkt bzw. der Kunde der das Produkt nutzt soll ja bekanntlich „König“ sein. Also müssen wir alles tun, um das Produkt auch königlich werden zu lassen. Dabei haben sich jeweils interdisziplinäre Teams etabliert, die unterschiedliche Charaktere abbilden, um ein möglichst breites Spektrum an Kreativität, Logik, Wirtschaftlichkeit, Entrepreneurship, Marketing, Vertrieb, Engineering usw. in das Produkt zu integrieren. Ein Team selbst sollte für eine logischen unabhängigen Teil des Produktes verantwortlich sein und von etwa 2 großen Pizzen satt werden ( ca. 7±2). Sobald das Team zu groß wird, werden einzelne schüchterne Kollegen nicht mehr zu Wort kommen und ein wichtiger Input geht verloren. Jetzt  werden Sie natürlich sagen, an unserem Produkt arbeiten hunderte von Menschen, wie wollen wir denn das bitte organisieren? Genau das ist die Herausforderung das Produkt in solch unabhängige Teile zu schneiden, dass verschiedene Teams möglichst autark voneinander arbeiten können. Und natürlich wird das nicht immer funktionieren. Aber auch dafür gibt es Mittel und Wege. Ein Scrum-of-Scrums gewährleistet beispielsweise eine solche Produktsynchronisierung; bedeutet jedoch auch einen erheblichen Overhead für die Product Owner. Wo kommt der jetzt her, fragen Sie sicher? Das Management bzw. das Team muss in solch einem Modell für jedes Team bzw. jedes Teilprodukt einen Product Owner stellen, der zukünftig für dieses Teilprodukt verantwortlich ist.

Dieser Product Owner ist jedoch nicht für die Menschen selbst verantwortlich. Hier genau findet die Trennung statt. Das Team sorgt für die Entwicklung des Teilproduktes. Der Product Owner ist für das herzustellende Produkt verantwortlich. Chef aller Teil-Product Owner ist wiederum der CxO (im Idealfall). Auch hier können verschiedene weitere Hierarchieebenen eingeführt werden, jedoch bedeutet jede Ebene Overhead, der zu vermeiden bzw. gering zu halten ist. Wissensarbeiter brauchen keinen direkten Vorgesetzten mehr, der den Urlaub „freiklickt“. Das können schon heutzutage Systeme besser als jeder Mensch. Was es von Zeit zu Zeit braucht ist eine unabhängige Person (alias Scrum Master), der dem Team hilft sich zu organisieren bzw. Ansprechperson für alles mögliche (unabhängig vom Produkt) zu sein. 

Wenn sich das Produkt ändert, ändern sich die Teams bzw. Teilprodukte. Reine Verwaltungseinheiten (z.B. die HR) haben auch ein Produkt. In dem Fall ist das der Mitarbeiter. Krankenhäuser haben den Patienten als Produkt. Somit müsste überlegt werden, wie kann der Patient möglichst schnell und optimal behandelt werden, so dass er (im Idealfall) das Krankenhaus weiter empfiehlt. Ingenieure sollten natürlich weiterhin an die Arbeitssicherheit denken, jedoch können dies wiederum Teilprodukte des Produktes sein (in diesem Fall natürlich „abhängig“). Schlüssel dieses agilen Arbeitens ist somit der Produktschnitt, der sich auch ganz natürlich bilden lassen kann. Fachexperten können innerhalb von verschiedenen geführten Kreativ-Workshops (Design Thinking Workshops) solche Produktmodelle entwerfen. Eine gewisse Redundanz kann helfen, die Produktmodelle auszuhärten. Es sollte grundsätzlich vermieden werden, das klassische Management mit der Umorganisation zu beauftragen. Meiner Erfahrung nach werden Manager persönliche Beziehungen bzw. Altlasten mit in das neue System umziehen, dass die Wirkung des neuen Produktmodells verpuffen lässt. Am Besten sind Entscheidungen die auf Basis des fachlichen Produktes gefällt werden. Persönliche Belange sollten hinten angestellt werden. Und genau das können große Firmen von Startups lernen. Startups müssen von Beginn an ihre Organisation am Produkt ausrichten, um im entsprechenden Markt bestehen zu können. Ansonsten sind Sie schnell wieder verschwunden. Große Firmen hingegen haben einen großen finanziellen Spielraum, der den Mitarbeitern auf den ersten Blick Sicherheit/ Beständigkeit bietet. Aber wenn der große Organismus sich nicht an den Bedarf anpasst, wird es auch nicht lange dauern, bis die Aktien fallen und der Organismus verkauft und zerschlagen wird. So ist das in der Natur, wie auch in der Wirtschaft. Man muss sich Anpassen oder man stirbt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.