Der Preis von Software entspricht nicht den Entwicklungskosten, sondern den Kosten für Betrieb und Nutzung während der gesamten Produktionszeit. Die Entwicklung selbst ist günstig geworden; Betrieb, Fehlerbehebung, Integration und Weiterentwicklung hingegen nicht. Zwei Angebote anhand ihres Lieferbudgets zu vergleichen, ist so, als würde man zwei Gebäude nur anhand der Betonkosten vergleichen.
Diese Unterscheidung hat in den letzten achtzehn Monaten an Dringlichkeit gewonnen. Die Kosten für die Codeerstellung sind real und nachweisbar gesunken – Stanford HAI dokumentierte, dass die Inferenzkosten für ein GPT-3.5-äquivalentes System zwischen November 2022 und Oktober 2024 um mehr als das 280-Fache sanken – und damit auch die Einstiegskosten vieler Entwicklungsprojekte. Was jedoch nicht gesunken ist, sind die Kosten für die Wartung der entwickelten Systeme.
Ein Projektbudget umfasst typischerweise Analyse, Design, Entwicklung und Implementierung. Dies entspricht 30 bis 40 % der Gesamtkosten des Systems während seiner gesamten Lebensdauer. Der Rest wird später aufgeteilt und in Posten unterteilt, die fast nie im ursprünglichen Angebot enthalten sind.
Abfahrt | Was ist enthalten? | Wann erscheint es? |
Konstruktion | Analyse, Design, Entwicklung, Implementierung | Monate 1-9 |
Infrastruktur | Cloud, Speicher, Backups, Umgebungen | Vom ersten Tag an, für immer |
Korrektur | Fehler, Regressionen, Produktionsvorfälle | Ab der ersten Woche |
Evolution | Geschäftliche Veränderungen, neue Anforderungen, neue Integrationen | Kontinuierlich |
Sicherheit und Compliance | Patches, Audits, regulatorische Anpassung | Kontinuierlich, mit regulatorischen Spitzenwerten |
Abhängigkeit | Kosten, die entstehen, wenn nur ein Lieferant weiß, wie man es spielt | Es erscheint, wenn Sie etwas ändern möchten. |
Die ersten fünf Posten lassen sich schätzen. Der sechste Posten taucht in keinem Budget auf und verursacht bei seiner Realisierung die höchsten Kosten, da er nicht von Anfang an in Euro bezahlt wird, sondern durch den Verlust an Verhandlungsmacht.
Technische Schulden werden üblicherweise als ingenieurwissenschaftliches Konzept erklärt, weshalb Managementausschüsse sie oft ignorieren, bis es zu spät ist. Finanziell betrachtet sind sie einfacher: Es handelt sich um die zusätzlichen Kosten, die jedes Mal anfallen, wenn man etwas ändern möchte – Kosten, die aus Entscheidungen resultieren, die damals getroffen wurden, um Prozesse zu beschleunigen.
Branchenschätzungen zufolge beläuft sich die Belastung durch Wartung und technologische Schulden auf rund 401 % des durchschnittlichen IT-Budgets eines Unternehmens. Dieser Wert sollte als Richtwert und nicht als geprüfter Datenpunkt betrachtet werden, da die Methoden der Studien erheblich variieren. Die Tendenz ist jedoch in allen Quellen einheitlich: Der Großteil der Technologieausgaben etablierter Unternehmen fließt nicht in neue Funktionen, sondern in die Aufrechterhaltung veralteter Systeme.
Eine weitere Information verändert die Diskussion mit einem Finanzchef: IBM schätzt, dass die Beseitigung technischer Schulden in Altsystemen den ROI von KI-Initiativen um bis zu 291.300 US-Dollar steigern kann. Anders ausgedrückt: Technische Schulden verursachen nicht nur Wartungskosten, sondern beeinträchtigen auch die Leistung aller darauf aufbauenden Systeme.
Und das Problem verschärft sich, anstatt sich zu verringern. GitClear dokumentierte anhand einer Analyse von 211 Millionen Codezeilen, dass die Duplikation von Codeblöcken ab 2024 sprunghaft angestiegen ist und dass der Anteil der Refactoring-Arbeit – also der Aktivitäten, die bestehende Schulden abbauen – von etwa 25,1 % der Gesamtänderungen im Jahr 2021 auf unter 10,1 % im Jahr 2024 gesunken ist. Es wird schneller kompiliert und weniger aufgeräumt.
Für die Erkennung erster Symptome ist keine formelle Prüfung erforderlich. Folgende Indikatoren treten zuerst auf:
Wenn drei oder mehr dieser Symptome auftreten, beschleunigt der Ausbau der Entwicklungskapazitäten nichts. Er erhöht lediglich die Anzahl der Personen, die auf eine Designentscheidung warten.
Beim Vergleich von Anbietern entscheiden diese vier Fragen darüber, ob jemand eine Einzellieferung verkauft oder ein System. Keine der Fragen ist technischer Natur; alle betreffen den Vertrag.
Wessen Code ist das? Wenn die Antwort Nuancen, Lizenzen oder den «Zugriff auf das Repository» beinhaltet, lautet die Antwort: Nein, es gehört Ihnen nicht. Das Eigentum an Code, Dokumentation und geistigem Eigentum muss vertraglich übertragen werden. Ohne dies ist jedes Angebot vorläufig, da der Anbieter uneingeschränkten Einfluss auf den Preis Ihrer Transaktion hat.
Was passiert, wenn ich morgen den Anbieter wechseln möchte? Die hilfreiche Antwort lautet nicht «Das werden Sie nicht». Sie lautet vielmehr: Es existiert eine Architekturdokumentation, Module legen versionierte Verträge offen, es gibt separate Umgebungen, und jedes kompetente Team kann innerhalb eines angemessenen Zeitraums übernehmen. Wenn für diesen Übergang jemand vom ursprünglichen Anbieter «erklären muss, wie es funktioniert», ist das System nicht dokumentiert, sondern nur auswendig gelernt.
Wer bezahlt für die Mängel? Ein Fehler im ausgelieferten Code stellt keine Änderung des Projektumfangs dar. Er muss kostenlos behoben werden, und das muss schriftlich festgehalten werden. Bei The Cloud Group nennen wir das die „Regengarantie“, und sie ist im Vertrag verankert: Wir beheben Fehler im ausgelieferten Code – ein Leben lang. Das ist keine Großzügigkeit, sondern Konsequenz: Wer behauptet, diszipliniert zu arbeiten, muss auch die Konsequenzen tragen, wenn dem nicht so ist.
Wie hoch sind die geschätzten Betriebskosten über drei Jahre? Jeder seriöse Anbieter kann Ihnen verschiedene Infrastruktur-, Support- und Upgrade-Optionen anbieten. Diejenigen, die dies nicht können, haben es entweder nicht in Betracht gezogen oder wollen es lieber nicht.
Genau diese Fragen helfen wir zu formulieren, wenn wir als unabhängige Partei in einem Prozess auftreten. Lieferantenauswahl und Erstellung von Angebotsanfragen [interner Link], ohne als Kandidaten an der von uns ausgewerteten Ausschreibung teilzunehmen.
Das ist kein Zufall, sondern ein kausaler Zusammenhang. Entscheidungen, die die Baukosten senken, führen fast immer zu höheren Instandhaltungskosten.
Keine dieser Entscheidungen ist in einer Demo sichtbar. Sie sind alle im Gesetzentwurf für das dritte Jahr ersichtlich.
Auch der umgekehrte Fall existiert und ist messbar. Bei der Modernisierung von Altsystemen – also durch Auditierung, Refactoring und Modernisierung statt durch komplette Neuentwicklung – konnten wir die Wartungskosten um bis zu 601.300 Pfund senken. Nicht etwa, weil der neue Code Wunder wirkt, sondern weil die Wartungskosten größtenteils die Kosten der Unsicherheit darstellen: Ist das System verständlich und getestet, ist jede Änderung kein Glücksspiel mehr.
Ein häufiger Fehler des technischen Teams ist die Beantragung eines Budgets «zur Tilgung technischer Schulden». Ein solcher Antrag wird von keinem Gremium begeistert bewilligt, da er den Eindruck erweckt, man wolle etwas korrigieren, das falsch gemacht wurde.
Die Formel, die funktioniert, ist anders und ehrlich:
Das Gespräch verlagert sich von «Die Software ist schlecht gemacht» zu «Das ist der Kostenunterschied zwischen den beiden Routen». Dieses zweite Gespräch kann gewonnen werden.
Ein billiges Angebot, das keine Codeverantwortung, Dokumentation, Tests oder Integrationsverträge beinhaltet, ist kein billiges Angebot: Es ist ein Darlehen mit einem Zinssatz, den Sie erst später entdecken werden.
Die wichtigste Frage bei Ihrer nächsten Software-Kaufentscheidung ist nicht, wie viel die Entwicklung kostet. Vielmehr sollten Sie sich fragen, wie viel der Besitz kostet, wem die Software gehört und was passiert, wenn Sie Ihre Meinung ändern möchten.
Es handelt sich um die Summe aller Kosten, die mit einem System während seiner gesamten Lebensdauer verbunden sind: Bau, Infrastruktur, Fehlerbehebung, Funktionsentwicklung, Sicherheit und Compliance sowie die Kosten der Abhängigkeit von einem einzigen Anbieter. Das Baubudget beträgt typischerweise nur zwischen 301 % und 401 % der Gesamtkosten.
Branchenschätzungen gehen von rund 401 % des IT-Budgets aus, wobei die Zahl je nach Studienmethodik variiert. Der Trend ist eindeutig: In etablierten Unternehmen fließt der Großteil der Technologieausgaben in die Aufrechterhaltung bestehender Entscheidungen, anstatt neue Kompetenzen aufzubauen.
Die Schätzung geht von einer Nutzungsdauer von mindestens drei Jahren aus und umfasst sechs Punkte: Bau, Infrastruktur und Umgebung, Mängelbehebung, Funktionsentwicklung, Sicherheit und Einhaltung gesetzlicher Vorschriften sowie Kosten für den Ausstieg oder Lieferantenwechsel. Ein seriöser Anbieter kann Ihnen für die ersten fünf Punkte eine realistische Preisspanne nennen.
Denn die Entscheidungen, die die Baukosten senken – auf die Planung verzichten, keine Tests durchführen, nicht dokumentieren, Mängel notdürftig beheben – sind genau die, die die Kosten jeder nachfolgenden Änderung erhöhen. Die Einsparungen konzentrieren sich auf das erste Quartal, die zusätzlichen Kosten verteilen sich auf die folgenden Jahre.
Vier Dinge: Eigentum an Code, Dokumentation und geistigem Eigentum; versionierte und dokumentierte Integrationsverträge; kostenlose Fehlerbehebung; und ein Übergangsplan, der es einem anderen Team ermöglicht, die Aufgabe zu übernehmen, ohne auf den ursprünglichen Anbieter angewiesen zu sein.
In den meisten Fällen ja, vorausgesetzt, es liegt eine vorherige Diagnose vor. Die Prüfung, Refaktorisierung und Modernisierung nach Domäne ermöglicht eine signifikante Reduzierung der Wartungskosten – bis zu 601.030.000 in von uns durchgeführten Projekten – bei gleichzeitigem laufenden Betrieb, was eine vollständige Neuentwicklung nicht ermöglicht.
Wissen Sie, wie viel Ihre Software Sie in drei Jahren kosten wird? Unser technisches Audit liefert Ihnen einen schriftlichen Bericht über den Zustand Ihrer Architektur, Ihres Codes, Ihrer Altlasten und Ihrer Sicherheit – zum Festpreis und innerhalb von 10 Werktagen. Es ist die kostengünstigste Methode, um teure Probleme aufzudecken. Fordern Sie Ihr Audit an → |