Verdacht, warum Konzern-Startups scheitern

Konzernmanager lenken (vielleicht unbewusst) ihre vom Aufsichtsrat erwarteten Startup Gründungen so, dass sie ihre Kompetenzlücken später als irrelevant erleben werden - also gen Misserfolg.

Die Maschinenbauingenieure an den Spitzen der Automobilhersteller haben "Fähigkeitslücken", die die erfolgreiche Gründung und Steuerung von Konzerntöchtern für Steuergerätesoftware verhindern. Damit diese aber als irrelevant angesehen werden, hilft es, wenn diese scheitern. Die Gründe des Scheiterns werden nicht besprochen. Sondern "strategisch" verbrämt.

Man will bei einem Bedarf an Maßnahmen ankommen, den man beherrscht: Verwalten, Bestellern, verfolgen und eskalieren. Also dort, wo man hergekommen ist.

Woran eines der großen Automotive Softwareprojekte gescheitert ist

Sie kamen, sahen und verloren. Die Maschinenbaumanager, die mit Schieblehren den Erfolg von Softwareprojekten zu messen pflegen.

Pünktlich zu Halloween berichten mehrere Zeitungen von Entlassungsplänen bei einer der größten Softwaretöchtern der Autohersteller. Und am Tag danach sogar von Verhandlungen über Stellenabbau bei dessen Muttergesellschaft.

Maschinenbauer können keine Softwareprojekte und schon gar keine Softwareunternehmen managen. Sie posieren zwar gerne wie Tim Cook oder Steve Jobs oder Elon Musk. Aber sie können es nicht. Sie zwingen den agilen Einheiten ihr Mikromanagement in Form von Task Forces auf. Sie ignorieren wichtige Strukturvorgaben und Randbedingungen der Systemarchitekten. Sie wollen immer alles und sofort und gehen gerne nach einem Meilenstein wieder zurück auf Los. Wie soll da Softwarequalität entstehen?

Wenn es nach keiner Umorganisation der viel zu schnell aufgebauten Organisation Zeit gibt, sich zu finden und einzutakten bevor schon die nächste Umorganisation kommt.

Wenn in der kurzen Zeit viel zu schnell zu viele Leute eingestellt wurden, weil mehr Ressourcen ja Zeit sparen - wie jeder Maschinenbauer weiß?

Wer das schon früh erkannte und benannte erntete nur Ignoranz und Ausgrenzung mit der Frage "Glaubst Du, Du weißt es besser?" Jetzt liegt der Karren im Graben und die gleichen sagen: "Das konnte ja keiner wissen."

Das wirft ein ganz schlechtes Licht auf Deutschland. Es fehlt uns an Managementkompetenz im Bereich Software.

Wie wir IT-Fachkräfte wieder mal von den Verwaltern gebremst werden..

Jetzt war ich endlich in meiner anvisierten Rolle angekommen: Im Programm-Management für die IT-Systeme unserer Projekt- und Produktdaten. Endlich konnte ich meinen Methodikvorschlag anbringen und umsetzen. Künftig würden wir ausgehend von fachlichen Prioritäten übergreifend vorausplanen. Anforderungen aufnehmen, in den Zusammenhang stellen, Abhängigkeiten erkennen und zu einer halbwegs vernünftigen Vorausplanung unserer Facharchitektur kommen. Schnittstellen zum Beispiel sollten künftig nicht an ihren beiden Enden in unterschiedlichen Quartelen oder gar Jahren eingeplant werden.

Freudig gingen wir in die Umsetzung. "Die IT" steuerte sogar ein Architekturmanagement Tool, das wie ein Wiki organisiert ist. Systeme werden dokumentiert und mit technischen und fachlichen und Statusattributen versehen. Als wir den ersten Stand hatten, generierte uns das Tool auf Basis einer ausgewählten Vorlage, vor allem aber auf Basis der gepflegten Attribute eine Facharchitektur, die man für verschiedene Blickwinkel filtern kann. Mal stehen die Farben der Boxen für den Finanzierungsstatus, mal für den Umsetzungsstatus, mal für die Geschäftskritkalität, mal für den erreichten Stand im Lebenszyklus.

"Mein" IT-Architekt und ich wollten gerade mit der ersten Planung beginnen und den dazu gehörenden Budgetanträgen, da wurden wir von oben gebremst:

1. Der neue Vorstand für neue Geschäftsfelder (ein Maschinenbauer) gab uns eine Setzung für Tools rein, die er mit Unternehmensberatern erarbeitet hatte. Auf der letzten Folie stand: "Umsetzung erfolgt durch die Steuerungen der Fachdomänen".
2. Diese von der Seite kommenden Setzungen sind nicht budgetiert. 
3. Von der anderen Seite kam eine Targetsetzung, unser IT-Budgetdeckel. Gegenüber dem Vorjahr abermals hart reduziert.
4. Und von oben kam die Ankündigung, die Organisation der Fachdomänen abermals umorganisieren zu wollen.

Seitdem:

• Kümmern sich unsere Manager nur noch darum, in der künftigen Organisation auch ein Kästchen belegen zu können. Plötzlich sind sie alle "Business" oder "Product Owner".
• Niemand interessiert sich mehr für unsere fachliche oder Budgetplanung bottom up.
• Das einzige was wir von ihnen empfangen ist Termindruck für die Einstellung unserer Budgetanträge ins System.

Unsere Motivation fiel auf Null. Methodisch waren wir am Ziel. Als Berater hätten wir uns schon zurückziehen können. Aber wir wollen ja auch erleben, dass es fliegt.

In meiner vorherigen Rolle hatte ich all die Aufgaben, um die sich jetzt Manager kloppen, alleine inne. Und zwar als Ehrenamt nebenbei, ohne Mandat. Und ohne Interesse des oberen Management. Und trotzdem schaffte ich es mit einigen anderen Systemverantwortlichen wenigstens einige Schnittstellen besser zu planen.

Und ein übergreifendes Datenmodell einzuführen, das unserem Projektsteuerungsmodell entspricht. Und auf das wir uns über mehrere Systeme hinweg beziehen.

Um mich herum ist keiner mehr ansprechbar. Die süddeutschen Marken haben dauernd Feiertage, lange Wochenenden und Urlaub. Meine Manager sind unentwegt in Meetings. Der zugeordnete IT-Vertreter fragt mich, ob der Portfoliomanager, der zu seinem Team gehört (!), schon eine Urlaubsvertretung hat, um die Budgetzahlen rechtzeitig einzugeben. 

Ich empfinde das als dermaßen niveaulos. Für Ärger habe ich keine Muße mehr. Ich passe nur stets auf, dass ich nicht zu sehr verdumme und demotiviert werde. Wenn ich dann höre, dass von ganz, ganz oben "Effizienzprogramme" und "Entbürokratisierung" starten sollen, kann ich nicht einmal mehr lachen.. Ich weiß so viel: Ich muss das Ganze nicht ernster nehmen als meine Manager..

Was sich in 20 Jahren Softwareentwicklung verbessert hat

(Entwurf, wird fortgesetzt)

Die Älteren unter uns erinnern sich an Schlagzeilen über krachend scheiternde Großprojekte für die Einführung einer Unternehmenssoftware. Solche Schlagzeilen liest man inzwischen seltener. Woran liegt das? Hier meine Erkenntnisse auf der Basis eigener Erfahrungen:

1. Make vs. Buy

Treiber für Großprojekte sind oft die Ablösung einer sehr alten Kernprozess Software oder der Unterstützungsbedarf für neue Kernprozesse. Da gibt es 40 Jahre alte Kernsysteme, die im Unternehmen oder der Behörde selbst entwickelt wurden. Und der letzte, der den umdokumentierten Code noch kennt  und versteht, geht bald in den Ruhestand. Wenn die IT einer Leitung unterstellt ist, die von IT und Software nicht allzu viel besteht, sucht man hier vorzugsweise nach einer anpassbaren Kauflösung. Das gilt auch für den Neubedarf einer Software, wenn die Organisation neue Geschäftsprozesse einführt.

Das Problem mit Kauflösungen ist, man muss sie bei der Implementierung anpassen. Denn kein Unternehmen will seine Kernprozesse vollständig an eine Out-of-the-box Lösung eines Anbieters anpassen. Wenn der Kernprozess wettbewerbsrelevant ist würde das Unternehmen damit Wettbewerbsvorteile verspielen.

Anpassen heißt im besten Fall: Konfiguration. Was mit  der Anpassung von Eingabemasken anfing, dreht sich heute um die Gestaltung ganzer Abläufe und die Nutzbarkeit bestehender Datenstrukturen. Aber schon hier braucht man geschultes Personal, das sich mit dem zu konfigurierenden Produkt wirklich auskennt. Ich habe in meiner frühen Zeit als IT-Berater erlebt, dass IT-Unternehmen nur ungern vorab in die Ausbildung ihrer Spezialisten investierte, sondern erst tat, wenn das Projekt wirklich beauftragt war. 

=> Risiko Nr. 1: Ungeschultes Personal für das Customizing von Standardsoftware.

Reicht die Anpassbarkeit über die Konfiguration nicht aus, kommt die Frage nach der Umprogrammierung: Gibt es Mittel, den Code des Produktes selbst zu ändern um zu einer individuellen Lösung zu kommen? Auch solche Wege gibt es heute, aber man übernimmt hier sehr viel Selbstverantwortung. Man riskiert z. B. aus der automatisierten Wartung des Systems herauszufallen und Aktualisierungen künftig selbst mit eigenem Knowhow und Aufwand bewerkstelligen zu müssen.

=> Risiko Nr. 2: Unterschätzung des mittel- und langfristigen Risikos einer Codeanpassung

Wenn man sich diese Risiken klar macht, kommt die Entwicklung einer eigenen Anwendung im Haus vielleicht doch in Betracht und ist zu bewerten. Der Vorteil, wenn man es hinbekommt, ist natürlich, dass sich das Softwareprodukt an die Anforderungen der eigenen Prozesse anpasst und anpassbar bleibt.  Amazon ist ein sehr gutes Beispiel für ein digitales Unternehmen, dass seine Software von Anfang selbst entwickelt hat (bzw. entwickeln ließ). Prozesse sind dort im hohen Maße nicht nur digitalisiert sondern auch automatisiert. Und genau daraus zieht das Unternehmen große Wettbewerbsvorteile. Das Risiko besteht natürlich darin, dass sich das Unternehmen auf sich selbst verlassen muss und entsprechend qualifiziertes Personal braucht.

=> Risiko Nr. 3: Eigenentwicklung erfordert langfristige Selbstverpflichtung und Verfügbarkeit von sehr guten Spezialisten. Und ein IT-Verständnis im Top-Management.

Anmerkung: Jeff Bezos hat meines Wissens nie mit seiner Ahnungslosigkeit in Sachen IT kokettiert.

Fazit: Eine Kauflösung empfiehlt sich aus meiner Sicht um so mehr, je standardisierter und je weniger wettbewerbsrelevant der Prozess ist. Zumindest muss man in der Lage sein, solche Prozesse aus dem Gesamtgefüge herauszulösen, so dass man diese entsprechend abdecken kann. Produktentwicklung ist m. E. ein Beispiel, das sich schwer mit Standardprodukten umsetzen lässt. 

2. Methodiken

Was sich zwischen 2000 und 2010 dramatisch verbessert hat, sind m. E. die Methoden. Disziplinen wie Anforderungsmanagement, Architekturmanagement, agile Entwicklung haben Struktur in das Chaos gebracht. Es hat auch das Anforderungsprofil an die Projektmitglieder weit aufgefächert.

Lastenhefte waren früher nur für Eingeweihte lesbar. Und sie waren ein Absicherungsdokument für den Auftraggeber. Das einzige Qualitätsmerkmal das sie fast immer erfüllten, war das der Vollständigkeit. Alles was wichtig war, stand irgendwo. Aber basierte auf tausend unausgesprochenen Annahmen und nicht immer in dem Kapitel, wo man es vermutet hätte. Schon wenn der Auftragnehmer die Auswertung (die "Exegese") des Lasterhaftes auf mehrere Mitarbeiter, seine Spezialisten, verteilte, bestand das Risiko, etwas wichtiges zu übersehen. 

Ich glaube ähnlich verhielt es sich mit Pflichtenheften des Auftragnehmers. Hier versuchte sich dieser gegenüber dem Kunden abzusichern. Wir werden Ihre Anforderungen so und so umsetzen. (Wenn Sie etwas daran stört, sagen Sie es. Schweigen ist Zustimmung.)

Heute gehen wir anders, aber ganz anders an diese Disziplin heran. Heute entwickeln wir auf beiden Seiten erstmal ein Gesamtverständnis vom Produkt und seinem Zweck. Wozu willst Du etwas tun können? Um was zu erreichen? Aha, darauf willst Du hinaus. Aber da haben wir eine viel schlankere Lösung, als Du zuerst vorgeschlagen hast. Gut, dass wir vorher darüber gesprochen haben.

Der Autor des Lasterhaftes ist heute eher ein System oder Produkt Owner. Der Autor des Pflichtenheftes tendenziell ein Architekt. 

Architekturmanagement ist die zweite, heute gängige Disziplin. Die Beschreibung der Produktstruktur ist der Realitätscheck für das Projekt. Welche Anforderungen werden mit welchen Produktkomponenten umgesetzt? Kaufen wir diese oder entwickeln wir sie selbst? In welcher Reihenfolge (Releases) kann das Produkt entstehen? Wie kann eine erste Version aussehen und welche Benutzergruppe wird sie bedienen?

Owner und Architekt müssen hierfür in einem ständigen Dialog sein und am besten teilen sie sich das selbe Büro (wenn wir mal wieder im Büro sind). Und dieses Büro braucht Wände, auf denen man zeichnen kann. Unsere Sprache besteht aus Worten und Diagrammen. Ich habe mit genau dieser Konstellation allerbeste Erfahrungen gemacht: "Kollege, wenn wir jetzt noch dies und das können wollen, was brauchen wir dazu?". Schon während der Kollege antwortete griffen wir beide nach einem Stift und schritten zur Wand. Und erweiterten unsere Produktskizze. Das war das erste Mal in meinem Leben, wo ich dachte: Genau so muss der Job eines Ingenieurs ablaufen. Ein kreativer Prozess aus sich ergänzenden Spezialisten mit dem Gesamtverständnis für das Spiel.

Und wenn wir uns dann über das Was, Wozu und Wie einig sind, dann können wir unsere Epics und Stories in die Implementierung geben. 

Und auch hier gibt es dramatische Verbesserungen zu früher: die iterative Entwicklung mit regelmäßigen Anforderungsklärungen, Reviews und Tests. Nicht den einen großen Knall am Ende des Projektes. Scrum, Scaled Agile sind Methoden, die für meine Begriffe genau so viel Wert geschaffen haben wie manches Unternehmen.

Dieser regelmäßige Austausch zwischen Fachbereichssicht und Entwicklerteam sichert das Projekt ständig ab. Man kann dann bei der Bergbesteigung dann eigentlich nicht tiefer zurückfallen, als der Ankerpflock des letzten Releases.

Dieser regelmäßige Umgang miteinander bewirkt auch ein wachsendes Vertrauen. Und wachsendes Vertrauen öffnet die Kommunikation und reichert das Wissen über Was und Wie auf beiden Seiten an. So entsteht ein Gesamtteam, das sich mit dem Produkt und mit sich als Team identifiziert. 

Es erfordert auf beiden Seiten aber auch die Bereitschaft, der anderen Seite zuzuhören und zu lernen. Entwickler empfinden den hohen Kommunikations- bzw. Meetinganteil manchmal als störend und hemmend. Aber nach einiger Zeit empfinden es meistens alle als nützlich.

Und umgekehrt: Ich kenne Prozessmenschen die sich ganz bewusst (um nicht zu sagen "selbstbewusst") von der IT abgrenzen und ein Verständnis von Delegation gegenüber der IT haben. Nein, auch der Fachbereich, der von einem Prozess und somit einem System abhängt, muss hier ein Verständnis über Möglichkeiten und Restriktionen und Zusammenhänge aufbauen. Jedenfalls im Groben.

3. Projektpersonal

Das ist der Grund, warum Softwareprojekte heute nicht nur Logiker brauchen. Sondern auch sprachlich begabte Leute. Begriffsbildung, Kontextvermittlung, die Unterscheidung zwischen Zweck und Mitteln - also eine bewusste Verwendung von Sprache und Bildern ist sehr wichtig. Hierzu gehört auch die Fähigkeit des Zuhörens. Und ich kann versichern: Hierzu hilft es auf Dauer ungemein, nicht nur Fachliteratur zu lesen, sondern auch andere Literaturgattungen. Das gleiche gilt für das gehörte Wort. Ich bin mit einer Germanistin verheiratet und ich habe unzählige Diskussionen über die Verwendung von Sprache und Begriffen ("Kommunikation?!") hinter mir ;-).

Neben der Sprache braucht es Verantwortungsbereitschaft und den Willen zum Mitdenken. Mein Verständnis der Owner - Rolle ist aus dem Produktmanagement abgeleitet. Ein 360° Blick auf das Produkt. Von allem muss ein Owner so viel verstehen, dass der die Implementierungsoptionen mitentscheiden und tragen kann. Das Team muss ihm Optionen mit Vor- und Nachteilen, auch technischen, anbieten. Ein Owner muss dann entscheiden können. Die Entscheidungen werden nie perfekt sein, das sind sie auf einem Markt nie. Die eigene Vorgehensweise muss auch immer Raum für Korrekturen lassen, bei denen man vielleicht mal Zeit verliert, aber nie das ganze Produkt.

Wie Open Source die Kooperation für das digitale Auto fördert

Ende der 90er Jahre wurden in Europa die Energie- und Telekommunikationsmärkte liberalisiert - d. h. Wettbewerb zugelassen.

Große Unternehmen reagierten damals mit Übernahmen und Kooperationen. Wettbewerb wurde weggekauft oder man verdiente an seinen Umsätzen mit.

Jetzt gibt es wieder eine Welle von Kooperationen (und wer weiß: vielleicht kommen Fusionen noch..): In der Automobilindustrie.

Weil sich die Wertschöpfung in Richtung Software bzw. softwaregeführter Systeme und Komponenten verschiebt, müssen die Entwicklungsbereiche der Hersteller und Zulieferer schnell viel neues lernen. Vor allem auch neue Entwicklungsmethoden: z. B. agile Entwicklung und die Nutzung von Open Source Frameworks.

Aber hier geht es nicht um Unterbindung von Wettbewerb, denn den gab es schon vorher. Sondern um eine sinnvolle Arbeitsteilung in Richtung mehr Effizienz.

Es gibt derzeit nämlich kaum mittelfristige Produktplanung über ein Fahrzeugprojekt hinaus. Nach einem Produktionsstart startet die Softwareentwicklung von Neuem. Oft auch mit einem neuen Team, wer halt gerade noch verfügbar ist und noch nicht von anderen Projekten angeheuert wurde.

Niemand legt Wert auf eine "aufgeräumte" Architektur, die eine Wiederverwendung von Bestehendem sehr vereinfachen würde. Niemand will den Taskforcemodus noch einmal erleben, in dem Entwicklungsleiter auf Kunden- (OEM-) Seite mit dem Hammer auf das Blechdach des Projekthauses hauen, bis die Software ins Fahrzeug passt.

Stattdessen macht es Sinn, in jedes Produkt von einer evolutionären Plattform aus abzuspringen. (Schon mal gehört? Vielleicht auch schon Ende der 90er..?).  Aber erst heute wird das so richtig möglich.

Wer die Software in die eigenen Reihen holen will, muss Hardware- und Softwareentwicklung trennen. Und kann die Softwareentwicklung dann auch noch einmal trennen, in einen unteren Stack, in dem die Dinge getestet, dokumentiert, architekturkonform und standardkonform liegen, die man in jedem Produktprojekt braucht Und die aber nicht wettbewerbsrelevant ist. Und in einen oberen Stack, in dem dann jeder Hersteller seine marken- und modellspezifischen Komponenten ausprägen kann - und nicht offen legen muss.

In Softwarefactories (ja, auch den Begriff "Factory" - von Andy Warhol ersonnen- gibt es wieder) "committen" Entwickler jeden Abend ihren Stand. Die Factory bindet alle Stände zusammen, analysiert den Code auf Architekturkonformität, kompiliert und testet. Am nächsten Morgen finden die Entwickler ihre Testberichte. Dies macht man innerhalb eines Projektes so. Man kann den offenen Quellcode -den nicht wettbewerbsrelevanten- aber auch gleich öffentlich gemeinsam produzieren. Dazu braucht man natürlich erstmal Genehmigungen von den Herstellern. Aber die Monate, die man darauf wartet, lohnen sich.

Aber eine weitere Bedingung muss dafür erfüllt sein: Die angestammten Zulieferer müssen da mitspielen - und richtige Anreize bekommen. Ich erlebe es derzeit als Kampf um die Bewahrung des Bestehenden. Die neuen Chancen werden nicht erkannt und am Fallenden wird krampfhaft festgehalten. Evtl. in der Annahme, dass dies nur eine vorübergehende Erscheinung sei. Alle Fahrzeughersteller haben gerade ihre Digital Labs und "experimentieren" ein bisschen herum, Bald werden sie merken, wie schwierig das Geschäft wirklich ist und werden bald zurückkehren - denken die Manager der Zulieferer.