Letztes Jahr habe ich mit zwei Unternehmen zusammengearbeitet, um deren digitale Kompetenzen zu verbessern. Beide gehören zu den Branchenführern und blicken auf über ein Jahrhundert erfolgreiche Geschichte im Maschinenbau und in der Fertigung zurück. Wie bei vielen unserer Kunden werden digitale Elemente für ihre Lösungen und ihr Geschäft immer wichtiger.
Sie unternehmen daher Maßnahmen, die sie für notwendig halten, um erfolgreiche Technologieunternehmen nachzuahmen: Sie bauen ihre Softwareentwicklungskapazitäten aus und setzen agile Methoden ein (und skalieren diese). Sie stellen Agile Coaches ein und entwickeln Produktmanagementfunktionen für ihre digitalen Lösungen.
Dennoch gelingt es ihnen kaum, auch nur annähernd an die digitalen Kompetenzen und den Erfolg der Branchenriesen der Westküste heranzukommen. Und unsere Kunden sind damit nicht allein; viele andere Unternehmen aus dem Industriezeitalter weltweit befinden sich in derselben Situation.
Was unterscheidet Amazon, Apple, Google usw. in ihren Kompetenzen?
Wenn ich auf meine über zwanzigjährige Erfahrung als Führungskraft in Technologieunternehmen (Apple, …) und meine mehr als zehnjährige Tätigkeit als Berater, vorwiegend für Industrieunternehmen, zurückblicke, bin ich der Meinung, dass der entscheidende Unterschied folgender ist:
Es sind die mentalen Modelle.
Mentale Modelle sind Repräsentationen der Welt, die uns helfen, sie zu verstehen und ihr einen Sinn zu geben. Sie prägen unsere Wahrnehmung und unsere Interaktion mit der Welt. Sie basieren auf unseren Erfahrungen, unserem Wissen und unseren Überzeugungen. (Das Konzept der mentalen Modelle wurde in den 1980er-Jahren in der Kognitionswissenschaft entwickelt.)
Die größte Herausforderung für Industrieunternehmen ist ein zugrunde liegendes mentales Modell, das die Software- und Digitaltechnologieentwicklung im Allgemeinen mit der industriellen Produktion gleichsetzt.
Industrieunternehmen: Mentales Modell „Softwareproduktion“
Die meisten Industrieunternehmen behandeln die Softwareentwicklung immer noch als industriellen Prozess mit spezifizierten, geplanten und verwalteten Komponenten – oft in „Projekten“.
Dieser Ansatz betrachtet Softwareentwickler (und ihre Zeit) als Produktionskostenfaktor. Daher werden sie wie Fabrikarbeiter oder Roboter in der Produktion eingeplant.
Outsourcing und sogar Offshoring sind in den IT- und F&E-Abteilungen von Industrieunternehmen gängige Praxis (verstärkt durch den allgemeinen Mangel an Programmierern und Informatikern auf dem deutschen Arbeitsmarkt).
Das mentale Modell der „Softwareproduktion“ prägt maßgeblich die Struktur von Organisationen und Produkten. Teams werden oft auf Basis technischer Expertise und nicht anhand der zu lösenden Probleme gebildet. Diese Strategie zielt darauf ab, die Kapazitätsauslastung zu optimieren, indem Spezialisten konzentriert und auf die Entwicklung verschiedener Komponenten verschiedener Produkte verteilt werden.
Die industrielle Denkweise umfasst häufig auch einen spezifikationsorientierten „Befehls- und Kontroll“-Managementansatz. Das Management legt Produktprioritäten, Implementierungsstrategien, Pläne und sogar Spezifikationen mit geringer Beteiligung der Entwicklungsabteilung fest, wodurch die Entwicklungsteams zu reinen Befehlsempfängern degradiert werden.
Obligatorische Prozessmodelle wie das Scaled Agile Framework (SAFe) unterstützen diesen Ansatz. Eine Umfrage des Blogs „The Pragmatic Engineer“ zeigte vor einiger Zeit, dass Industrieunternehmen häufiger Entwicklungsmethoden vorschreiben als große Technologiekonzerne.
Dieser Ansatz hat Konsequenzen: Die Abstimmung von Ressourcen über mehrere Teams hinweg erfordert komplexe und in der Regel längere Planungszyklen. Ingenieure mit begrenzten Markt-, Problem- und Produktkenntnissen entwickeln möglicherweise Lösungen, die die Kunden nicht zufriedenstellen und somit Nacharbeiten erforderlich machen. Der Ansatz mit matrixorganisierten Spezialistenteams erfordert häufige Kontextwechsel für die Entwickler, was nachweislich die Implementierungsgeschwindigkeit verringert und die Fehlerrate erhöht. Matrixressourcen verstärken zudem die technischen Abhängigkeiten zwischen Komponenten und erhöhen die Entwicklungszeit und das Projektrisiko.
Technologieunternehmen: Das mentale Modell „Software erschließt Wert“
Typische Technologieunternehmen betrachten die Softwareentwicklung aus der Perspektive der Lösung von Geschäftsproblemen. In ihrem mentalen Modell wird Software entwickelt, um ein Geschäftsproblem zu lösen oder eine Aufgabe zu erledigen, um Mehrwert zu schaffen.
In diesen Umgebungen wird typischerweise ein Team (oder eine Gruppe von Teams) mit der Lösung eines Problems oder der Verfolgung einer bestimmten Chance beauftragt. Ingenieure und Entwickler werden ermutigt, innerhalb der vereinbarten Rahmenbedingungen, die mit dem Produktmanagement kontinuierlich verhandelt werden, eigene Lösungen zu entwickeln.
Um dies effektiv zu tun, haben sie in der Regel direkten Zugriff auf Daten und Kennzahlen. Produktmanager und andere Mitarbeiter des Unternehmens interagieren direkt mit den Entwicklungsteams und umgekehrt. Auch Ingenieure verschiedener Gruppen kommunizieren bei Bedarf direkt miteinander. Eine Kommunikation über die Managementebene gilt als unüblich.
In Technologieunternehmen werden Entwicklungsteams als wertvolle Ressource betrachtet und oft fast wie Profitcenter behandelt.
Sie erhalten zudem die notwendige Unterstützung, um sich auf ihre Aufgaben im Hinblick auf Tools und Infrastruktur konzentrieren zu können. In der Digitalbranche ist es üblich, dass Unternehmen eine Technologie- und Tool-Architektur aufbauen, die die Produktentwicklung optimal unterstützt. Technologieunternehmen investieren sogar in dedizierte Ressourcen für Infrastruktur, APIs und DevOps-Tools.
Verstärkt wird dies oft durch erfahrene CTOs, die die Architektur dieser digitalen Infrastrukturen aktiv gestalten. Beispiele hierfür sind Werner Vogels bei Amazon, Mark Russinovich bei Microsoft Azure oder David Heinemeyer-Hansson bei Basecamp.
Im Gegensatz zu Industrieunternehmen schreiben große Technologieunternehmen in der Regel keine bestimmte Entwicklungsmethode vor. Von den Teams wird erwartet, dass sie ihren eigenen Weg wählen oder entwickeln, der zum Problem, zum Kontext und zu ihren Erfahrungen passt.
Dadurch haben die Ingenieure von Technologieunternehmen typischerweise weniger Aufwand und wirken somit weniger überlastet und können sich besser auf ihre Aufgaben konzentrieren. Tatsächlich versuchen einige Unternehmen aktiv, einen gewissen Spielraum zu schaffen, den „Headroom“, wie er beispielsweise bei eBay genannt wird. Googles viel zitierte 20%-Regel, die Ingenieuren effektiv einen Tag pro Woche für die Entwicklung eigener Ideen einräumte, war möglicherweise übertrieben. Dennoch unterstreicht sie das Konzept, Ingenieuren Freiraum für die Problemerkennung und -lösung zu lassen.
Meine persönliche Erfahrung verdeutlicht diesen Unterschied: Als ich für ein deutsches Technikunternehmen arbeitete, das sich damals in einer schwierigen Lage befand, sprach ich mit dem Leiter der Forschungs- und Entwicklungsabteilung, um herauszufinden, ob er von geheimen Projekten oder unfertigen Ideen wusste, die uns weiterhelfen könnten. Seine Antwort war eindeutig: Es gab keine, da die Ingenieure keine Kapazitäten dafür hatten. Ich war schockiert. Ein Bier oder ein Abendessen mit einem Entwicklungsleiter in einem der Technologieunternehmen, für die ich gearbeitet hatte, brachte stets Ideen für Produktverbesserungen oder sogar für unausgereifte neue Produkte ans Licht.
Dies führt zu einem messbaren Unterschied: Studien von MIT/Sloan und Glassdoor zeigen, dass typische Technologieunternehmen eine deutlich höhere „Business Agilität“ aufweisen (definiert als die Fähigkeit, „…schnell und effektiv auf Marktveränderungen zu reagieren und neue Chancen zu nutzen“), was mit einem signifikanten Unterschied in ihren Innovationswerten korreliert, wenn nicht sogar diesen verursacht.
Projektmanagement vs. Produktmanagement
Diese Unterschiede in Denkweise und Herangehensweise werden besonders deutlich, wenn es um die Projektorganisation geht. Industrieunternehmen betrachten Softwareprojekte eher als solche, während Technologieunternehmen typischerweise Produkte managen. Projekte haben per Definition einen Anfang und ein Ende. Produkte hingegen werden so lange weitergeführt, bis sie keinen oder nur noch geringen Nutzen bringen und eingestellt werden.
(Um es gleich vorwegzunehmen: Auch im Technologiebereich gibt es viel „Engineering-Projektmanagement“, das zwar ähnlich klingt, aber meiner Ansicht nach eine andere Rolle spielt.)
Auch hier zeigt sich der industrielle Ansatz. Ein Projekt wird eingerichtet, um etwas zu entwickeln oder zu erstellen. Spezifikationen und Anforderungen werden zu Beginn erfasst und festgelegt, Ressourcen, Zeitaufwand und Kosten werden geschätzt. Anschließend wird das Projekt geplant und umgesetzt. Am Projektende wird das Ergebnis – oft unabhängig vom Erfolg – eingeführt und geht in einen Wartungsmodus über, in dem nur noch begrenzte Verbesserungen oder Modifikationen erwartet werden, häufig in der Verantwortung eines völlig anderen Teams.
Dies ähnelt der Herstellung eines industriellen Druckgussteils. Abmessungen und Spezifikationen werden erfasst. Die Gussform wird hergestellt, anhand der Spezifikationen geprüft, bei Bedarf nachjustiert und fertiggestellt. Die Form geht in die Produktion, und es werden Teile gegossen, bis das Produkt ausläuft.
Dieses industrielle Modell spiegelt sich auch im typischen industriellen Budgetierungsansatz wider: Es gibt ein Projektbudget für die Implementierung. Die Instandhaltung des Projektergebnisses wird anschließend durch ein Wartungs- oder Betriebsbudget abgedeckt.
Technologieunternehmen entwickeln primär Produkte, die Kunden- oder Geschäftsprobleme lösen, indem sie digitale Technologien nutzen, um Wertschöpfung zu schaffen. Wenn das Produktmanagement ein Kunden- oder Geschäftsproblem als attraktive Chance identifiziert, wird ein Produkt entwickelt und auf den Markt gebracht, sofern der Geschäftsnutzen den erwarteten Ressourcenbedarf und das Technologierisiko übersteigt.
In einem wettbewerbsintensiven Markt, in dem sich die Technologie ständig weiterentwickelt, wird das Produkt kontinuierlich optimiert, um den Kunden- und Geschäftswert zu maximieren. Dieser Optimierungsprozess ist eine Zusammenarbeit zwischen dem Produktmanager, der die Geschäftsziele und -beschränkungen entwickelt und verwaltet, und dem Entwicklungsteam, das für die technische Umsetzung verantwortlich ist (und oft einem Designer, der die Benutzererfahrung optimiert).
Produktbudgets sind daher kontinuierlich. Je nach strategischer Bedeutung und Geschäftswert werden sie im Laufe der Planung angepasst. Die ständige Transparenz ermöglicht das Verständnis und die Steuerung der Rentabilität (Kosten pro generiertem Wert) und fördert die gezielte Entwicklungsarbeit.
Fazit: Die obige Beschreibung erläutert grob die Unterschiede zwischen den mentalen Modellen von Technologie- und Industrieunternehmen und ihre Auswirkungen auf die Softwareentwicklung. Die Realität in Unternehmen ist natürlich komplexer.
In meiner Arbeit mit Industriekunden im Maschinenbau habe ich, begonnen, die Herausforderungen der Integration von Software und digitalen Technologien in groß angelegte Maschinenbauprojekte besser zu verstehen. Die Entwicklung effektiver Arbeitsmodelle zur Bewältigung dieser Herausforderungen ist entscheidend.
Die Leistungsfähigkeit und der Einfluss digitaler, insbesondere von Softwaretechnologien, erfordern jedoch einen Wandel in unseren Denkweisen. Maschinenbau und Produktion werden rasant digitalisiert. Neue Wettbewerber nähern sich traditionellen Industrieprodukten mit digitalen Denkweisen.
Es ist entscheidend, dass wir unsere Denkweisen erkennen und anpassen, um die Chancen und die Möglichkeiten der Digitalisierung effektiv zu nutzen.