„Software is eating the world“ postulierte der US-amerikanische Venture Capitalist Marc Andreesen im Jahr 2012. Der Buchhandel wurde disruptiert von einem Online-Shop. Telefonie wird jetzt durch Software erledigt und findet auf Uhren, iPads und Computern statt. Die klassische Medienindustrie mit ihrem Werbegeschäft wurde zu Instagram und Google. Tesla zeigt, dass der Erfolg in der Autoindustrie von Software abhängt.
Software frisst Branche um Branche. Was also können Organisationen, die von deutschem Ingenieursgeist geprägt sind von den amerikanischen Software-Giganten lernen?
Diese Frage und viele mehr haben wir diskutiert mit Jan Ahrend, Buchautor und seit 25 Jahren unterwegs in großen deutschen Unternehmen als freier Berater.
Gregor: Mir scheint es, als seien es immer amerikanische Firmen, die besser in Softwareentwicklung sind, als ihre europäische Konkurrenz. Siehst du das auch so?
Jan: Wenn man sich die absoluten Zahlen anguckt, dann stimmt das. Die Unternehmen mit einem großen Börsenwert kommen aus den USA. Und dabei geht es am Ende nicht nur um ihre Fähigkeit zur Softwareentwicklung, sondern es geht auch um die Verbindung zwischen vorhandenem Kapital und Softwareentwicklung.
Die amerikanischen Börsen sind stets bereit ins Risiko zu gehen – auch in den frühen Phasen. Da wird auch in Themen investiert, die Potential haben, aber eben noch nicht sehr erprobt sind. Und diese Verbindung aus Möglichkeit und Fähigkeit hat die Amerikaner in den vergangenen Jahrzehnten dahin gebracht, wo sie heute stehen. Hinzu kommt ein weitläufiges Netzwerk aus Zulieferern, das sich die amerikanischen Firmen aufgebaut haben. Und das lässt sich so nicht ohne Weiteres kopieren.
Gregor: Das Umfeld in den USA stimmt also. Aber wie sieht es mit der Innenperspektive aus? Was machen die amerikanischen Unternehmen besser?
Jan: Auf der einen Seite haben diese Unternehmen eine Vision. Sie wollen etwas erreichen, sie wollen einen Mehrwert für ihre Kunden schaffen. Und sie schaffen es diese Vision mit den operativen Prozessen zu verbinden.
In Deutschland gilt ja immer noch: Wer eine Vision hat, sollte mal besser zum Arzt gehen. Hierzulande lässt man dann im Zweifelsfall eine Möglichkeit lieber verstreichen und kopiert das, was die anderen bereits machen.
Innovation findet am Kunden statt und Innovation hat immer was mit dem eigenen Produkt zu tun. Was eine erfolgreiche Innovation ist, kann nur der Kunde bestimmen. Und Kundenwünsche sind durchaus komplex. Das beinhaltet auch, dass Unternehmen experimentieren. Denn nur so kann das Unternehmen am Ende herausfinden, was der beste Weg ist.
Gregor: Da gibt es ja die berühmte Unterscheidung zwischen den beiden Begriffen “komplex” und “kompliziert”. Kannst Du das den Lesern bitte mal erläutern?
Jan: Kompliziert bedeutet, dass Prozess und Produkte für den Laien schwierig aussehen. Allerdings gibt es in komplizierten Fällen bereits vorhandene Prozesse, Algorithmen und Experten. Das kann dann im Zweifelsfall auch automatisiert werden.
Komplexe Situationen sind schwieriger zu handhaben. Denn hier spielen unglaublich viele Faktoren ineinander. Ein Beispiel für eine komplexe Aufgabe ist es beispielsweise, ein Flugzeug mit neuen Formen zu entwickeln, die es bisher noch nicht gegeben hat. Denn hier stellt sich die generelle Frage: In welche Richtung soll ich weitgehen? Da müssen dann zunächst einmal strukturiert Experimente durchgeführt werden. Wenn das Experiment erfolgreich ist, dann kann ich in die gleiche Richtung weitergehen. Wenn das Experiment nicht erfolgreich ist, muss ich mein Modell hinterfragen und entsprechend andere Hypothesen entwickeln.
Und manchmal mache ich mehrere Experimente gleichzeitig. Manchmal mache ich Experimente, um den positiven Weg zu identifizieren. Manchmal mache ich Experimente, um die negativen Wege auszuschließen. Und dieses Vorgehen widerspricht der deutschen Effizienz-Idee. Und es widerspricht dem deutschen Wunsch nach Planbarkeit und Professionalität
Gregor: Das bedeutet, dass amerikanische Unternehmen besonders gut darin sind sich an eine komplexe Welt anzupassen?
Jan: Am Anfang steht bei den amerikanischen Unternehmen die Vision. Denn ohne Ziel navigiert es sich schlecht. Und nur das Gleiche, wie die anderen zu machen reicht eben nicht aus als Ziel.
Ausgehend von dieser Vision braucht es dann Rückkopplungsschleifen. Das heißt, es gilt sehr flexible Prozesse aufzubauen, bei denen das Unternehmen jederzeit in der Lage ist Änderungen vorzunehmen.
Navigation ist in diesem Fall Navigation in vielen kleinen Schritten. Und das heißt, die operativen Ergebnisse von Experimenten werden zurückgespiegelt und bewertet – anhand der Passgenauigkeit auf die durch die Vision vorgegebene Richtung. Und da braucht es eben einen sehr kontinuierlichen Fluss an neuen Ideen, die immer wieder live gestellt werden. Aber nicht einfach nur, um sie live zu stellen, sondern immer auch um zu überprüfen: War das jetzt der richtige Schritt?
Gregor: Ein konkretes Beispiel: Als Microsoft ChatGPT in den eigenen Browser Bing integrierte, wurden innerhalb von Stunden Fälle bekannt, in denen es Nutzern gelungen ist den Bot zu provozieren. Das Problem wurde aber von Microsoft schnell erkannt und abgestellt.
Jan: Ja, das ist nur ein Beispiel für die vielen kleinen Schritte, die auf dem Weg einer Software-Entwicklung zu gehen sind. Es ist Microsoft in kurzer Zeit gelungen, die aktuelle Probleme abzustellen. Die anderen Probleme, die da draußen lauern, sind aber möglicherweise noch nicht erkannt.
Das Entscheidende ist also, dass Probleme, die beim Nutzer auftauchen, nicht ignoriert werden dürfen, sondern dass permanent nach neuen Lösungen geforscht wird.
Es geht bei Software-Entwicklung nicht darum, auf einmal den ganz großen Wurf zu schaffen. Es geht aber auch nicht, all die kleinen Probleme zu ignorieren. Und genau zwischen den Extremen pendelt man in Deutschland sehr stark.
Da können die deutschen Unternehmen noch sehr viel von den amerikanischen Unternehmen lernen: Nämlich jene Probleme anzugehen, die direkt vor den eigenen Füßen liegen.
Gregor: Dabei können wir doch in Deutschland sehr gut “Hardware” herstellen. Wo ist da der Unterschied zur “Software”?
Jan: Der Unterschied zwischen Hard- und Software lässt sich gut mit dem Begriffspaar “kompliziert” und “komplex” verdeutlichen.
Viele der Modelle der Hardwareanpassung sind zunächst einmal nur “kompliziert”. Das heißt, nachdem das Modell entwickelt ist lassen sich nach genauen Vorgaben Parameter identifizieren, die es zu verbessern gilt. Beispielsweise das Getriebe eines Autos.
Software-Entwicklung basiert aber auf einem ganz anderen Paradigma: Dem Agieren in einer komplexen Umwelt.
Gregor: Das bedeutet, dass deutsche Unternehmen das Agieren in komplexen Umweltzuständen erst erlernen müssen?
Jan: Ja, sowohl die Software-Welt, als auch die Hardwarewelt haben eigene Denk- und Handlungsmuster. Und die beiden Welten sind nicht kompatibel. Es bringt also nichts mit den Erfolgskonzepten der “Hardware-Welt” an Software rumzutüfteln.
Das führt am Ende dazu, dass die deutschen Unternehmen auf den einen Experten warten, der ihnen alle Fragen beantworten kann.
Gregor: Aber woher stammt die Komplexität der Software-Welt? Von außen betrachtet könnte man sagen: Das sind doch auch nur X-Zeilen Code, die es zu optimieren gilt?
Jan: Die Komplexität in der Software-Welt ist deutlich höher. Denn es ist schwerer als in der Hardware-Welt vorauszusagen, wie sich Software verhält. Das zeigt sich schon daran, wie Software getestet wird. Es ist völlig unmöglich in einer Software alle möglichen Parameter durchzutesten, die auftreten können. Das heißt, wir können nur einen bestimmten Prozentsatz davon testen.
Das liegt daran, dass Software aus zahlreichen Layern aufgebaut ist, die sich gegenseitig beeinflussen können, die sich in irgendeiner Weise aufschaukeln können. Dadurch entstehen Effekte – auch im Zusammenspiel mit dem Internet – die eben nicht vorhersehbar sind. Und dadurch entsteht letztlich Komplexität: Viele, viele Systemelemente, die leicht miteinander gekoppelt sind. Nehmen wir als Beispiel eine große Software wie ein Betriebssystem. Oder ein Chatbot wie ChatGPT, der dann auch noch selbst lernt. Da entstehen extrem komplexe Verhaltensweisen rein über die Skalierung und über die Größe. Und da funktioniert eben das deutsche “Ärmel hochkrempeln” und die Dinge angehen nicht mehr. Vielmehr muss permanent neu analysiert und angepasst werden. In vielen kleinen Schritten.
Gregor: Was ist also das Erfolgsgeheimnis der Software-Entwicklung?
Jan: Bei der Software-Entwicklung geht es nicht um eine vollständige Kontrolle aller denkbaren Szenarien. Vielmehr geht es um den Aufbau von Prozessen. Konkret bedarf es in Software-Unternehmen des Aufbaus einer funktionierenden Feedback-Schleife. Als Unternehmen weiß ich nicht, ob das Experiment erfolgreich ist. Genau deshalb führe ich es durch. Wenn das Experiment erfolgreich ist, mache ich genau in der Richtung weiter. Und wenn es nicht erfolgreich ist, dann designe ich ein neues Experiment. Das heißt, ich habe einen ständigen Fluss an Erneuerungen, den ich immer wieder überprüfe.
Das bedeutet wir benötigen weniger Experten und mehr Feedback-Schleifen, die uns sagen, in welche Richtung es weiter geht.
Und das bedeutet dann auch, dass man mit dem Scheitern leben und umgehen muss. Das Unternehmen führt Experimente durch. Und es gestattet, dass 10 Experimente parallel durchgeführt werden dürfen. Und es ist dann auch nicht schlimm, wenn alle 10 scheitern.
Gregor: Wie kann ein solcher Prozess aussehen?
Jan: Es geht darum einen konstanten Fluss von Neuentwicklungen zu ermöglichen. Es benötigt daher spezifische Veränderungen im Produkt, die auch wirklich eine Rückmeldung geben. Und dann muss gewährleistet sein, dass die Dinge auch geändert werden, wenn neue Erkenntnisse da sind.
Es geht also auch darum, als Unternehmen loszulassen. Nicht zu erwarten, dass ein Mitarbeiter selbstständig die perfekte theoretische Antwort findet, sondern es dem System zu überlassen, die perfekte Antwort zu geben, indem es auf die richtige Weise reagiert.
Die schnellen Lernzyklen sind im Endeffekt der Unterschied. Je schneller ich lerne, desto eher bin ich am Ziel. Das heißt, es ist nicht zwingend notwendig, die richtigen Experimente durchzuführen. Möglicherweise helfen mir auch die falschen Experimente auf den richtigen Weg zu gehen. Dann brauche ich eben drei Feedbackschleifen mehr.
Gregor: Kann das nicht auch schiefgehen?
Jan: Klar, nehmen wir das Beispiel Tesla. Da geht es nicht nur um Experimente. Da geht es auch darum, die Sicherheit der Fahrer:innen zu gewährleisten. Das heißt, wenn ich etwas live stelle und und alle Teslas dieser Welt bleiben stehen, dann war das keine gute Idee.
Das heißt, ich muss im Zweifelsfall eine Umgebung haben, in der ich kontrollierte Experimente durchführen kann. Möglicherweise gibt es einen Mitarbeiter auf einer Teststrecke. Und nur er bekommt dieses Feature eingespielt. So bin ich in der Lage, die die Sichtbarkeit und die Nutzbarkeit einzelner Funktionen zu steuern.
Und erst wenn mehrere dieser Schleifen durchlaufen sind, darf ein neues Feature dann auch beim Endkunden aufgespielt werden.
Bei anderen Produkten ist das dann vielleicht unproblematischer. Tritt ein Fehler bei Chat GPT auf, ist das nicht so dramatisch. Da kann einfach ein neues Update drüber gespielt werden. Und das ist dann nur noch komplizierte Ingenieurs-Feinarbeit. Das heißt, am Ende geht es um das Zusammenspiel zwischen kreativem Experimentieren und der Fähigkeit neuerlangtes Wissen mit Hilfe von Ingenieursprozessen anzupassen.
Gregor: Also ist das Geheimnis das perfekte Zusammenspiel zwischen Kreativität und Ingenieurswissen?
Jan: Softwareentwicklung hat am Anfang eher etwas damit zu tun, einen Film zu machen oder ein Musikstück zu komponieren. Das ist eben ein wirklich kreativer Prozess. Das heißt, am Anfang ist diese Kreativität extrem wichtig.
Ingenieurswissen wird später extrem wertvoll, wenn ich anfange zu industrialisieren und planbar zu machen. Dafür brauche ich dann weniger Kreativität. Da geht es eher darum, die Produktionsprozesse zu beherrschen.
Und am Ende müssen Unternehmen dann sehr viel in die Qualitätssicherung investieren, um sicherzustellen, dass der Kunde keinen Schaden nimmt.
Gregor: Welche Rolle spielt die Public Cloud bei der Software-Entwicklung?
Jan: Der entscheidende Erfolgsfaktor der Public Cloud ist die Qualität der angebotenen Produkte.
In den 1980er Jahren mit Windows gab es häufig Fehlermeldungen. Irgendein Error mit der Fehlermeldung 379. Und keiner wusste, was zu tun ist.
Die Cloud ist inzwischen so weit entwickelt, dass nur noch wenige Fehler auftreten. So, dass diese kostenmäßig nicht ins Gewicht fallen. So, wie Strom fehlerfrei aus der Steckdose kommt, kommt Computing heute fehlerfrei aus der Public Cloud.
Das ermöglicht es Software-Unternehmen, neue Dienste zu entwickeln, in Entwicklungsumgebungen zu testen und dann an den Markt zu bringen. Und das ohne permanent Angst vor Regressforderungen zu haben. Einfach weil die Produkte dann stabil laufen.
Gregor: Wir haben jetzt viel über Software-Entwicklung gesprochen, wie sieht es denn mit dem Prozess von der Idee bis zu einer gut beschriebenen User Story aus? Insbesondere bei großen Organisationen mit viel bestehender IT stimmt man sich da ja zu Tode ab …
Jan: Gewichtiger Punkt, also eine durchgängige Umgebung bei der alles gut sortiert in einer bestimmten Cloud ist, das habe ich ja in der Regel nicht. Meistens ist es ja ein Zoo von Systemen aus unterschiedlichen Technologie-Generationen, die ihren Teil zur Wertschöpfung beitragen. Und die neue Idee betrifft dann mehrere der vorhandenen Anwendungen.
Hier hilft die Idee von Wertströmen. Wenn ich einen klaren Blick darauf habe, entlang welches Prozesses der Mehrwert für die NutzerInnen entsteht, dann muss ich nicht mit allen sprechen, sondern nur mit den Stakeholdern entlang dieses Prozesses.
Gregor: Kannst du einmal ein Beispiel nennen für so einen Wertstrom?
Jan: Ein Beispiel könnte der Marketingprozess sein. Dort gibt es NutzerInnen, Ziele und einen darauf ausgerichteten Prozess mit Kampagnen, Bestellungen, Rechnungen und Feedbacks. Aber eben keine Warenhäuser und keine Logistik. Diesen Wertstrom sollte man dann, wie in der Fertigung eines Autos, in eine gemeinsame Taktung bringen.
Gregor: Was meinst du mit Taktung?
Jan: Nehmen wir ein Beispiel, bei dem wir viele parallellaufende Systeme in einem Unternehmen haben. Und nun passiert folgendes: Die Entwickler, die ein neues Produkt bauen, haben die einzelnen Elemente zusammengesteckt und sind mit dem Release fertig. Und dann stellt man fest, dass nichts mehr funktioniert. Das liegt daran, dass die Komplexität dieser vielen Systeme zu groß ist und sich das Zusammenspiel dieser Systeme nicht vorhersagen lässt.
Und die Spezifikation ist nie so gut und so klar, dass sie alle möglichen Fehler umfassend vorwegnimmt.
Und deshalb brauche ich in einem Software-Entwicklungsprozess Rückkopplungspunkte. So entsteht dann eine Taktung. Beispielsweise wird am Ende eines Sprints das Produkt auf bestimmte Systeme gemeinsam eingespielt.
Dann habe ich nicht nur ein theoretisches und ein gemeinsames Konzept, sondern ich habe auch frühere Releases, die gemeinsam funktionieren und kann dadurch sicherstellen, dass ich schon erste Tests ausführen und die Lauffähigkeit testen kann.
Wenn ich das zu spät mache beschert das häufig viele ungeliebte Überraschungen.
Gregor: Was empfiehlst Du Unternehmen, die aus der Hardware kommen und jetzt merken, dass sie eigentlich Software beherrschen lernen müssen?
Jan: Der aktuell innovativste Ansatz ist die Schaffung von digitalen Zwillingen (Digital Twins). Das bedeutet beispielsweise für BMW, dass sie mit einem Auto virtuell herumfahren können, bevor es gebaut ist. Die Hardware wird also in der Software entwickelt und getestet.
Dadurch wird gewährleistet, dass die Software und die Hardware von neuen Produkten gleichzeitig entwickelt wird. Das Zusammenspiel der beiden Komponenten kann in einem Simulator getestet werden. Dadurch können die Hardware- und Software-Entwicklungszyklen aneinander angepasst werden.
Hat das einmal geklappt dann können sie genau diese Integration von Hardware und Software immer wieder machen, weil sie sozusagen ihre gemeinsamen Releases live stellen und gemeinsam simulieren.
Irgendwann muss ich natürlich das Auto dann auch tatsächlich bauen. Aber die Wahrscheinlichkeit, dass das, was in der Simulation erfolgreich ist dann auch wirklich in der Endfertigung zusammenpasst, ist deutlich höher.
Gregor: Aber auch hier frisst die Software wieder die Hardware.
Jan: Ja, natürlich. Software frisst Hardware. Und letztlich werden nur die Unternehmen erfolgreich sein, denen es gelingt, erfolgreich solche Verbundsysteme zu entwickeln.
Dann wird aus Ingenieurskunst ein System Thinking, bei dem permanent das Gesamtsystem aus Hard- und Software optimiert werden kann. Ich muss reale Systeme und Softwaresysteme zusammenbringen und dann natürlich im weiteren Prozess auch gucken, dass die realen Systeme, die ich produziere, dann natürlich auch noch zusammenpassen.
Das ist auch ein Lernprozess, bei dem es darum geht, die unterschiedlichen Parameter zwischen realer Produktion und Softwareumgebung zu erkennen und auszumerzen. Dass die beiden Ebenen zu hundert Prozent matchen ist eben auch nicht zu erwarten. Die Software erstellt sozusagen immer wieder neue Hypothesen, die dann hinterher überprüft werden müssen. Ich baue eine Hardware und überprüfe, ob sie genauso reagiert wie in meinem Simulator. Und wenn das nicht der Fall ist, dann muss ich da eben entsprechend gegensteuern.
Gregor: Das ist ein Paradigmenwechsel, der auch in den Köpfen des Top-Managements stattfinden muss oder?
Jan: Wenn sich das Top-Management damit beschäftigt diese internen Prozesse zu beschleunigen, ist das in der Regel nicht hilfreich. Denn Beschleunigung wird von diesen Managern häufig mit größerer Effizienz gleichgesetzt. Tatsächlich wäre es hilfreich, wenn sich die Ebene des Top-Managements auf die Visionen fokussiert: Was soll tatsächlich erreicht werden? Die Ebene sollte sich also eher um die Rahmenbedingungen kümmern: Wie kann man das Gesamtsystem designen? Was sind die Möglichkeiten, die dieses Gesamtsystem haben darf? Die Aufgabe des Top-Managements besteht also im Grunde darin die Leitplanken zu installieren.
Gregor: Also geht es dabei auch um Budgets und Konfliktlösung?
Jan: Ja, genau. Es reicht nicht nur aus, einen perfekten technischen Prozess zu haben, sondern die Organisation muss auch so designt sein, dass sie dazu passt. Dass sie in der Lage ist eben entsprechend in Wertströmen zu arbeiten und dann eben diese Ergebnisse aus der Feedbackschleife zu bekommen und zu priorisieren. Welche Änderung an welchem Wertstrom ist denn jetzt das Wichtigste?
Und da brauchen wir eben nicht mehr den einsamen Experten, sondern da sind dann eben viele gemeinsam beteiligt. Dazu gehören auch die Menschen, die direkt am Kunden sind. Die sogar noch konkreter die relevanten Themen benennen können.
Da definiert sich die Rolle des Top-Managements neu. Weg vom wissenden Steuerer hin zum Moderator, der andere Experten interviewt und dem es gelingt einen Konsens zu schaffen.
Gregor: Jan, vielen Dank für das Gespräch!
Die Erstellung des Interviews wurde unterstützt von Prof. Dr. Roland Frank.
