Allgemein

Von der Linien- zu Matrixorganisation

Viele Unternehmen organisieren sich ganz traditionell über Bereiche, Abteilungen und Teams. Häufig hört man von „Silodenken“ und Zeitverlusten bei der Übergabe von Themen von einem Team zum anderen oder ganz generellen Problemen bei der Projektumsetzung. Kann es Sinn machen diese traditionelle Aufteilung aufzubrechen?

Viele Organisationen sind sehr traditionell organisiert. Eine Bereichsleiter:in leitet mehrere Abteilungen mit jeweils einem oder mehreren Teams. Jede Führungskraft (Team-, Abteilungs- und Bereichsleitung) hat jeweils die Verantwortung über die ihr unterstellten Organisationseinheiten. So gibt es beispielsweise einen Bereich Sales und einen Bereich IT. In letzterem die Abteilungen IT-DEV (Entwicklung) und IT-OPS (Betrieb), in denen wiederum die einzelnen Teams organisiert sind (Datenbanken, Linux Admin, Windows Admin und CloudOps in OPS und jeweils ein Entwicklungsteam pro Anwendung in der DEV Abteilung. Siehe Abb.1).

Diese oder eine ähnliche Organisation findet man sehr häufig in mittleren und größeren Unternehmen vor. Man nennt das Linienorganisation, weil sich die Verantwortlichkeiten und Vorgesetzten an einer Linie bis zur Geschäftsführung aufreihen lassen. Jeder Mitarbeiter hat genau einen direkten weisungsbefugten Vorgesetzten. Diese Organisation hat den Vorteil, dass sich Arbeiten sehr leicht anhand der Aufgabe zur richtigen Gruppe von Menschen leiten lässt, wenn man weiß welche Technologie hinter dieser Aufgabe steht. Ich habe ein Problem mit einem Windows System, dann sende ich einen Hilfeaufruf ans Team Windows ADM. Oder ich habe ein Problem mit einer Anwendung, dann erstelle ich ein Issue für das entsprechende Application Team. Das macht das initiale Routing der Aufgaben zunächst scheinbar einfach. Oft sind Probleme oder Anforderungen jedoch nicht von einem Team allein zu lösen und das initiale Team braucht Zuarbeit von einem anderen Team, welches wiederum Hilfe von wieder einem anderen Team benötigt. Für eine neue Software Funktion aus dem Team App1 wird eine neue Datenbank benötigt. Diese wird von dem Datenbank Team bereitgestellt, welches dafür jedoch einen neuen Server aus dem Linux Team braucht. An jeder dieser Übergangsstellen von einem Team zum anderen entstehen Wartezeiten, weil möglicherweise nicht sofort ein Kollege bereit steht der sich zeitnah darum kümmern kann.

Auch Probleme bzw. Incidents, die sich nicht direkt einem Team zuordnen lassen, müssen in solch einer Organisation zeitaufwendig von Team zu Team übergeben werden – das gefürchtete Ticket Ping-Pong.

Würde es da nicht Sinn machen alle für den Betrieb eines Business Prozesses oder einer Anwendung benötigten Skills in einem Team zu bündeln und sich damit die Übergaben zu sparen und vom berüchtigten Silodenken („das ist nicht meine Aufgabe“) weg zu kommen?

Genau diesen Gedanken verfolgt der Ansatz der Matrixorganisation. Mitarbeiter werden hier nicht mehr nur einem Organigramm Team zugeordnet, sondern arbeiten in Projekt- oder Produkt Teams zusammen. In solch einem Produkt Team können dann je nach Bedarf eine oder mehrere Entwickler:innen mit einem DBA und diversen Sysadmins zusammenarbeiten. Solch ein Team wird dann oft von einem / einer ProductOwner:in verantwortet. (Das hat übrigens nicht viel mit dem DevOps Konzept zu tun, bei dem es primär darum geht Entwickler:innen zu ermöglichen, komplett autark zu arbeiten ohne große Abhängigkeiten von Ops Ressourcen (dazu aber mehr an anderer Stelle).

Daraus folgt jedoch, dass jede Mitarbeiter:in nun plötzlich zwei (oder mehr) weisungsbefugte Vorgesetzte hat. Zum einen die Teamleiter:in aus der Linienführung und zum anderen den Product Owner des Produkt Teams. Oft wird dann an dieser Stelle zwischen fachlicher und disziplinarischer Führung unterschieden, um diesen Konflikt aufzulösen.

Dieses System macht es möglich, alle Probleme und Aufgaben, die das Produkt betreffen, autark und ohne äußere Abhängigkeiten teamintern zu lösen. Auch die Priorisierung von Aufgaben wird einfacher, weil der Productowner (der alleinverantwortlich für den kommerziellen Erfolg des Produktes ist) eigenständig priorisieren kann. Diese Überlagerung von Linien und Produkt Teams nennt man Matrixorganisation (siehe https://de.wikipedia.org/wiki/Matrixorganisation).

Allerdings bringt so eine Matrixorganisation häufig auch Probleme mit. Zum Einen verlieren die disziplinarisch Verantwortlichen schnell den direkten Kontakt zu den Mitarbeitern, weil sie nicht mehr täglich zusammen arbeiten. Das lässt sich nur durch enge Absprachen zwischen Linien- und Fachverantwortlichem regeln (z.B. für Personalgespräche). Zum Anderen hat man häufig nicht genug Personal, um jedes Produktteam mit allen benötigten Skills auszustatten. Das führt dann dazu, dass die entsprechenden Kollegen gleichzeitig in mehreren Produkt Teams arbeiten müssen, was einen enormen Overhead an Planungsterminen mit sich bringt (mehrfache Daylies, Sprint plannings, Reviews, Teamevents, usw.). Dazu kommt, und das ist weitaus entscheidender, eine Priorisierungsproblematik zwischen den Teams. Welche Aufgabe (welches Projekt) ist jetzt momentan wichtiger? Da es in einem solchen Fall keine übergeordnete Instanz gibt, die derlei Dinge entscheiden kann, kommt es immer auf die persönliche Einschätzung des Mitarbeiters oder den Druck an, den ein Productowner aufbaut. Keine gute Ausgangssituation.

Wenn man also nicht genug Personal hat, um jedes Produkt Team komplett auszustatten und dabei in Kauf nimmt, dass dann möglicherweise einige Kollegen nicht voll ausgelastet sind, dann wird man in diese Problematik rutschen. Häufig versucht man der nicht vollständigen Auslastung der Team Member durch Änderungen des Anforderungsprofils an die Mitarbeiter entgegen zu wirken. Man erwartet „T-Shaped People“. Das bedeutet, das eine Mitarbeiter:in in seinem/ ihrem Team ein Spezialgebiet hat, in dem er/ sie sich ganz tief auskennt (symbolisiert durch den vertikalen Strich im T) und sich in allen anderen Bereichen, die das Team betreffen, zumindest soweit an der Oberfläche auskennt, dass er oder sie den Großteil der Aufgaben im Team bearbeiten kann (symbolisiert durch den horizontalen Strich im T). Das klappt in Zeiten mit immer mehr eingesetzten Technologien und immer komplexeren Umgebungen leider nur sehr bedingt und kann zu großen Problemen führen, wenn sich jemand nicht wirklich detailliert mit einem Thema oder einem Kunden auskennt. Kleine Fehler können dann schnell zu sehr großen Problemen oder Ausfällen führen. Besser wäre es doch, wenn man es hinbekommt, jeden mit den Themen, in denen er / sie Experte ist, auszulasten. Das kommt auch der Arbeitszufriedenheit der Mitarbeiter:innen entgegen. Wenn man sich entschieden hat die Vorteile eine Matrixorganisation nutzen zu wollen und das Unternehmen in diese Richtung zu entwickeln, wie stellt man das dann an? Ein Organigramm zu schreiben geht schnell, die Mitarbeiter auf diesen Weg mitzunehmen braucht jedoch ein wenig Zeit und Fingerspitzengefühl. Man sollte versuchen den Übergang so weich und wenig invasiv zu gestalten wie möglich.

Mit Resourcecloud ist es möglich genau das zu tun. Sie organisieren ihre Mitarbeiter wie bisher auch in einer Linienorganisation und einem klaren Organigramm. Zusätzlich können Sie in Resourcecloud sehr schnell virtuelle (Projekt-) Teams gründen, in die Sie Mitarbeiter mit einem bestimmten Prozentsatz ihrer Arbeitszeit entsenden. Resourcecloud stellt sicher, dass jeder Mitarbeiter die für ihn relevanten Arbeiten sehen und bearbeiten kann. Das Routing von Arbeiten wird damit auch sehr einfach, weil sie eine Aufgabe entweder ans Fachteam oder ans Projektteam senden und sicher sein können, dass immer die relevanten Mitarbeiter die Aufgaben sehen. Auch das Ticketpingpong wird damit nahezu unmöglich, weil die initiale Routingtrefferquote so hoch ist. Auch das Silodenken und die Problematik des Verlust der Übersicht der Teamleiter stellt sich damit nicht, weil sowohl die Teamleiter wie auch die Mitarbeiter:innen und Productowner eine völlig transparente Übersicht über die anliegenden Tätigkeiten haben. Selbstverständlich anonymisiert Resourcecloud mit den Hirarchieebenen die persönlichen Auslassungen der Mitarbeiter:innen. So kann eine Abteilungsleiter:in nicht mehr die Auslastung der einzelnen Mitarbeiter:innen sehen, sehr wohl aber die Auslastung der Teams. Ein Teamleiter kann jedoch die Auslastung (nur) seiner Mitarbeiter:innen sehen. Einer Überlastung wird automatisch durch diverse anpassbare Mechanismen in Resourcecloud vorgebeugt.

Testen Sie noch heute diese und viele andere clevere Funktionen in Resourcecloud und bestellen Sie kostenlos eine Testinstanz ihrer Resourcecloud (keine Kreditkarte benötigt).