Umso erstaunter war ich, als mir kürzlich in einem ruhigen Moment auffiel, dass ich mich selbst im Arbeitsalltag erstaunlich selten daran halte. Und schlimmer noch: dass ich ziemlich gut darin geworden bin, mir das auch noch schönzureden.

Eisenhower ist aus meiner Sicht weiterhin ein sinnvolles Werkzeug – das ist mir wichtig vorwegzuschicken. Gleichzeitig stößt dieses Zeitmanagement-Modell aus der Mitte des 20. Jahrhunderts – entwickelt von einem US-General und späteren Präsidenten – im Arbeitsalltag moderner Wissensarbeiter erstaunlich schnell an seine Grenzen.

Dafür gibt es mehrere Gründe.

Kognitive Überlastung: Wenn zu viele Reize um Aufmerksamkeit konkurrieren

Wissensarbeiter – egal ob Fachspezialisten, Berater oder Entscheider – leiden heute weniger an fehlender Priorisierung als an kognitiver Überlastung. Die ständige Notwendigkeit, zwischen konzentrierter Arbeit an komplexen Fragestellungen und reaktiver Kommunikation zu wechseln, erzeugt Kontextwechselkosten (siehe auch [1]), die Fokus, Entscheidungsqualität und letztlich auch die eigene Zufriedenheit spürbar beeinträchtigen.

Die Eisenhower-Matrix verspricht an dieser Stelle eigentlich Orientierung, scheitert jedoch häufig an der psychologischen Realität der Illusion of Urgency [2]: Aufgaben fühlen sich dringend an, erzeugen Handlungsdruck und verlangen Aufmerksamkeit – ohne deshalb, um in der Sprache von Eisenhower zu bleiben, automatisch auch wichtig oder tatsächlich dringend zu sein.

Für mich hat sich daraus eine einfache, bewusst pragmatische Regel ergeben: Aufgaben, die sich in weniger als fünf Minuten erledigen lassen, versuche ich unmittelbar abzuschließen. Nicht aus Effizienzgründen im klassischen Sinne, sondern um kognitive Last zu reduzieren. Jede nicht beantwortete Rückfrage, jede angefangene, aber nicht abgeschlossene Kleinigkeit bleibt im Kopf präsent – und konkurriert dort mit eigentlich wichtigeren Themen um Aufmerksamkeit.

Das Problem: In meinem hochfragmentierten Arbeitsalltag gibt es überraschend viele „kurze Anfragen“. Und so schlägt die Fünf-Minuten-Regel bei mir erstaunlich oft Eisenhower.

Und ja, ich weiß: Man muss Mails und Chatnachrichten nicht sofort lesen. In der Theorie leuchtet mir das vollkommen ein. In der Praxis stressen mich 13 ungelesene Teams-Nachrichten jedoch zuverlässig. Disziplinierte Zeitfenster für Mail- und Chatkommunikation funktionieren für manche hervorragend. Für mich nicht. Und so stößt auch Eisenhower an seine Grenzen.

Kognitive Last der Organisation: Wenn zu viele Themen gleichzeitig offen sind

Nun ist kognitive (Über-)Last kein individuelles Versagen. Sie ist in vielen Fällen ein übergreifendes organisatorisches Problem. Organisationen arbeiten selten an einem Thema zur gleichen Zeit. Sie arbeiten an sehr vielen. Projekte, Initiativen, Abstimmungen, Eskalationen, strategische Themen und operative Kleinigkeiten laufen parallel – oft über Monate oder sogar Jahre. Jeder offene Vorgang erzeugt kognitive Last. Nicht nur bei Einzelpersonen, sondern im System insgesamt: in Meetings, Statusrunden, Entscheidungsprozessen oder auch nur, weil ich diese eine nervige Aufgabe nun schon zum dritten Mal in die Folgewoche verschiebe.

Diese systemische kognitive Last entsteht unabhängig davon, wie dringend oder wichtig ein einzelnes Thema gerade ist. Allein die Tatsache, dass etwas „noch offen“ ist, bindet Aufmerksamkeit. Ein psychologisches Fundament dieser Beobachtung liefert übrigens der Zeigarnik-Effekt, der besagt, dass uns unterbrochene, unerledigte Aufgaben kognitiv stärker beschäftigen als abgeschlossene [4]. Das kostet Energie – selbst dann, wenn faktisch gerade niemand daran arbeitet.

Ein besonders plastisches Beispiel dafür habe ich im behördlichen Umfeld erlebt. Eine Broschüre sollte aktualisiert werden – kein besonders dringendes Thema, von mittlerer Wichtigkeit. Der erste Entwurf war schnell erstellt. Danach passierte lange Zeit: nichts. Aufgrund interner Prozesse mussten verschiedene Einheiten involviert werden, zwischen den einzelnen Abstimmungen lagen jeweils mehrere Wochen.

Das Ergebnis? Ein Prozess über 20 Monate. Durch unzählige Abstimmungsrunden und Liegezeiten musste sich jeder Beteiligte in jedem Termin neu eindenken („Wo standen wir nochmal?“). Am Ende wurde konservativ geschätzt mindestens das Zehnfache der eigentlichen Arbeitszeit investiert, nur weil das Thema immer wieder liegen blieb. Ein klassisches Beispiel dafür, wie „nicht dringende“ Themen durch reinen Zeitverzug zu hocheffizienten Ressourcenfressern mutieren.

Die Eisenhower-Matrix betrachtet Aufgaben isoliert. Sie hilft dabei, einzelne To-dos zu priorisieren. Was sie jedoch systematisch ausblendet, ist die kumulative Wirkung vieler paralleler, offener Themen auf eine Organisation.

In der Praxis ist es oft nicht das einzelne wichtige oder dringende Thema, das überlastet – sondern die schiere Anzahl an offenen Baustellen. Aus einer Lean-Perspektive ist es deshalb sinnvoll, die Anzahl gleichzeitig offener Themen möglichst gering zu halten. Nicht nur, um schneller zu werden, sondern um arbeitsfähig zu bleiben.

Genau hier beginnt ein Aspekt, den Eisenhower nur unzureichend adressiert: Offene Themen sind nicht neutral. Sie sind nicht einfach „noch nicht dran“. Sie erzeugen Kosten – allein durch ihr Liegenlassen.

Cost of Delay: Wenn Liegenlassen teuer wird

Wenn man genau hinschaut, habe ich im obigen Behördenbeispiel bereits ein Konzept verwendet, ohne es zu benennen: Cost of Delay.

Nicht die (gefühlte und meist sehr subjektive) Wichtigkeit einer Aufgabe entscheidet über ihre Priorität, sondern die Kosten, die entstehen, wenn sie nicht umgesetzt wird. Diese Kosten sind oft nicht sichtbar – aber sie sind real.

Ein einfaches Beispiel: Ein kurzes Debriefing zu einem Konferenzbesuch an Kollegen zu schicken, ist selten dringend und meist auch nicht besonders wichtig. Während der Zugfahrt nach Hause ist das in wenigen Minuten erledigt. Zwei Wochen später brauche ich dafür schon deutlich länger. Zwei Monate später muss ich anhand meiner Notizen rekonstruieren, was ich eigentlich mitteilen wollte.

Die Aufgabe ist dieselbe geblieben – der Aufwand nicht. Die Verzögerung hat hier keinen inhaltlichen Mehrwert erzeugt, sondern ausschließlich zusätzliche Arbeit. Genau das beschreibt Cost of Delay.

In Organisationen wirkt dieser Effekt noch stärker. Der eigentliche Cost of Delay entsteht häufig nicht durch fehlende Umsetzung, sondern durch das Wiederanlaufen: sich erneut einlesen, Kontexte rekonstruieren, Entscheidungen erklären, Abhängigkeiten neu klären. Je länger ein Thema liegt, desto höher werden diese Reibungsverluste. Besonders schön wird es dann, wenn Nachfragen nach dem Stand einer Aufgabe und ein oder zwei Feedbackschleifen in Summe bereits mehr Zeit kosten als die eigentliche Erledigung.

Eisenhower hilft dabei zu entscheiden, was wichtig und dringend ist. Cost of Delay macht sichtbar, was es kostet, nichts zu entscheiden – und Themen immer wieder liegen zu lassen.

Mir ist bewusst, dass Cost of Delay ein abstrakter Begriff bleibt. Mir hilft dieser Perspektivwechsel jedoch sehr, meine Arbeitsprioritäten besser zu setzen. Übliche Dimensionen, die meinen höchst persönlichen Cost of Delay ausmachen, sind:

• der erwartete Mehrwert des Arbeitspakets (strategisch, operativ oder risikoseitig)
• Effizienz- und Reibungsverluste über die Zeit (Wiederanlauf, Abstimmung, Kontextverlust)
• die Möglichkeit, Themen sauber abzuschließen und damit kognitive Last zu reduzieren
• Lernen und Wissensgewinn – oder dessen Verzögerung

Ob ich eine Aufgabe selbst erledige oder delegiere, beantwortet Cost of Delay allerdings nicht. Aber dazu kommen wir im kommenden Abschnitt.

Verteilte Verantwortung: Wenn klassische Delegation an Grenzen stößt

Die Eisenhower-Matrix ist in einer Welt klarer Hierarchien entstanden. Aufgaben werden priorisiert, erledigt oder delegiert. Delegation setzt dabei etwas voraus, das lange selbstverständlich war: eine eindeutige hierarchische Ordnung mit klarer Weisungsbefugnis.

In der Sprache von Reinventing Organizations [5] würde man sagen: Eisenhower passt hervorragend zu bernsteinfarbenen, stark hierarchischen Organisationen. Führung bedeutet dort, Entscheidungen zu treffen und Aufgaben weiterzugeben.

Viele Organisationen funktionieren heute jedoch anders. Wir sprechen über flache Hierarchien, selbstorganisierte Teams, laterale Führung und Servant Leadership. Verantwortung liegt nicht mehr ausschließlich bei einzelnen Rollen, sondern verteilt sich auf Teams. Entscheidungen werden gemeinsam getroffen, Aufgaben gemeinsam getragen.

In solchen Strukturen wird Delegation unscharf. An wen delegiere ich, wenn Verantwortung im Team liegt? Was bedeutet „abgeben“, wenn ich fachlich gar nicht weisungsbefugt bin? Und was passiert, wenn Delegation nicht als Entlastung, sondern als Abschieben wahrgenommen wird?

Gleichzeitig verstehen sich viele Organisationen zunehmend als lernende Systeme. Aufgaben sind nicht nur Mittel zur Zielerreichung, sondern auch Gelegenheiten zur Entwicklung. Konzepte wie Management 3.0 [6] betonen genau diesen Aspekt: Arbeit dient nicht nur der Effizienz, sondern auch dem Lernen, der Motivation und dem Kompetenzaufbau von Mitarbeitern.

Damit wird Delegation zu einer Führungsentscheidung mit mehreren Dimensionen. Nicht jede Aufgabe, die delegierbar wäre, sollte delegiert werden. Und nicht jede Aufgabe, die belastet, lässt sich sinnvoll abgeben. Eisenhower gibt darauf keine Antworten – weil er diese Organisationslogik schlicht nicht kennt.

Fazit: Eisenhower reicht nicht mehr – aber er bleibt hilfreich

Die Eisenhower-Matrix ist kein schlechtes Werkzeug. Sie hilft, innezuhalten, Aufgaben bewusst zu betrachten und sich nicht von jeder Dringlichkeit treiben zu lassen. Das allein ist viel wert.

In meinem Arbeitsalltag reicht sie jedoch nicht mehr aus. Kognitive Überlastung, systemische Reibung, Cost of Delay und veränderte Organisationsformen lassen sich nicht sauber in vier Quadranten pressen. Dafür sind moderne Wissensorganisationen zu komplex – und Arbeit zu stark von Kontext, Abhängigkeiten und Lernen geprägt.

Was mir heute hilft, ist kein Ersatz für Eisenhower, sondern eine Ergänzung: der bewusste Blick auf Liegezeiten, auf kognitive Last – und auf die Frage, was es mich und die Organisation kostet, Dinge nicht zu entscheiden.

Eisenhower hilft mir weiterhin bei der Orientierung. Die eigentliche Priorisierung entsteht jedoch erst im Zusammenspiel aus Kontext, Verantwortung und Cost of Delay. Am Ende bleibt die Erkenntnis: Ein Werkzeug ist eben nur ein Werkzeug. Mit einem Hammer lässt sich vieles erledigen – aber nicht alles im modernen Arbeitsalltag ist ein Nagel.

Referenzen

[1] Multitasking: Switching Costs – https://www.apa.org/topics/research/multitasking 
[2] The Illusion of Urgency –  https://pmc.ncbi.nlm.nih.gov/articles/PMC10159458/ 
[3] Mintzberg, H. (1973). The nature of managerial work.
[4] Zeigarnik-Effekt – https://de.wikipedia.org/wiki/Zeigarnik-Effekt 
[5] Reinventing Organisations – https://www.reinventingorganizations.com/ 
[6] Management 3.0 – https://management30.com/ 

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Während Agilität mit dem de-facto Standard Scrum auf Teamebene oftmals relativ leicht umzusetzen ist, stellt Skalierung der agilen Vorgehensweisen Organisationen regelmäßig vor größere Herausforderungen. Viele Frameworks wie etwa SAFe oder LeSS liefern interessante und gute Ansätze hierfür. Jedoch scheitern Organisationen regelmäßig bei der Einführung dieser, aufgrund heterogener Teams, Anforderungen und Produktlandschaften. So ist beispielsweise ein Team, welches den Checkout-Prozess eines Onlineshops verantwortet, ganz anders zu betrachten als das Team, welches die interne Cloudplattform oder einen Data Lake entwickelt. Jedes dieser Teams hat unterschiedliche Anforderungen an eine teamübergreifende Planung und Zusammenarbeit. Aufgrund der abweichenden Herausforderungen benötigt es ein anpassbares Vorgehensmodell. 

Die Strukturierung und Interaktion von Teams ist eine der größten Herausforderungen in agilen Organisationen. Besonders in der IT müssen Teams häufig komplexe Aufgaben bewältigen und dabei flexibel bleiben. Matthew Skelton und Manuel Pais bieten mit ihrem Buch „Team Topologies“ eine klare Methode, wie Teams organisiert und ihre Schnittstellen gestaltet werden können, um Effizienz, Zusammenarbeit und Anpassungsfähigkeit zu maximieren.

Die Grundidee hinter Team Topologies

• Klare Verantwortlichkeiten: Jede Teamkategorie hat definierte Ziele und Aufgaben, was den Fokus und die Effizienz erhöht. 
• Verbesserte Zusammenarbeit: Gut durchdachte Kommunikationswege und Schnittstellen reduzieren Missverständnisse. 
• Schnelle Anpassung: Enabling-Teams helfen anderen Teams, neue Technologien oder Methoden schneller einzuführen. 
• Optimierte Ressourcennutzung: Plattform-Teams schaffen gemeinsame Infrastruktur, damit sich andere Teams auf ihre Kernaufgaben konzentrieren können.

Auf diese Weise soll der Ansatz der Teamkategorien eine praxisnahe und flexible Methode bieten, um skaliertes Agilitätsmanagement in komplexen Organisationsstrukturen zu implementieren und nachhaltig zu verankern.

In kurzen Worten: Team Topologies soll die Entwicklung von Organisationen im Laufe der Zeit unterstützen, wann immer sich die Bedingungen ändern. 
Moderne Organisationsprinzipien werden gefördert und Softwareanpassungen können schneller umgesetzt werden. In der Realität bleibt es bei der immer gleichen Herausforderung, den Teams dafür entsprechend Zeit zum Testen & Lernen einzuräumen.

Schauen wir uns das Konzept in der notwendigen Tiefe an, um zu erfahren, wie diese Konzepte auch in den eigenen Teams angewendet werden könnten: 

Inhalt:

1. Conway’s Law
2. Team First
3. Vier grundlegende Topologien
4. Team-Interaktionsmodi
5. Organisatorisches Gespür
6. Topologieentwicklung
7. Team-API

1. Conway’s Law

Conway’s Law besagt:

»Jede Organisation, die ein System entwirft, wird zwangsläufig einen Entwurf erstellen, der eine Kopie ihrer Kommunikationsstruktur ist.« 

Anders formuliert: Die Organisationsstruktur und die Kommunikationswege zwischen den Teams spiegeln sich direkt in der Systemarchitektur wider. Ein einfaches Beispiel dazu zeigt die folgende Grafik.

Während Conway’s Law oft als reine Beobachtung beschrieben wird, geht der Ansatz von Team Topologies einen Schritt weiter: Es wird als aktives Gestaltungsprinzip verstanden. Anstatt zu akzeptieren, dass die Architektur die bestehenden Teamstrukturen widerspiegelt, lassen sich Teams gezielt so gestalten, dass sie eine gewünschte Architektur aktiv fördern.

Möchte man beispielsweise eine modulare, lose gekoppelte Architektur, sollten die Teams entsprechend strukturiert werden. Dies gelingt durch den Aufbau autonomer, funktionsübergreifender Teams sowie durch die Etablierung klarer Schnittstellen und definierter Verantwortlichkeiten. Dieses Prinzip wird als Inverses Conway’s Law bezeichnet. In unserem Projektalltag begegnen wir diesem Phänomen immer wieder.

Ein Beispiel aus der Praxis: Selbst sehr erfahrene Entwickler entwerfen zum Teil monolithische, fehleranfällige Strukturen – nicht aufgrund mangelnden Könnens, sondern weil:

• Architekturbausteine mit zu viel Funktionalität überladen werden, da Entwickler in diesen Bereichen besonders vertraut sind.
• Hoher Lieferdruck führt dazu, dass eigentlich isolierte Funktionalitäten schnell in bestehende Strukturen integriert werden, statt sauber gekapselt zu werden.

Ob traditionelles oder inverses Conway’s Law: Das „Störgefühl“, wenn die Softwarearchitektur nicht mehr zur Teamstruktur passt, kennt fast jeder. Sich dieses Zusammenhangs bewusst zu sein, ist der erste Schritt, um sowohl die Architektur als auch die Organisation gezielt weiterzuentwickeln.

(Mehr dazu hier: Conway´s Law – EN  / Conway´s Law DE)

2. Team First

Bei Team Topologies wird ein Team als eine stabile Gruppe von Menschen betrachtet, die am gleichen Ziel arbeiten. Verantwortlichkeiten werden keinen Einzelpersonen zugewiesen, sondern Teams.

Die Anzahl der Teammitglieder ist entscheidend, um Vertrauen zu bilden. Ein effektives Team umfasst laut Team Topologies 7 bis 9 Personen. 

Bis eine einigermaßen geschlossene Einheit entsteht, dauert es bis zu drei Monate. Es ist kaum sinnvoll, Teams nach Abschluss eines Projekts, an dem sie ein halbes Jahr gearbeitet haben, neu zu strukturieren. Die emotionale Anpassung an die Arbeitsgewohnheiten und Sichtweisen neuer Kollegen hat einen gravierenden Einfluss auf die Leistung. Nur wenn das Vertrauen in eine Organisation hoch ist, ist ein Teamwechsel einmal im Jahr ohne negative Auswirkungen möglich.

Die Autoren betonen, dass es wichtig ist, die kognitiven Fähigkeiten des Teams zu maximieren, durch die Verbesserung der Arbeitsumgebung, des Führungsstils und die Minimierung von Ablenkungen.

Diese Ansicht wird bereits in vielen bekannten Team-Konstellationen angewandt, wie beispielsweise in Projektteams, Enabling oder Transformationsteams. Die Vorteile von Teams mit klarem Fokus ohne Ablenkungen von “außen” sind nicht von der Hand zu weisen. 

John Sweller bezeichnet Kognitive Belastung mit: „Die Gesamtmenge an geistiger Anstrengung, die im Arbeitsgedächtnis aufgewendet wird.“

Drei Arten der kognitiven Belastung werden benannt:

• Intrinsische kognitive Belastung – bezieht sich auf die Faktoren, die für die Lösung der Aufgabe bedeutend sind. Beispiel: Wie kreieren wir eine neue Methode?
• Externe kognitive Belastung – bezieht sich auf die Voraussetzungen, in der die Aufgabe ausgeführt wird. Beispiel: Wie konfigurieren wir diesen Service?
• Lernbezogene kognitive Belastung – bezieht sich auf Inhalte, die erlernt werden müssen, um die Aufgabe zu lösen. Beispiel: Wie funktionieren Bank Transfers?

Mehr dazu hier: Cognitive Load Theory – DE.

Team Topologies spricht davon, die Verantwortlichkeit des Teams so zu beschränken, dass es die maximale kognitive Belastung des Teams nicht überschreitet.

Aus unserer Sicht wird es entscheidend sein, wie viel Zeit den Teams eingeräumt wird, um zu lernen, wie alltägliche Herausforderungen gemeistert werden, ohne die maximale kognitive Belastung zu überschreiten. Der Lieferdruck auf Teams und das Problem, dauerhaft an zu vielen Aufgaben parallel zu arbeiten, macht evident, wie wichtig es ist, in den Teams zu lernen, die Verantwortlichkeiten klar zu definieren und zu beschränken.

 Das Lernen im Tagesgeschäft  “nein” zu sagen, erweist sich unter hohem Lieferdruck, meist als nicht überwindbares Unterfangen und wird selten vom Management in Drucksituationen akzeptiert. Die Akzeptanz auf Managementebenen ist aber maßgeblich, um die Theorie auch in der Praxis umsetzen zu können. Hier zeigt sich für uns klar, dass die gesamte Organisation “lernen” muss.   

Eine Möglichkeit könnte der Team-First-Ansatz sein. Durch den Team-First-Ansatz soll Mitarbeitern die Möglichkeit gegeben werden, in einer Organisation erfolgreich zu sein. Anstatt ein dickes Fell oder Belastbarkeit zu benötigen, um in einer Organisation zu überleben, haben Mitarbeiter in einer Team-First-Organisation den Raum und die Unterstützung, ihre Fähigkeiten und Praktiken zu entwickeln.

3. Die vier grundlegenden Teamtopologien

Es gibt sehr viele Teamtypen in Organisationen. Der Einfachheit wegen werden diese auf vier Haupttypen reduziert. Diese betrachten das Verhalten und die Fähigkeiten der Teams und lauten wie folgt:

Stream-aligned Team: Das Team, das auf die Geschäftsveränderung ausgerichtet ist, mit einem funktionsübergreifenden Kompetenzmix und der Fähigkeit, signifikante Inkremente zu liefern, ohne auf ein anderes Team warten zu müssen.

Enabling-Team: Das Team, das andere Teams bei der Einführung und Änderung von Software im Rahmen einer Übergangs- oder Lernphase unterstützt.

Complicated-subsystem Team: Das Team mit einer besonderen Aufgabe für ein Subsystem, das zu kompliziert ist, als dass es von einem normalen Stream-ausgerichteten Team oder Plattformteam bearbeitet werden könnte. Optional und nur dann verwendet, wenn es wirklich notwendig ist.

Plattform Team: Das Team, das an der zugrunde liegenden Plattform arbeitet und Stream-ausgerichtete Teams bei der Bereitstellung unterstützt. Die Plattform vereinfacht komplexe Technologie und reduziert die kognitive Belastung für Teams.

Nehmen wir hier nochmal als Beispiel ein klassisches Unternehmen aus dem e-Commerce Bereich:

• Ein Stream-aligned Team könnte den gesamten Checkout-Prozess des Onlineshops verantworten, einschließlich der Integration neuer Payment-Dienstleister und der UX-Optimierung.
• Das Unternehmen möchte verstärkt die Vorteile der Cloud-native Entwicklung nutzen. Ein Enabling Team könnte hierbei bei der Einführung der Technologie und notwendigen Architekturmuster helfen, beispielsweise durch Schulungen, Bereitstellung von Prototypen oder Definition von Architekturpattern.

• Als complicated-subsystem-Team entwickelt eine Gruppe von Spezialisten einen hochspezialisierten Empfehlungsalgorithmus, welcher Kundinnen und Kunden passgenaue Produktempfehlungen zur Verfügung stellt.
• Unser fiktives Unternehmen hat direkt zwei Plattform-Teams, welche zum einen die interne Developer-Cloudplattform und zum anderen einen Unternehmensweiten Data-Lake zur Verfügung stellen.

4. Team-Interaktionsmodi 

Ineffektivität wird in vielen Organisationen durch schlecht definierte Interaktionen verursacht. Laut TeamTopologies läuft die Beziehung zwischen den Teams auf zwei Dinge hinaus: Wird durch die Zusammenarbeit mit einem anderen Team ein Ziel erreicht oder bietet es dem Team einen Service an. Auf diese Weise werde drei Möglichkeiten festgelegt, wie Teams interagieren können:

Zusammenarbeit enge Zusammenarbeit mit anderen Teams. Dies ist besonders nützlich, wenn Teams neue Technologien oder Techniken erforschen. Die Zusammenarbeit ermöglicht die schnelle Entdeckung neuer Dinge, da kostspielige Übergaben vermieden werden. Am besten verwendet, wenn ein hohes Maß an Anpassungsfähigkeit zwischen zwei Teams erforderlich ist.

X-as-a-Service etwas mit minimaler Zusammenarbeit nutzen oder bereitstellen.
Dieser Interaktionsmodus kann die Liefergeschwindigkeit erhöhen. Team A braucht etwas, um seinen Wert zu liefern, Team B hat eine Dienstleistung ohne großen Aufwand bereitgestellt. Es sind keine langwierigen Gespräche, Besprechungen oder Vorbereitungen erforderlich.

Unterstützen: Einem anderen Team helfen und umgekehrt, Hindernisse zu beseitigen. Der unterstützende Interaktionsmodus eignet sich am besten in Situationen, in denen ein Team die Hilfe eines anderen benötigt. Das Enabling Team versetzt zum Beispiel ein anderes Team in die Lage, effektiver zu sein, schneller zu lernen, eine neue Technologie besser zu verstehen oder Hindernisse zu entdecken und zu beseitigen.  Domain-Driven Design kann hier ein gutes Hilfsmittel sein.

5. Organisatorisches Gespür

Mit “Organisatorisches Gespür” ist gemeint: die Situation zu erkennen und anzupassen. Unternehmen müssen flexibel sein, um sich an Veränderungen anzupassen. Dazu gehört die Anpassung der Struktur und Abläufe. Eine Organisation sollte in der Lage sein, die richtigen Teamstrukturen und Interaktionsmodi anzuwenden.

Woran erkennt man also, dass eine Organisation sich weiterentwickeln muss?

1. Die Software wird für ein Team zu komplex. Während am Anfang jeder ein umfassendes Verständnis davon hat, was vor sich geht, wird das immer schwieriger. Dadurch verlagert sich der Fokus von echten Prioritäten auf den Versuch, Leute zu finden, die kompetent genug sind, um ein bestimmtes Problem zu lösen.
2. Die Lieferfrequenz verlangsamt sich. Die Teammitglieder sehen, dass eine Lieferung mehr Zeit und mehr Schritte erfordert. Um dies zu vermeiden, müssen Teams autonom sein und dürfen nicht darauf warten, dass andere Teams eine neue Infrastruktur erstellen.
3. Mehrere Geschäftsdienste basieren auf einer großen Anzahl zugrunde liegender Dienste. In einigen Sektoren wie Finanzen, Versicherungen, Regierung usw. können hochrangige Dienste auf Dienste auf niedrigerem Niveau angewiesen sein. Die Lösung könnte darin bestehen, die Dienste auf niedrigerer Ebene zu “plattformisieren” und für jeden Dienst auf hoher Ebene Stream-ausgerichtete Teams einzusetzen.

Hier spricht man von der Kompetenz der OrganisationswahrnehmungDies ist die Fähigkeit, die Organisationsituation so zu erfassen oder zu spüren, dass das Überleben der Organisation sichergestellt wird. Einige der Dinge, die eine Organisation „spüren“ muss, sind:

• Müssen die Teaminteraktionsmodi geändert werden?
• Was behindert den Arbeitsfluss für ein bestimmtes Team?
• Sollen wir ein bestimmtes Tool bauen oder können wir es von einem Anbieter bekommen?

Es gibt nicht wenige Systeme, die über viele Jahre hinweg entstanden sind. Diese Systeme haben Abhängigkeiten, die nicht außer Acht gelassen werden können. Die Teaminteraktionsmodi passen sich an das System an und nicht umgekehrt. Die Frage, die sich stellt, ist: Was kann oder muss ich tun, um die Komplexität des Systems zu verringern, damit die Vorteile der Teaminteraktionsmodi zum Tragen kommen, und ist dies aufgrund der Größe des Systems überhaupt möglich?

6. Topologieentwicklung

Sobald eine Organisation auf neue Herausforderungen reagiert, ist davon auszugehen, dass Teams untereinander anders als zuvor interagieren werden.

Dies kann bedeuten, dass Teams neu strukturiert oder neu zusammengesetzt werden, um spezifische Probleme anzugehen oder neue Technologien zu implementieren. Gleichzeitig können sich die Arbeitsabläufe und Prozesse ändern, um die Zusammenarbeit zwischen den Teams zu verbessern. Das übergeordnete Ziel besteht darin, sicherzustellen, dass die Teams flexibel genug sind, um sich an veränderte Anforderungen anzupassen, und dass ihre Interaktionen effektiv sind, um die Ziele der Organisation zu erreichen. Dies erfordert eine kontinuierliche Bewertung und Anpassung der Teamstrukturen und -interaktionen im Einklang mit den sich ändernden Anforderungen und Zielen der Organisation.

7. Team-API 

Eine Beschreibung der Interaktionen mit dem jeweiligen Team: Code, Versionierung, Wiki und Dokumentation, Praktiken und Prinzipien, Kommunikation, Arbeitsinformationen und einiges mehr. Ziel ist es, anderen Teams transparent und in einem einfachen Überblick zu zeigen, an was, wie, mit wem, das Team arbeitet. Ein gutes Beispiel für eine Team API hat Team Topologies selbst auf Github.com veröffentlicht.

Zusammenfassung

Die sieben Grundideen von Team Topologies bieten Vorteile, die die Effektivität der Teamarbeit in Unternehmen steigern können. 

Die Fähigkeit zur Flexibilität und Anpassungsfähigkeit, denn durch die Strukturierung von Teams können Unternehmen schnell auf Veränderungen reagieren und neue Anforderungen integrieren. 

Das Übertragen von Verantwortlichkeiten an eigenständige Teams fördert die Autonomie und Eigenverantwortung, beschleunigt die Entscheidungsfindung und fördert agile Reaktionen auf Herausforderungen (siehe 3. Grundidee), wenn das Management mit einbezogen wird und Verantwortung an die Teams weitergibt.
Ferner ermöglicht Team Topologies die Bildung hochspezialisierter Teams, die sich auf bestimmte Aufgaben oder Technologien konzentrieren können, die Entwicklung von Expertise fördert und die Effizienz steigert. 

Teams dieser Art gibt es bereits zuhauf in Organisationen. Die große Herausforderung sind die Abhängigkeiten der Teams, des Produkts und nicht zuletzt, wie viel Zeit den Teams eingeräumt wird, um zu wachsen und die Fähigkeiten zu entwickeln, die es benötigt. 

Wenn spezialisierte Teams in ihren eigenen Bereichen isoliert arbeiten und den Informationsaustausch behindern, können Kommunikationsbarrieren entstehen. Das Entstehen von Silos innerhalb des Unternehmens, wenn einzelne Teams isoliert arbeiten und der Gesamtüberblick über Projekte verloren geht, steigt.
Dies kann die Synergien zwischen den Teams behindern und die Effizienz beeinträchtigen. Zudem kommt die zunehmende Komplexität und der Koordinationsaufwand, wenn eine Vielzahl spezialisierter Teams gleichzeitig agiert. Eine klare Fokussierung auf gemeinsame Ziele kann dieses Problem mindern. Hierbei könnten sich die Vorgehensweisen von Team Topologies als klarer Vorteil erweisen. Zwar sind nicht alle Ideen von Team Topologies neu, jedoch ermöglicht die globale Sicht auf die Teams eine einheitliche strategische Ausrichtung und ein gemeinsames Vokabular für IT-Projekte. 

Zusammenfassend hier eine Kurzübersichtskarte: QRC Team Topologies

Herausforderungen bei der Umsetzung

Die Theorie von Team Topologies ist vielversprechend, aber wie bei jedem Ansatz gibt es auch Herausforderungen:

• Management-Unterstützung: Ohne ein Management, das die Prinzipien von Autonomie und psychologischer Sicherheit versteht und fördert, wird es schwer, die Teams nachhaltig zu etablieren. Ein Führungsstil der Haltung “Servant Leadership” ist eine Grundvorraussetzung für den Erfolg und die Produktivität der Teams.
• Silos und Abhängigkeiten: Oft arbeiten Teams isoliert voneinander. Hier braucht es gezielte Interaktionsmodi, um Synergien zu fördern.
• Zeit und Ressourcen: Teams benötigen Raum und Zeit, um ihre Arbeitsweisen zu entwickeln und zu verbessern. Teams müssen mit entsprechenden Personen besetzt und “ausgebildet” werden. Dies wird häufig unterschätzt.

Schlussfolgerung und Einladung zur Diskussion zur Verbesserung ihrer Teams Team Topologies bietet eine mächtige Grundlage, um Teams effektiver, autonomer und besser miteinander vernetzt zu gestalten. Die Implementierung erfordert jedoch eine bewusste Anpassung an die jeweilige Organisation und ein Management, das diese Ansätze aktiv unterstützt.  

Diskussionsfragen an den Leser: 

• Wie sieht es bei Euch im Unternehmen aus? Welche Erfahrungen haben Sie mit der Strukturierung von Teams gemacht, und welche Ansätze haben bei Ihnen besonders gut funktioniert?
• Wie können Organisationen sicherstellen, dass ihre Teamstrukturen nicht nur effizient, sondern auch anpassungsfähig sind?
• Welche Herausforderungen sehen Sie bei der Implementierung der vier Teamarten in Ihrem eigenen Umfeld?

Kaschef Yawar

Geschäftsbereichsleitung »Handel« Prokurist

Kaschef Yawar ist ein erfahrener agiler Coach und Berater mit über 15 Jahren Erfahrung in der IT-Branche. In seinen Rollen als Scrum Master, Agiler Coach und Trainer hat er erfolgreich agile Methoden in verschiedenen Unternehmen und auf unterschiedlichen Ebenen eingeführt und begleitet. Sein Fokus liegt dabei hauptsächlich auf Scrum und Kanban, sowie der Arbeit in skalierbaren Frameworks wie SAFe, LeSS und Nexus. Besonders wichtig ist ihm die wertgetriebene Entwicklung, bei der er stets darauf achtet, dass die entwickelten Produkte und Dienstleistungen einen echten Mehrwert für die Kunden schaffen.

k.yawar@atra.consulting    

• LinkedIn

Inhalt:

• Einleitung
• Interner Softwareentwickler – externer Berater im Anwenderunternehmen
  • Personalnebenkosten
  • Produktivität
• Fazit

Einleitung

Wenn man in Umfeldern tätig ist, in denen sowohl angestellte Mitarbeiter als auch externe Berater eingesetzt werden, wird man früher oder später mit der Frage konfrontiert, warum der Externe im Vergleich zum Angestellten so teuer sei. Hier wird dann häufig der Tagessatz eines externen Beraters, welcher beispielsweise als Java-Entwickler für einen Kunden tätig ist, mit 20 Arbeitstagen multipliziert und mit dem Bruttomonatsgehalt eines bei dem Kunden angestellten Java-Entwicklers verglichen.

Für einen angestellten Java-Entwickler sind das derzeit durchschnittlich 70.250 € [1] pro Jahr. Das Beratungshonorar eines externen Beraters kann erheblich variieren, ein Freelancer ist dabei üblicherweise günstiger als ein über eines der großen Beratungshäuser, wie zum Beispiel Accenture, eingesetzter Berater. Ein Durchschnittswert von 1.000 € pro Tag für einen externen Berater erscheint aus unserer Erfahrung realistisch. 20.000 € im Monat für einen externen Berater im Vergleich zu 5.854 € für einen angestellten Softwareentwickler wirken auf den ersten Blick nachvollziehbarerweise unverhältnismäßig – bei dieser Betrachtungsweise würde ein Angestellter nicht mal ein Drittel eines Externen kosten. Wieso machen Unternehmen das also?

»Für jedes Problem gibt es eine Lösung, die einfach, klar und falsch ist.« –H. L. Mencken

Wie so häufig ist die Realität nicht einfach und es nur mit der „Äpfel mit Birnen vergleichen“-Metapher abzutun, auch wenn sie hier zutrifft, wird der Sache nicht gerecht. Deshalb werden wir die Thematik im Folgenden einmal genauer beleuchten.

Entscheidend für entsprechende Kostenvergleiche ist zunächst die Art und Weise der Kalkulation im Unternehmen. Beim Einsatz von Softwareentwicklern, um den es hier geht, ist die Frage, ob das Unternehmen mit Softwareentwicklung Geld verdient oder die Softwareentwicklung Mittel zu einem (anderen) Zweck ist. Handelt es sich also um ein IT- beziehungsweise Softwareunternehmen oder – aus der Perspektive der IT beziehungsweise Softwareentwicklung – um ein Anwenderunternehmen? Buchhalterisch gefragt: Ist die Softwareentwicklung Aktiv- oder Passivposten in der Bilanz des Unternehmens, Profit- oder Cost-Center? Betriebswirtschaftlich weiter gefasst: Handelt es sich bei der Softwareentwicklung um einen Kern- oder Hilfsprozess für das Unternehmen?

Abbildung 1: Exemplarische Prozessübersicht eines Handelsunternehmens

Im obigen Beispiel haben wir die vereinfachte Prozesslandschaft einer Handelsorganisation als ein Anwenderunternehmen dargestellt, welche im Wesentlichen aus den beiden Kernprozessen Einkauf und Verkauf besteht; die IT ist hier üblicherweise (noch) nur Mittel zum Zweck, also ein unterstützender Prozess beziehungsweise eine Kostenstelle.

Natürlich hat sich gerade in den vergangenen 10 Jahren diesbezüglich in deutschen Handelsunternehmen viel getan. Getrieben durch Amazon und die Digitalisierung kennen wir auch klassische Handelsunternehmen, die die Umsatz-Parität zwischen online und offline erreicht haben und mehr als 1.000 Mitarbeiter in ihren Technologiebereichen beschäftigen. Diese Firmen sind sicherlich nicht mehr als reine Handelsorganisationen zu verstehen. Ob sie schon wie ein reines Technologieunternehmen kalkulieren, lassen wir für diese Betrachtung außen vor.

Je nachdem, ob die Softwareentwicklung Kern- oder Hilfsprozess für eine Organisation ist, wird entsprechend anders kalkuliert. Deshalb differenzieren wir in unserer weiteren Betrachtung auch entsprechend nach Anwender- und Technologieunternehmen und zeigen anhand einer Vollkostenkalkulation zunächst für ein Anwenderunternehmen auf, was ein angestellter Softwareentwickler wirklich kostet.

Die einfachste Form eines Technologieunternehmens ist ein freischaffender Softwareentwickler. Auch hier erleben wir häufig sehr vereinfachende Darstellungen betriebswirtschaftlicher Realitäten, die dann eher in die Richtung gehen, dass man als Freelancer doch so viel mehr verdienen würde als ein angestellter Softwareentwickler. Da dies im Prinzip nur die andere Seite der eingangs geschilderten Problematik darstellt, zeigen wir in einem zweiten Schritt anhand eines Soloselbständgen auf, was es aus Sicht eines Technologieunternehmens bei der Vollkostenkalkulation zu beachten gilt.

Dass der eingangs gezeigte Vergleich des Monatsgehalts mit dem Beratungshonorar betriebswirtschaftlich schlicht falsch ist, zeigen auch Einblicke aus unserer eigenen Managementpraxis in entsprechenden Unternehmen. Zumindest ab einer gewissen Ebene und in den Finanzabteilungen größerer Unternehmen ist man sich natürlich bewusst, dass die Kosten eines Angestellten mehr umfassen als nur sein Gehalt. In dieser sogenannten Vollkostenbetrachtung kalkulierte man beispielsweise schon in den 2000er Jahren in der Telekommunikationsbranche mit ~750 € pro Tag für einen angestellten IT-Experten, wie wir aus entsprechenden Mandaten wissen. Aus der Finanzdienstleistungsbranche liegen uns aus dem vergangenen Jahr kalkulatorische Kosten angestellter Softwareentwickler in Höhe von 900 € pro Tag vor, von einem anderen Unternehmen wissen wir, dass IT-Experten intern sogar mit weit über 1.000 € verrechnet werden. Das Beratungshonorar eines externen IT-Spezialisten in Höhe von rund 1.000 € pro Tag unterscheidet sich also scheinbar doch gar nicht so sehr von den „echten“ beziehungsweise kalkulatorischen Vollkosten eines angestellten IT-Experten in einem Anwenderunternehmen.

Über die Hintergründe, warum scheinbar wissentlich in Organisationen falsch kalkuliert (oder kommuniziert) wird, können wir nur spekulieren. In Preisverhandlungen mag die (falsche) Vereinfachung noch als Taktik durchgehen. Des Weiteren lässt sich nur vermuten, dass das durchaus vorhandene Wissen bewusst oder unbewusst nicht an alle Stellen im Unternehmen weitergegeben wird. Hier kann dieser Beitrag vielleicht für ein wenig Aufklärung sorgen.

Da die Softwareentwicklung den Schwerpunkt unserer Beratungstätigkeit umfasst, fokussieren wir uns hier auch entsprechend auf selbige. Die Beispiele lassen sich aber auf beliebige andere Rollen, die sowohl von eigenem Personal als auch externen Beratern in Organisationen übernommen werden, transferieren, seien es agile Coaches, IT-Projektleiterinnen, UX-Designer oder beispielsweise Business Analysten, um nur einige zu nennen.

Interner Softwareentwickler – externer Berater im Anwender­unterneh­men

Wie kommt man nun also von durchschnittlich 5.854 € Bruttomonatsgehalt eines angestellten Softwareentwicklers in einem Anwenderunternehmen auf 20.000 € kalkulatorische Vollkosten beziehungsweise externes Beratungshonorar – für die gleiche Arbeit? Zwei wesentliche Aspekte gilt es hier zu bedenken. Einerseits die weiteren Kosten neben den reinen Gehaltskosten, also die Personalnebenkosten im weitesten Sinne. Andererseits die Produktivität, also wieviel Stunden oder Tage für das Gehalt im Falle eines Softwareentwicklers dann wirklich auch für die Softwareentwicklung aufgewendet wird; der externe Berater wird ja nur bezahlt, wenn er für den Kunden tätig ist, also Software entwickelt, der Angestellte erhält sein Gehalt auch, wenn er im beispielsweise im Urlaub ist.

Personalneben­kosten

Schauen wir uns zunächst die weiteren Kosten aus Arbeitgebersicht neben dem Bruttomonatsgehalt eines Angestellten an. Als Erstes fallen für den Arbeitgeber natürlich die anteiligen Beiträge zur Sozialversicherung an, aber auch die Entgeltfortzahlung im Krankheitsfall und beispielsweise Zahlungen an aus dem Unternehmen ausscheidende Arbeitnehmer (Abfindungen) dürfen bei Angestellten nicht außer Acht gelassen werden. Gemäß statistischem Bundesamt [2] ist hierfür im Schnitt mit 23,3 % zu kalkulieren.

Da die dort angenommenen 233 € pro Jahr für Weiterbildung in der Softwareentwicklung unserer Erfahrung nach nicht ausreichen, legen wir hierfür realistischere 3.000 € pro Jahr zugrunde, circa 2.000 € für eine mehrtägige Weiterbildung und rund 1.000 € für einen zweitägigen Konferenzbesuch.

Außerdem sind die Arbeitsplatzkosten zu berücksichtigen, welche je nach Standort und Ausstattung natürlich erheblich variieren können – 1.000 € pro Monat erscheint uns hier ein realistischer Näherungswert für einen Arbeitsplatz inklusive IT-Ausstattung1. Natürlich können auch für einen externen Berater Arbeitsplatzkosten beim Kunden anfallen, wir gehen hier von dem unserer Erfahrung nach (gesetzlich) üblichen Szenario aus, bei welchem der externe Berater nur zu Besprechungen beim Kunden ist und ansonsten mit und in eigener Infrastruktur arbeitet.

Die durchschnittlichen Vollkosten eines angestellten Softwareentwicklers liegen somit bereits bei rund 8.500 € pro Monat beziehungsweise rund 100.000 € pro Jahr:

Tabelle 1: Vollkostenkalkulation eines angestellten Softwareentwicklers – Stufe I

Es geht allerdings noch weiter, denn in der Vollkostenbetrachtung ist aus Sicht eines Anwenderunternehmens zumindest auch das Management der Mitarbeiter als Kostenposition anzusetzen2. Addiert man die oben genannten Personalnebenkosten zu dem durchschnittlichen Gehalt eines Teamleiters im IT-Bereich von 78.250 pro Jahr [1], ergeben sich für selbigen monatliche Vollkosten in Höhe von 9.290 €. Da es gegebenenfalls mehrere Führungsebenen gibt, die mit jeder Stufe mehr kosten, deren Anteil pro Mitarbeiter aber auch immer geringer wird, setzen wir als Managementkosten aus Vereinfachungsgründen 10.000 € pro Monat für einen IT-Teamleiter und die weiteren Hierarchie-Stufen an:

Tabelle 2: Vollkostenkalkulation eines angestellten Teamleiters in der IT

Wie viel dieser Managementkosten dem einzelnen Mitarbeiter zugerechnet werden, hängt von der Führungsspanne ab. In agilen Entwicklungsorganisationen besteht ein Team gemäß Amazons berühmter »Two Pizza Team«-Regel [4] zwar idealerweise aus weniger als 10 Personen, wir sehen hier regelmäßig aber auch größere Teams, so dass man als durchschnittliche Teamgröße durchaus 10 Personen ansetzen kann. Das Management eines Teams verteilt sich im agilen Kontext allerdings auf mehrere Rollen. Ein „klassischer“ Teamleiter ist hier beispielsweise nun sogenannter Chapter Lead, der sich „nur“ noch um die disziplinarische Führung seiner Mitarbeiter kümmert und dadurch unserer Erfahrung nach dann bis zu maximal 25 Mitarbeiter betreut. Dazu kommt dann üblicherweise ein Product Owner je agilem Entwicklungsteam, der sich um das Inhaltliche kümmert, also was getan wird. Für prozessuale Fragen unterstützt dann noch ein Scrum Master oder agiler Coach – unserer Erfahrung nach in der Regel zwei Entwicklungsteams.

Ein durchschnittliches agiles Entwicklungsteam mit 10 Mitarbeitern wird so also von 1,9 „Führungskräften“ unterstützt. Aus Vereinfachungsgründen setzen wir für den Product Owner und Scrum Master die gleichen Vollkosten wie für den Teamleiter an, womit sich folgenden Vollkostenkalkulation ergibt:

Tabelle 3: Vollkostenkalkulation eines angestellten Softwareentwicklers – Stufe II

Aus rund 70.000 € Jahresbruttogehalt eines angestellten Softwareentwicklers werden in der agilen Entwicklungsorganisation eines IT-Anwenderunternehmens bei Betrachtung der Personalnebenkosten und der Kosten für das Management somit Vollkosten von nahezu 125.000 € pro Jahr.

Produktivität

Wie weiter oben schon kurz geschildert, fällt das Honorar für einen externen Berater nur an, wenn er auch für seinen Kunden tätig ist. Ein Angestellter erhält sein Gehalt hingegen auch, wenn er nicht für seinen Arbeitgeber tätig ist, also bei Urlaub, Krankheit und so weiter. Um die beiden Modelle vergleichen zu können, müssen also die effektiven Arbeitstage eines Angestellten ermittelt werden.

Von den rund 250 Arbeitstagen pro Jahr sind 30 Urlaubstage und 13 Krankheitstage [5] für einen Softwareentwickler abzuziehen. Für Weiterbildung setzen wir 5 Tage an, weitere 5 Tage müssen für den gesetzlich jedem Arbeitnehmer zustehenden Weiterbildungsurlaub pro Jahr abgezogen werden, womit 197 Tage verbleiben. Ein IT-Anwenderunternehmen kann für einen angestellten Softwareentwickler also mit rund 200 Anwesenheitstagen pro Jahr kalkulieren.

Aufgrund von Mitarbeitergesprächen, Team- oder Abteilungsbesprechungen, Mitarbeiterversammlungen und sonstigen Einflüssen kann diese Zeit nicht vollständig produktiv angerechnet werden – außerdem gilt es, Parkinson’s Law zu beachten:

»Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.« –C. N. Parkinson

Die Zahlen und Quellen zu produktiver Arbeit variieren erheblich. Gemäß einem Anbieter von Bürosoftware gilt die »Faustregel […] dass 25 Prozent der Arbeitszeit unproduktiv sind. Das beinhaltet Arbeitszeit, die für Meetings, Gespräche oder andere unproduktive, aber geschäftlich wichtige Abläufe aufgewendet wird« [6]. Zu einem ähnlichen Ergebnis kommt der „Slack State of Work Report 2023”. Demnach »geben deutsche Arbeitnehmer an, dass sie knapp ein Drittel ihrer Arbeitszeit (29 Prozent) mit Aufgaben verbringen, die nicht direkt auf ihre Ziele einzahlen [10]«. Das US-Unternehmen Tower geht davon aus, dass Mitarbeiter maximal 5 Stunden am Tag produktiv sein können, weshalb dies auch ihre vertragliche Arbeitszeit ist – bei vollem Gehalt [11]; in diesem Fall wird also schon mit 37,5 % unproduktiver Arbeitszeit gerechnet. Eine Untersuchung in UK kommt sogar zu dem Ergebnis, dass aufgrund Socialmedia und anderer Ablenkungen nur 2 Stunden und 23 Minuten eines Arbeitstags produktive Arbeit sind [12] – dies entspräche fast 70 % unproduktiver Zeit. Für unsere weitere Betrachtung setzen wir den unteren Wert der verschiedenen Untersuchungen von 25 % an, was bezogen auf die oben weiter ermittelten 197 Anwesenheitstage zu 49 unproduktiven Tagen im Jahr führt – rund ein Tag pro Woche für nicht-produktive Aktivitäten klingt unserer Einschätzung nach realistisch.

Für einen angestellten Softwareentwickler ergeben sich somit rund 147 effektive oder produktive Arbeitstage pro Jahr:

Tabelle 4: Ermittlung effektive Arbeitstage in der Softwareentwicklung

Fazit

Um die Vollkosten eines angestellten Softwareentwicklers von rund 125.000 € mit dem Beratungshonorar eines Externen vergleichen zu können, müssen die effektiven Arbeitstage des Angestellten herangezogen werden. Wir setzen hierfür die oben ermittelten 147 Tage pro Jahr an, womit der kalkulatorische Tagessatz eines angestellten Softwareentwicklers in einer Vollkostenkalkulation im gezeigten Beispiel schon bei rund *850 € liegt – das vermeintliche Delta zwischen den beiden Ansätzen ist bei kaufmännisch solider Betrachtung also von zunächst dramatisch erscheinenden 70 % auf überschaubare 15 % abgeschmolzen.

Größere Organisation haben in der Regel noch mehr und höhere Kostenpositionen, beispielsweise durch zusätzliche Hierarchiestufen oder weitere Vorteile für Mitarbeiter, welche in einer Vollkostenbetrachtung auch entsprechend berücksichtigt werden müssen – aus 850 € werden so schnell 900 € und mehr pro Tag.

Und dann darf nicht vergessen werden, dass hier am Ende des Tages schließlich doch Äpfel mit Birnen verglichen werden. Externe Berater werden üblicherweise geholt, um Leistungsspitzen / Kapazitätsengpässe abzudecken und / oder Spezialwissen einzubringen. Darüber hinaus sei auch auf die Flexibilität bei ihrem Einsatz verwiesen. Ein externer Softwareentwickler ist unserer Erfahrung nach innerhalb von 2-4 Wochen im Projekt, für die Einstellung eines angestellten fallen 7,7 Monate an [13] – und manchmal, Stichwort Fachkräftemangel, findet sich schlicht gar kein passender Angestellter. Genauso schnell, wie ein Externer gefunden ist, kann sich als Anwenderunternehmen auch wieder von ihm getrennt werden – bei Angestellten fällt dies zu Recht wesentlich schwerer. Kurzfristige Budgetschwankungen lassen sich mit Externen wesentlich leichter ausgleichen – wir kennen Unternehmen, die bewusst Richtung Geschäftsjahres- und somit Budgetende mit Externen entsprechend „atmen”. Und auch über interne Versetzungen, Stellenpläne oder Ähnliches muss ich mir bei externem Personal keine Gedanken machen. Jeder, der schon mal in größeren Organisationen mit einem Betriebsart in diese Themen involviert war, wird sie für sich beziffern können.

Des Weiteren unterscheiden sich die beiden Ansätze auch hinsichtlich ihrer bilanziellen Auswirkungen. 1.000 €, die das Unternehmen verlassen, sind natürlich 1.000 €, egal ob als Gehalt oder Beratungshonorar. Im Rechnungswesen wird aber nicht ohne Grund zwischen Ausgaben, Aufwand und Kosten unterschieden, da 1.000 €, je nachdem wie sie verbucht werden (können), auch einfach nur einen entsprechenden Mittelabfluss darstellen oder die Bilanz und somit den Unternehmenswert dabei entsprechend erhöhen können, Stichwort CAPEX/OPEX [7]. Die sogenannte Aktivierung von externem Beratungshonorar fällt dabei regelmäßig leichter, da Gehälter üblicherweise pauschal Betriebsausgaben und somit OPEX sind.

Vereinfacht gesagt, kostet ein angestellter und ein externer Softwareentwickler also nahezu das gleiche. Entscheidend für das eine oder andere Modell sind also insbesondere deren weitere Eigenschaften. Ob die Vorteile des Externen wie zum Beispiel Flexibilität, Spezialwissen und gegebenenfalls höher darstellbarer Unternehmenswert durch bessere Bilanzierungsmöglichkeiten die zugegebenermaßen auch vorhandenen Vorteile eines Angestellten aufwiegen, kommt, wie immer, auf die individuelle Situation und Zielsetzung an. Bei entsprechenden Vergleichen sollte also auch auf diese echten Unterscheidungskriterien eingegangen werden – die Kosten sind nahezu gleich.

Im zweiten Teil dieses Beitrags werden wir aus Sicht eines Technologieunternehmens aufzeigen, was bei der Vollkostenkalkulation zu beachten ist – und damit das geringe monetäre Delta von rund 15 % zwischen einem angestellten Softwareentwickler und seinem externen Pendant auflösen.

Fussnoten:

1.
Ein Einzelplatz im Coworking-Space ohne Computer ist beispielsweise ab 150 € pro Nutzer und Monat zu haben [8], lässt aber auch noch viele relevante Kostenpositionen außen vor. Eine etwas umfassendere Kalkulation der gemittelten Kosten für die Anmietung eigener Büroräume inklusive Besprechungsraum und Nebenkosten, aber noch ohne Computer, kommt bereits auf nahezu 500 € pro Monat und Arbeitsplatz [3]. Und die Sachkostenpauschale eines Arbeitsplatzes in der Bundesverwaltung wurde bereits 2010 inklusive IT-Kosten mit 1.030 € pro Monat ausgewiesen [9]. Dieser Betrag dürfte sich mittlerweile zwar einerseits noch weiter erhöht haben, umfasst andererseits aber auch Positionen, wie zum Beispiel Kapital- und Investitionskosten, welche nicht in jedem Fall anzusetzen sein dürften. Wir halten 1.000 € pro Monat und Arbeitsplatz inklusive IT-Kosten deshalb für kalkulatorisch angemessen. 

2.
Auch ein externer Berater erfordert natürlich ein gewisses Maß an »Betreuung« durch die Organisation und das Management des jeweiligen Kunden, beispielsweise für Beauftragung, Onboarding, etc. Wir orientieren uns hier am gesetzlichen Rahmen (Stichworte: Scheinselbständigkeit, Arbeitnehmerüberlassung), wonach externe Berater nicht in die Organisation des Kunden eingebunden sein dürfen, und lassen diese im Vergleich zu einem angestellten Mitarbeiter definitiv geringeren Kosten aus Vereinfachungsgründen außen vor. 

Auch wir spenden im geschäftlichen Umfeld zu Weihnachten, anstatt zu schenken. Sinnvoll sollte die Spende aber sein, also einem guten Zweck dienen. Hier wird es dann spannend, denn die Auswahl an möglichen Spendenorganisationen und -empfängern ist riesig. Eine entsprechende Google-Suche zum Stichwort »Weihnachtsspende« brachte alleine 135.000 Ergebnisse hervor.

Hierunter finden sich großartige caritative Einrichtungen, aber eben auch so viele, dass eine Auswahl eigentlich nur dem Zufallsprinzip folgen kann, was für uns aber kein gutes Geschäftsprinzipo ist. Als IT-Beratungsgruppe sollte unsere Spende auch »irgendwie technologisch« sein und vielleicht auch mal den Fokus auf andere problematische oder übersehene Bereiche, für die eine finanzielle Zuwendung sinnvoll ist, lenken.

Da wir Open-Source-Software (»OSS«) nicht nur selbst einsetzen, sondern auch in unseren Projekten propagieren, wissen wir, dass sie einerseits die Grundlage des Internets und unserer heutigen, von Software dominierten Welt ist und es andererseits in diesem Umfeld durchaus problematische und übersehene Bereiche gibt.

Die 2,5 Milliarden aktiven Android-Geräte in 2018 bedeuten beispielsweise entsprechend viele Installationen des Linux-Kernels, denn das Android-Betriebssystem basiert auf eben dieser Open-Source-Software. Doch das ist nur die Spitze des berühmten Eisbergs. Mittlerweile haben viele Nutzer bereits mehrere unterschiedliche Browser auf ihren verschiedenen Computern und Handys parallel installiert, die alle OSS-Komponenten einsetzen, wie die Datenbank SQLite zum Beispiel. Diese kommt dadurch auf unglaubliche 1 Billion aktive Nutzungen.

Open-Source-Software ist also das Rückgrat unserer softwarebasierten Infrastruktur, ähnlich den Brücken und Straßen in unserem Land, wie eine entsprechende Untersuchung der Ford Foundation schon 2016 sehr treffend formulierte.

Anders als diese physikalische Infrastruktur entsteht das Open-Source Rückgrat unserer digitalen Welt allerdings häufig im privaten Kontext von Freiwilligen, welche aus Leidenschaft und ohne wirtschaftliche Motivation ihre Entwicklungen der Allgemeinheit zur Verfügung stellen. Davon aber eben auch nicht leben können und so kritische Infrastruktur von Einzelkämpfern in Nacht- oder Wochenendschichten – neben anderen Jobs – bereitgestellt wird. Wie die OpenSSL-Programmbibliothek beispielsweise, welche geschätzte ⅔ des gesamten Internetverkehrs verschlüsselt. Ein lange unentdeckter Fehler in dieser OSS-Komponente führte zum berühmten Heartbleed-Bug, welcher sogar eine eigene Wikipedia-Seite hat, da durch ihn weite Teile der Verschlüsselung privater Daten im Internet anfällig für Angriffe war. Nicht, dass dies nicht auch bei kommerzieller Software passieren würde; es spricht eher für den Entwickler, der OpenSSL lange Zeit weitestgehend alleine gepflegt hat, dass der Fehler so lange unentdeckt blieb. Die Frage ist aber doch, ob wir die Verschlüsselung eines Großteils unserer Daten im Internet vom Einsatz eines einzelnen und dafür auch noch unbezahlten Menschen abhängig machen wollen?

Da Open-Source-Software Entwickler in der Regel mit großer Leidenschaft an ihre entsprechenden Projekte gehen, gleichzeitig ihre Arbeit naturgemäß sehr transparent, eben offen ist und zum Teil auch viel davon abhängt, ist der Druck in diesem Bereich häufig groß. So groß, dass auch das Thema Burnout hier immer offener diskutiert wird, also offensichtlich immer weiter um sich greift.

Dazu kommt, dass auch im Umfeld von OSS, wie leider mittlerweile üblich im Internet, Hatespeech und Flamewars an der Tagesordnung sind. Ein Großteil der Open-Source-Software-Entwicklung erfolgt über Github. Änderungsanforderungen erfolgen dort unter anderem über sogenannte Pullrequests. In deren Kommentarbereichen geht es wiederum häufig nicht anders zu, als in denselben eines beliebigen Influencers auf Instagram. Das geht sogar bis zu Morddrohungen an Daniel Stenberg, dem Entwickler von »libcurl«, einer Open-Source-Software-Komponente, welche zur Datenübertragung in Netzwerken genutzt wird und als eine der meist verwendeten Software-Bibliotheken gilt. Auch diese Software wurde übrigens lange Zeit von ihm alleine gepflegt.

Ein weiteres Risiko in diesem Umfeld ist die sogenannte »Dependency Hell«, welche dadurch entsteht, dass die Software, die man einsetzt, in der Regel auch wieder auf anderen OSS-Komponenten basiert, welche wiederum andere Open-Source-Software einbindet … Wie der Fall eines bis dahin unbekannten Open-Source-Software Entwicklers 2016 zeigte, der aufgrund von rechtlichen Auseinandersetzungen seine nur 11 Codezeilen umfassende Open-Source-Software-Komponente »left-pad« zurückzog und damit fast “das Internet kaputt gemacht hat”.

Zusammengefasst und überspitzt formuliert muss man sich das, um den Titel der oben genannten Studie aufzugreifen, vorstellen, als ob alle Brücken der Welt ein kleines, tragendes Bauteil enthielten, welches von einem einzigen, vielleicht auch noch überarbeiteten Menschen, der dem Burnout nahe ist und gerade auch noch mit Morddrohungen zu kämpfen hat, freiwillig und kostenlos bereitgestellt würde. Klingt nicht sehr stabil, ist im Internet und da, wo Software zum Einsatz kommt, aber ein Teil der Realität.

Wer also beispielsweise mit dem Handy telefoniert, E-Mails oder WhatsApp-Nachrichten verschickt, im Internet surft oder Videos streamt, wird mit Open-Source-Software in Berührung kommen, die eventuell von so einem Programmierer irgendwo auf der Welt am Laufen gehalten wird. Wir finden, Weihnachten ist eine gute Gelegenheit, auch mal diesen etwas anderen, »stillen Helden« für ihren Einsatz zu danken.

Die atra.consulting-Gruppe spendet diese Weihnachten per Gitub Donors an RubyGems, dem Paketsystem für die Verwaltung und Verteilung von Programmbibliotheken der Programmiersprache Ruby. Die Paketverwaltung stellt für jede Programmiersprache eine besonders kritische Infrastrukturkomponente in der sogenannten Software Supply Chain dar. RubyGems ist dadurch regelmäßig das Ziel von Hacker-Attacken, wie beispielsweise gerade auch wieder npm, das populäre Pendant der JavaScript-Welt. Da die größeren und bekannteren OSS-Komponenten in der Regel mittlerweile auch schon mehr Unterstützung erfahren, haben wir uns bewusst dazu entschieden, dieses Jahr diese vielleicht etwas unbekanntere Open-Source-Software-Komponente zu unterstützen.

Nach dem Zusammenschluss der SCS Consulting GmbH und Schwarze Consulting GmbH bündeln die beiden Unternehmen ihr Portfolio in der atra.consulting GmbH & Co. KG, welche somit nun hochwertige IT-Beratungskompetenz in folgenden Geschäftsbereichen vereint:

• Handel/Online/E-Commerce
• Finanzdienstleistungen
• Behörden

Michael Schwarze, Geschäftsführer der atra.consulting GmbH & Co. KG:

»Schon im Zuge des Mergers war deutlich geworden, dass die beiden bestehenden Firmen und Marken auch weiterhin Bestand haben sollen, da sie über 10 respektive 20 Jahre am Markt etabliert sind. Gleichzeitig wurde es in der Marktkommunikation aber unhandlich, nun von einer “IT-Beratungsgruppe bestehend aus den zwei Einzelgesellschaften SCS Consulting GmbH und Schwarze Consulting GmbH mit den drei Geschäftsbereichen…” zu sprechen. Somit war klar, dass wir eine neue Marke etablieren werden, welche das gemeinsame Portfolio der beiden Firmen nach außen repräsentiert: atra.consulting.«

Die beiden bisherigen Gesellschaften bleiben auch weiterhin bestehen.

Zur Schwarze Consulting GmbH

Seit 2009 unterstützt das Unternehmen namhafte Kunden bei Fragestellungen rund um Softwareentwicklung und das Management von Softwareentwicklungsvorhaben, insb. im innovativen E-Commerce-Umfeld. Die Unternehmens-DNA ist ganzheitliches Software Engineering, also die Entwicklung von langlebigen und wartbaren Softwaresystemen. Dies umfasst Softwarearchitektur- und Technologieberatung, Organisationsberatung von Softwareentwicklungseinheiten zu Struktur- und Prozessfragen sowie Interimsmanagement im Technologieumfeld.

Zur SCS Consulting GmbH

Gegründet 2004 unterstützt das Unternehmen renommierte Kunden aus den Bereichen Finanzdienstleistungen und Behörden im IT- und Business-Consulting. Dies umfasst diverse Managementservices von der Managementberatung bis zum Coaching, sowie die Konzeption und Entwicklung von komplexen IT-Services in einem weiten Technologieumfeld.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Nach über 10 erfolgreichen Jahren in der Beratung rund um Softwareentwicklung insb. im Umfeld Handel, Online/E-Commerce erweitert die Schwarze Consulting GmbH aus Nürnberg ihre Branchenexpertise mit Übernahme der SCS Consulting GmbH aus Stuttgart um die Bereiche Finanzdienstleistungen und Behörden. Gleichzeitig kann so die regionale Präsenz der Unternehmensgruppe auf die dann fünf Standorte Nürnberg, Stuttgart, München, Hamburg und Berlin ausgeweitet werden.

Zur Schwarze Consulting GmbH

Seit 2009 unterstützt das Unternehmen namhafte Kunden bei Fragestellungen rund um Softwareentwicklung und das Management von Softwareentwicklungsvorhaben, insb. im innovativen E-Commerce-Umfeld. Die Unternehmens-DNA ist ganzheitliches Software Engineering, also die Entwicklung von langlebigen und wartbaren Softwaresystemen. Dies umfasst Softwarearchitektur- und Technologieberatung, Organisationsberatung von Softwareentwicklungseinheiten zu Struktur- und Prozessfragen sowie Interimsmanagement im Technologieumfeld.

Michael Schwarze, geschäftsführender Gesellschafter der Schwarze Consulting GmbH:

»Ich freue mich sehr, nach 10 erfolgreichen Jahren organischem Wachstums mit der Übernahme der SCS Consulting GmbH nun das berühmte nächste Kapitel der Unternehmensentwicklung einläuten zu können. Die beiden Unternehmen ergänzen sich hervorragend hinsichtlich ihres Leistungsspektrums und der Branchenexpertise, aber auch bezogen auf ihre Unternehmensphilosophie. So können wir unsere Kunden zukünftig noch umfassender bei ihren IT-bezogenen Fragestellungen unterstützen. Gleichzeitig erreichen wir damit eine Größe, die es uns erlaubt, nicht mehr nur als Sperrspitze für innovative Themen, sondern als umfassender Lösungspartner für unsere Kunden auftreten zu können. Mein herzlicher Dank geht an Herrn und Frau Zink, die ein hervorragend aufgestelltes Unternehmen übergeben. Ich freue mich darauf, mit großartigen Mitarbeiterinnen und Mitarbeitern unsere treuen Kunden weiterhin nachhaltig unterstützen zu dürfen.«

Zur SCS Consulting GmbH

Gegründet 2004 unterstützt das Unternehmen renommierte Kunden aus den Bereichen Finanzdienstleistungen und Behörden im IT- und Business-Consulting. Dies umfasst diverse Managementservices von der Managementberatung bis zum Coaching, sowie die Konzeption und Entwicklung von komplexen IT-Services in einem weiten Technologieumfeld.

Klaus-Ulrich Zink, geschäftsführender Gesellschafter der SCS Consulting GmbH:

»Nach dreieinhalb Jahrzehnten IT-Consulting freuen wir uns, mit Herrn Schwarze und seiner Schwarze Consulting GmbH eine optimale Lösung für unsere Nachfolgeregelung gefunden zu haben. Meiner Frau und mir, als Gründer und Gesellschafter der SCS Consulting GmbH, war es wichtig, für unsere Mitarbeiter:innen sowie Geschäftspartner einen Nachfolger zu finden, der die gewohnte Kontinuität bietet und dabei aber auch den Generationenwechsel ermöglicht. Mit Herrn Schwarze und seiner Schwarze Consulting GmbH ist dies gewährleistet, denn es übernimmt ein erfolgreicher Unternehmer, der über umfangreiche Erfahrung in der Softwareentwicklung, Beratung und dem Management verfügt. Gleichzeitig passt bei ihm aber auch die »Chemie«, so dass wir das Unternehmen, die Kunden und Mitarbeiter:innen in den besten Händen wissen. Wir bedanken uns herzlich bei allen, die uns bis hierhin begleitet haben und wünschen das Beste für die Zukunft.«

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Auch wenn derzeit keine verlässlichen Prognosen möglich sind, haben wir die uns verfügbaren Bruchstücke genommen, um ein Gefühl für die Auswirkungen der Corona-Krise auf den Softwaremarkt zu bekommen. Und noch sieht es nicht so schlimm aus… [Update: Dies ist eine Aktualisierung des Artikels vom 23.4.20 ergänzt um Daten vom 30.3.20.]

Verschiedene Indikatoren können dabei helfen, sich eine Meinung über die wirtschaftliche Entwicklung zu verschaffen, um so beispielsweise unternehmerische Entscheidungen fundieren zu können. Da wir im deutschen Markt für Software tätig sind, schauen wir uns regelmäßig die Prognose des Bundeswirtschaftsministeriums (BMWi) zur Entwicklung des deutschen Bruttoinlandsproduktes (BIP) und die bitkom ITK-Marktzahlen an.

Anfang 2019 war der Ausblick auf die wirtschaftliche Entwicklung in Deutschland mit 1,1 % Wachstum nicht nur sehr positiv, sondern zu dem Zeitpunkt insbesondere auf Basis der Entwicklung der vergangenen Jahre auch durchaus realistisch. Noch besser, dabei aber mindestens genauso verlässlich sah es mit 6,4 % für den Softwaremarkt aus.

Mit Ausbruch der Corona-Krise in Deutschland Anfang März 2020 haben sich diese Prognosen überholt und entsprechende Aussagen sind absehbar mit einer hohen Unsicherheit behaftet. Nichtsdestotrotz haben wir in diesem Artikel vom 23.3.20 eine erste korrigierte Indikation zur Entwicklung der Wirtschaftsleistung gefunden:

»Das Finanzministerium kalkuliert Regierungskreisen zufolge 2020 mit einem Rückgang der Wirtschaftsleistung um sechs Prozent«

Da seitens bitkom bislang noch keine korrigierten Zahlen für den ITK-Markt vorliegen, welche auch die Corona-Krise berücksichtigen, haben wir die vorhandenen Informationen absolut ins Verhältnis gesetzt, um eine erste Prognose für den Softwaremarkt ableiten zu können. Absolut bedeutet in diesem Zusammenhang, dass wir den Vorsprung von 5,3 Prozentpunkten, den der Softwaremarkt bislang bei der wirtschaftlichen Entwicklung gegenüber dem Gesamtmarkt hatte, 1:1 auf die neue wirtschaftliche Realität übertragen haben. Somit ergibt sich mit Stand vom 23.3.20 ein Rückgang des Softwaremarktes in Deutschland in 2020 von 0,7 %.

Einzelne Stellen, wie zum Beispiel auch das ifo Institut berichten zwar in Abhänggikeit von der Dauer des Shutdowns schon von einem Rückgang des BIP von bis zu 20,6 % für dieses Jahr. Wir greifen für diese Betrachtung aber nur auf Informationen aus regierungsnahen Kreisen zurück.

Diesbezüglich liegt seit dem 30.3.20 vom sogenannten »Sachverständigenrat zur Begutachtung der gesamtwirtschaftlichen Entwicklung« oder auch den Wirtschaftsweisen das Sondergutachten »DIE GESAMTWIRTSCHAFTLICHE LAGE ANGESICHTS DER CORONA-PANDEMIE« vor. Hierin werden drei mögliche Szenarien unter Berücksichtung der aktuellen Erkenntnisse der Corona-Krise zur Entwicklung des BIP für 2020 diskutiert. Im sogenanten Basisszenario, welches von den Wirtschaftsweisen als derzeit wahrscheinlichstes angesehen wird, geht die Wirtschaftsleistung in Deutschland dieses Jahr um 2,8 % zurück. Darüber hinaus werden zwei sogenannte Risikoszenarien vorgestellt. Das Risikoszenario »langes U« stellt sich auf ein Minus von 4,5 % ein, wohingegen der derzeitige Worstcase der Wirtschaftsweisen, das Risikoszenario »ausgeprägtes V« von einem Rückgang von 5,4 % ausgeht. Somit ist die Prognose der Wirtschaftsweisen vom 30.3.20 mit im schlimmsten Fall -5,4 % aber auch immer noch besser als die Annahme des Finanzministeriums vom 23.3.20 mit -6 %.

Entsprechend abgeleitet auf die Entwicklung des Softwaremarktes ergibt sich somit für diesen am 30.3.20 gemäß der Wirtschaftsweisen je nach Szenario für 2020 sogar noch ein Plus zwischen 0,8 % und 2,5 % oder nur ein leichter Rückgang um 0,1 %.

Auch wenn diese erste Ableitung natürlich eine Vereinfachung ist, die der Komplexität des Marktes nicht annähernd gerecht wird, halten wir sie doch für nicht ganz unrealistisch. Denn einerseits wird der Druck zur Digitalisierung an vielen Stellen durch die aktuelle Krise sogar noch steigen, kommt doch beispielsweise der Onlinehandel der aktuell erhöhten Nachfrage nicht hinterher. Und andererseits kann gerade in der IT viel Arbeit unabhängig vom Ort, also beispielsweise auch von daheim aus erfolgen. Die aktuellen Ausgangsbeschränkungen werden hier, anders als in anderen Branchen, somit auch nur geringere wirtschaftliche Auswirkungen zur Folge haben. Deutsche Unternehmen, die sich dem Thema Homeoffice gegenüber bisher eher verschlossen haben, sehen jetzt die Vorteile flexiblerer Arbeitsformen, wie zum Beispiel eine höhere Produktivität und geringere Arbeitsplatzkosten, aber auch eine geringere Umweltbelastung durch weniger Fahrten, etc. Sollte Deutschland diesbezüglich nun beispielsweise zu Skandinavien mit seiner Home Office Quote von 28 % aufschließen, könnte die Krise auch etwas Gutes haben.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Effizienz oder Effektivität? Wenn die Softwareentwicklung optimiert werden soll, wird häufig an der falschen Stelle angesetzt. Die Lösung liegt mit Blick auf zwei Studien und unter Anwendung des Pareto-Prinzips auf der Hand. Die Produktivität der Softwareentwicklung kann so um das bis zu Fünffache gesteigert werden – allerdings nicht durch schnelleres Tippen …

Inhalt:

• Einleitung
• Effizienz – wie entwickelt wird
  – Multitasking
• Effektivität – was entwickelt wird
  – Lösungsansätze
• Fazit

Einleitung

Die Softwarekrise ist auch rund 50 Jahre nach ihrer offiziellen Feststellung noch nicht überstanden. Jede Softwareentwicklungseinheit steht vor der Herausforderung, dass es mehr Bedarf beziehungsweise Anforderungen als Entwicklungskapazität gibt. Um dem entgegenzuwirken, liegt der Fokus von entsprechenden Optimierungsversuchen häufig auf Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen. Salopp gesagt, wird versucht, durch “schnelleres Tippen” mehr Software in kürzerer Zeit entwickelt zu bekommen.

Dies funktioniert aus verschiedenen Gründen nicht. Einerseits wird bei Effizienzsteigerungsversuchen häufig an der falschen Stelle angesetzt und der echte Hebel in der Softwareentwicklung, die Effektivität, wird andererseits viel zu selten betrachtet.

Effizienz – wie entwickelt wird

Softwareentwicklung ist zu einem hohen Anteil eine geistig-kreative Tätigkeit. Natürlich muss auch ein Schriftsteller zügig schreiben können, der Fertigstellungstermin eines Romans ist aber nur zu einem geringen Anteil von der reinen Schreibgeschwindigkeit des Schriftstellers abhängig. Gleiches gilt für die Softwareentwicklung. Es gibt zwar noch wenige Studien hierzu, die bestätigen allerdings unsere Projekterfahrung. Demnach umfasst ein Großteil der gesamten Entwicklungszeit für eine einzelne Software-Funktion Wartezeit und nur ein geringer Anteil ist Arbeits- beziehungsweise eben “echte” Entwicklungszeit:

© Darstellung: Schwarze Consulting GmbH – © Daten: Kanban University: https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Die sogenannte Flow Efficiency, also die Dauer für die Entwicklung einer Funktion geteilt durch die reine Arbeitszeit, beträgt üblicherweise 15 %; Organisationen, die sich noch gar nicht mit dem Thema befasst haben, liegen häufig bei nur 1-2 % und am anderen Ende gibt es wenige Entwicklungseinheiten, die auf eine Flow Efficiency von bis zu 40 % kommen. Der Normalverteilung folgend, darf man hier aber guten Gewissens erstmal die üblichen 15 % ansetzen.

Der ABC-Analyse oder auch dem Pareto-Prinzip folgend, sollte man sich bei einer Wartezeit von 85 % natürlich zunächst um diesen großen Hebel kümmern. Bei entsprechenden Produktivitäts- beziehungsweise Effizienzsteigerungsmaßnahmen der Softwareentwicklung wird er aber unserer Erfahrung nach nahezu kategorisch ignoriert. Vermutlich weil die Wartezeiten schwerer zu greifen sind, als die eigentliche Arbeitsleistung. Dabei sind sie auch einer der Gründe, warum die Umsetzungsdauer von Entwicklungsvorhaben schwer zu schätzen ist, beziehungsweise entsprechende Schätzungen häufig daneben liegen: Wartezeiten sind kaum vorhersehbar, geschweige denn solide abschätzbar. Was ich zu entwickeln habe, kann ich als Entwickler sicherlich sehr gut mit etwas Erfahrung einschätzen. Aber wann ich wie lange auf was oder wen dabei zu warten habe, ist nicht deterministisch.

Selbst wenn man mit viel Aufwand die Entwicklungsgeschwindigkeit um 50 % erhöht bekäme, so hat man auf die übliche Flow Efficiency doch dann gerade mal 7,5 % an Umsetzungsdauer gewonnen1. Die Fertigstellung einer einzelnen Funktion wird durch “schnelleres Tippen” des Entwicklers also nur unwesentlich beschleunigt.

Und wenn man ehrlich ist, so wird in vielen Organisationen durch eine Vielzahl von Hürden für den Entwickler die Entwicklungsgeschwindigkeit sogar eher noch mutwillig reduziert. Als Beispiele seien hier die Team-übergreifend einheitlich zu verwendende IDE zu nennen, die den einzelnen Entwickler eher verlangsamt. Oder Internet-Proxys, die einen daran hindern, notwendige Entwicklungsbibliotheken zu beziehen, nicht vorhandene Admin-Rechte auf dem Entwicklungsrechner, quälende langsame Test-Suiten, für die niemand Zeit zum Aufräumen bekommt, und so weiter.

Nicht, dass das falsch verstanden wird. Es ist extrem wichtig, in die Entwicklungseffizienz durch vernünftiges Tooling, individuelle IDEs und schnelle Feedback-Zyklen zu investieren, um einem Entwickler eine optimale Arbeitsumgebung zur Verfügung stellen zu können und so insbesondere die Entwicklungsqualität zu erhöhen. Die Umsetzungsdauer eines Features wird dies aber, wie gezeigt, nicht signifikant reduzieren.

Multitasking

Ein Entwickler wechselt bei entsprechender Wartezeit natürlich zu einer anderen Aufgabe, zum Beispiel der Entwicklung eines zweiten Features:

© Schwarze Consulting GmbH

Dieses Task-Switching ist aber sowohl grundsätzlich als auch bei Entwicklungstätigkeiten im Besonderen ein Produktivitäts- und Qualitäts-Killer. Jeder, der schon mal versucht hat, eine Aufgabe zu erledigen, die eine gewisse Konzentration erfordert und dabei permanent unterbrochen wurde, sollte das leicht nachvollziehen können. Und bis ein Entwickler das mentale Modell einer umfangreichen Codebasis “in den Kopf geladen” hat, können auch schon mal Stunden vergehen, bevor eine Zeile verändert wird. Blöd, wenn er dann kurz vorher gestört wird. Es ist also extrem wichtig, ein Arbeitsumfeld für Entwickler zu schaffen, in dem sie durchaus mehrere Stunden ungestört sind.

Sind dann mehrere Entwicklungsaufgaben parallel in Bearbeitung, um die Wartezeit zu optimieren, kommt es häufig zu Situationen, in denen der Entwickler eigentlich an beiden Features gleichzeitig arbeiten müsste, was natürlich nicht geht. Somit entsteht an einer Stelle eine zusätzliche Wartezeit (⚠️) und die Umsetzungsdauer erhöht sich entweder beim einen (Entwicklungsdauer Feature 1 = 100 % + x) oder beim anderen Feature (Entwicklungsdauer Feature 2 = 100 % + y) entsprechend. Die Umsetzungdauer jedes einzelnen Features, welches parallel zu anderen entwickelt wird, verlängert sich durch Multitasking also.

Untersuchungen zeigen, dass ein Entwickler trotz dieser Task-Wechsel aber auch nur 25-50 % seiner Zeit pro Tag mit reinen Entwicklungstätigkeiten verbringt. Unter Annahme der üblichen Flow Efficiency von 15 % schafft ein Entwickler es also, an 2 bis 3 Features parallel zu entwickeln; mit entsprechenden Zeit- und Qualitätseinbußen. Also liegt auch unter Einsatz von Multitasking das angenommene Effizienzpotential durch “schnelleres Tippen” bei nur 18,75 % 2 und somit immer noch unter der Pareto-Schwelle.

Effizienz in der Softwareentwicklung ist also nicht der Heilsbringer, da ihr Hebel gering ist und ihre Optimierung, beispielsweise durch Multitasking auch negative Auswirkungen mit sich bringt.

Effektivität – was entwickelt wird

Die Effektivität, also die Frage, was beziehungsweise ob das Richtige entwickelt wird, ist bei der Optimierung von Softwareentwicklungsvorhaben unserer Erfahrung nach häufig nur von nachrangiger Bedeutung. Dabei werden nur 20 % der Anforderungen wirklich benötigt:

© Darstellung: Schwarze Consulting GmbH – © Daten: Universität Karlsruhe: https://ps.ipd.kit.edu/downloads/za_2007_schlanke_produktionsweisen_moderne_softwareentwicklung.pdf

Auch hier springt einen die ABC-Analyse oder das Pareto-Prinzip wieder geradezu an. Durch die richtige Auswahl dessen, was entwickelt wird, also über die Effektivität, lässt sich die Softwareentwicklung offensichtlich wesentlich leichter verbessern als über die Effizienz: der Hebel ist hier mit 80 % beim “Was” entwickelt wird viel höher als die oben weiter genannten 15 % beim “Wie”.

Zugegebenermaßen etwas polemisch formuliert, müsste eine Entwicklungseinheit, da bei 20% ja nur jedes fünfte umgesetzte Feature auch wirklich zum Einsatz kommt, kalkulatorisch auch “einfach” nur fünf Mal so groß sein, um die fehlende Effektivität zu kompensieren. Wir sind mit dem Vorschlag leider noch bei keinem Budgetverantwortlichen durch gekommen …

Bei Umsetzungen im Kundenauftrag ließe sich natürlich argumentieren, dass der Kunde doch alle Anforderungen bezahlt und damit doch wohl auch alle Anforderungen benötigt werden. Doch auch hier ist der Bedarf meist größer als die Entwicklungskapazität oder das Entwicklungsbudget. Und auch in diesem Fall stellt der Auftraggeber früher oder später fest, dass das eine oder andere Feature vielleicht doch nicht oder zumindest nicht so gebraucht wird, weshalb man auch hier drauf achten sollte, was entwickelt wird.

Weniger ist in der Softwareentwicklung also wirklich mehr, auch wenn es zunächst abwegig erscheint und abgedroschen klingen mag. Optimierungsversuche sollten hier also immer zuerst auf die Effektivität abzielen.

Lösungsansätze

Wie kann ich aber nun die Effektivität meiner Softwareentwicklung erhöhen, also dafür sorgen, dass möglichst viel von dem umgesetzt wird, was auch wirklich benötigt wird und möglichst wenig von dem, was nicht wirklich benötigt wird?

Wir erleben immer wieder Product-Backlogs, die voll von uralten Features sind. Wissend, dass 80 % davon nicht wirklich gebraucht werden, kann man also guten Gewissens davon ausgehen, dass die wichtigen Features schon umgesetzt wurden und die, die eine gewisse Zeit lang nicht zur Umsetzung kamen, auch nicht mehr gebraucht werden. Trotzdem müssen diese Features dann häufig umgesetzt werden, wodurch knappe Entwicklungskapazität unnötig gebunden wird. Effektive Softwareentwicklung ist keine “Supermarktkasse”, wo jeder früher oder später dran kommt. Um effektiver zu werden, müssen die Anforderungen sich jeden Tag aufs Neue hinsichtlich ihrer Priorität beweisen; Anforderungen, die nicht wichtig genug sind, sollten auch nicht “dran kommen”, wenn man mehr (des Richtigen) aus der Entwicklung bekommen möchte.

Anders herum erleben wir auch immer wieder, dass die Priorisierung von Features darüber erfolgt, welcher Anforderer “am lautesten schreit”. Wenn 80 % der Features aber nicht benötigt werden, wird so wiederum wertvolle, da knappe Entwicklungskapazität für unnötige Themen verschwendet, weil der, der am lautesten schreit, noch lange nicht der wichtigste Anforderer ist. Gibt man denen nach, entsteht natürlich der Eindruck, dass aus einer Entwicklungseinheit nicht genug heraus kommt, da eben nicht genug des Richtigen heraus kommt. So lange die Entwicklungseinheit sich selbst die Aufgaben priorisiert, wird sie immer Teil des Problems sein. In diesem Fall ist es genau wie an einer Supermarktkasse: Wenn ich vorgelassen werden möchte, kann das nicht der Mitarbeiter an der Kasse, also die Entwicklungseinheit entscheiden, sondern ich muss der Reihe nach alle vor mir Stehenden fragen beziehungsweise davon überzeugen, dass mein Anliegen dringender ist.

Wichtig ist in solchen Fällen, dass die üblicherweise vielen verschiedenen Stakeholder der Softwareentwicklung das Problem unter sich lösen. Hierzu haben wir schon erfolgreich unterschiedliche Ansätze, üblicherweise Gremien-orientiert in verschiedenen Organisationen implementiert. Alternativ wird es durch einen entsprechend “starken” Product Owner erledigt:

© Scrum.Org: https://www.scrum.org/resources/blog/evolution-product-owner

Die Rolle des Product Owners ist zwar mittlerweile in vielen Organisationen, die sich mit Softwareentwicklung beschäftigen, besetzt. Unserer Erfahrung nach aber noch eher selten im Sinne eines »Unternehmers im Unternehmen« (“Entrepreneur”), der auch alleine und vollumfänglich über die Roadmap und Features “seines” Produktes entscheiden kann. Dabei ist eine seiner Hauptaufgaben, “Nein” zu den meisten Anforderungen zu sagen und das Entwicklungsteam so effektiv und produktiv entwickeln zu lasssen. Alle anderen der oben gezeigten Ausprägungen der Rolle Product Owner werden üblicherweise einen konsens-orientierten Ansatz mit ihren Stakeholdern zur Priorisierung finden müssen. Wobei auch einem “starken” Product Owner dieser Weg durchaus angeraten sein kann.

Fazit

Eine effiziente Softwareentwicklung ist heutzutage ein Hygienefaktor. Über die Effizienz lässt sich die Produktivität in der Entwicklung, wie wir gezeigt haben, mit unter 20 % auch nur begrenzt steigern. Wenn das Thema Effizienz in der Softwareentwicklung angegangen wird, empfehlen wir, Wartezeiten zu reduzieren, da diese üblicherweise den Großteil der Entwicklungszeit eines Features ausmachen.

Wer wirklich mehr aus seiner Softwareentwicklungseinheit heraus bekommen möchte, sollte tatsächlich weniger entwicklen, nämlich weniger der nicht benötigten Features. Über die Effektivität lässt sich die Produktivität in der Entwicklung um das bis zu Fünffache steigern! Dann ist auch wieder ausreichend Kapazität für die wichtigen Features vorhanden. Hierzu wird jemand in verantwortlicher Position gebraucht, der “Nein” sagen kann – beispielsweise ein entsprechend “starker”, also befähigter und ermächtigter Product Owner.

Fussnoten:

1. 15 % normale Flow Efficiency beziehungsweise Entwicklungszeit * 50 % angenommene Optimierung = 7,5 % optimierte Entwicklungszeit und somit Reduktion der gesamten Umsetzungsdauer. 
2. Der Mittelwert der Zeit, die ein Entwickler pro Tag mit reiner Entwicklung verbringt von 25-50 % ist 37,5 %. Die Annahme im voran gegangenen Beispiel bei der Entwicklung eines Features war, dass 50 % der reinen Entwicklungszeit optimierbar wären. Bei Multitasking somit also 50 % von 37,5 % = 18,75 %. 

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Unser Blogbeitrag »Die Wachstumsrate von Software« wurde als Fachartikel in der Fachzeitschrift OBJEKTspektrum veröffentlicht.

Die Fachzeitschrift OBJEKTspektrum »liefert zuverlässige Hintergründe, Trends und Erfahrungen zu Software-Management, -Architektur und -Engineering«. Unser Blogbeitrag »Die Wachstumsrate von Software« fand Anklang bei der Redaktion der OBJEKTspektrum und wurde in einer erweiterten Fassung in Ausgabe 1/2019 veröffentlicht.

Interessierte können sich den ganzen Artikel hier herunterladen.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

• Rund 120.000 Online-Shops in Deutschland.
• Mindestens 6 Mio. Umsatz sind notwendig, um zu den Top-1000-Online-Shops zu gehören.
• Wachstum erfolgt nur noch unter den ersten 500 Online-Shops beziehungsweise ab 10 Mio. € Umsatz.
• Die Top-100 Online-Shops vereinen mit 30 Mrd. € bereits ¾ des Gesamtumsatzes auf sich.
• Rund 55 % der Top-1000 setzen ein Standard-Online-Shop-System ein, davon sind 5 % SAP Hybris; circa 45 % entwickeln selbst.

Inhalt:

• Allgemeines
• E-Commerce-Markt
• Shop-Systeme

Allgemeines

Dr. Roman Zenner hat in seinen ShopTechTalks #038 die Top-1000-Shops-Analyse des EHI mit dessen verantwortlichem Projektleiter besprochen. Wir haben zugehört und hier die für uns interessantesten Erkenntnisse hinsichtlich des E-Commerce-Marktes in Deutschland 2018 im Allgemeinen und Shop-Systemen im Besonderen zusammengefasst. Nicht jeder kommt vielleicht dazu, dem Podcast zu folgen oder die komplette Studie vom EHI Retail Institut zu kaufen.

Die Inhalte der Studie wurden vom EHI auf Basis von Befragungen, offiziell zugänglichen Informationen, wie zum Beispiel aus Jahresabschlüssen und Traffic-Analysen, sowie durch Ableitungen und Hochrechnungen ermittelt. Dementsprechend sind sie auch nicht immer zu 100 % zutreffend. So ist beispielsweise die Degussa Goldhandel GmbH im Hauptsegment »Hobby & Schreibwaren« geführt und die eine oder andere Umsatzangabe deckt sich auch nicht mit unseren Erfahrungen aus konkreten Kundenprojekten. Die Tendenz der Studie stimmt unseres Erachtens aber und es ist durchaus eine Leistung, die Daten in der Anzahl und Güte überhaupt konsolidiert zu bekommen.

E-Commerce-Markt

Die Studie bildet die B2C-Handelsumsätze für physische Güter ab. Dienstleistungs- und B2B-Shops sind entsprechend ausgenommen, Marktplätze ebenso. Um in der Top-1000 dabei zu sein, müssen 2018 mindestens 6 Mio. € Umsatz mit einem Online-Shop erzielt werden. Der Median liegt bei rund 10 Mio. € Umsatz, der Durchschnitt bei 43 Mio. € Umsatz. Wachstum erzielt nur noch die vordere Hälfte der Top-1000. Anders formuliert wird es also schon ab 10 Mio. € Umsatz (Median) schwierig für einen Online-Shop, Umsatzwachstum zu erzielen.

Das Gerücht, dass Wachstum nur noch für Online-Pure-player möglich ist, konnte die Studie nicht stützen. Selbige liegen diesbezüglich nahezu gleichauf zu Omni- beziehungsweise Multichannel-Anbietern. Kämpfen Letztgenannte mit rückläufigen Erlösen auf den Flächen, leiden die Online-Pure-Player unter Markplätzen und Rabattschlachten beziehungsweise Gutscheinen, da Online-Käufer zumeist nicht loyal sind. MediaMarktSaturn liegt beispielsweise als Omnichannel-Anbieter trotz Kritik an seinem Geschäftsmodell auf Platz 5.

Die Top-1000 Shops sind dabei nur die Spitze des berühmten Eisberges, da es in Deutschland vermutlich 120.000 entsprechende B2C-Onlineshops für Waren gibt. Die voran skizzierten Umsatzdaten zeigen dabei, dass es eine klare Konzentration auf wenige große Player gibt. Die Top-100, welche auszugsweise vor Kurzem kostenlos veröffentlicht wurde, bildet so mit 30 Mrd. € Umsatz bereits ¾ des Gesamtumsatzes der Top-1000 von rund 42 Mrd. € Umsatz ab.

© HighText Verlag: ibusiness.de | https://www.ibusiness.de/wrapper.cgi/www.ibusiness.de/files/iBusiness-Poster_Onlineshops_2018.pdf

Über alle Segmente hinweg taxiert die Studie den Online-Anteil derzeit auf rund 15 %. Wobei dann auch die interessante Frage gestellt wurde, wie viel online überhaupt noch geht. Im Weihnachtsgeschäft sind die Straßen der Metropolen mittlerweile derart verstopft von Paketdienstfahrzeugen, dass wir doch vermutlich schon längt an der Grenze des Machbaren der Logistik-Infrastruktur angekommen sind.

Shop-Systeme

55 % der Top-1000 Online-Shops setzen auf ein Standard-Shop-System wie Magento (14 %) oder SAP Hybris (5 %). Unter den Top-100 setzen nur noch 39 % auf einen Standard-Shop, davon 9 % auf IBM Websphere und 8 % auf SAP Hybris. Man erkennt also bei den umsatzstärkeren Online-Shops eine klare Tendenz weg vom Standard-System – beziehungsweise wenn Standard, dann eines der Systeme der großen Anbieter.

Bei den nicht identifizierbaren Systemen handelt es sich zum Großteil um Eigenentwicklungen oder Standard-Systeme, die so stark angepasst wurden, dass das Standard-System nicht mehr erkennbar war. Zum geringen Teil fallen hier auch Standard-Shop-Systeme wie Spryker oder CommerceTools drunter, die vom EHI nicht erkennbar waren.

© Darstellung: Schwarze Consulting GmbH – Daten: © EHI Retail Institute GmbH | https://www.ehi-shop.de/de/handelsthemen/e-commerce/studie-e-commerce-markt-deutschland-2018

Interessante Anekdote der Autoren am Rande: Mister Spex ist mit einer Eigenentwicklung gestartet und dann erfolgreich zu einem Standard-System (Intershop) gewechselt; üblicherweise sehen wir hier die Bewegung anders herum vom Standard-System in Richtung Eigenentwicklung.

Im Podcast wurde dann noch recht detailliert auf die Umsatzgrößen eingegangen, welche die Händler im Schnitt über die entsprechenden Shop-Systeme bewegen. Leider wurde nicht überall der Mittelwert mit angegeben. Dass der Median von Intershop vor Hybris und Eigenentwicklungen liegt, hat uns dann schon gewundert, gerade auch, da wir einige große Hybris-Installationen als auch Eigenentwicklungen im E-Commerce kennen. Der Ausreißer im Mittelwert von Webshpere wird sich wahrscheinlich schon durch das Umsatzvolumen von MediamarktSaturn, welche die Lösung von IBM als Shop-Sytem nutzen, erklären.

© Darstellung: Schwarze Consulting GmbH – Daten: © EHI Retail Institute GmbH | https://www.ehi-shop.de/de/handelsthemen/e-commerce/studie-e-commerce-markt-deutschland-2018

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn