Die eigentlichen Kosten von Software entstehen nach dem Go-live.

Wenn Sie drei Angebote für ein Softwarevorhaben vergleichen, vergleichen Sie fast immer dieselbe Zahl: den Preis für die Erstentwicklung. Diese Zahl steht ganz vorne, sie ist gut vergleichbar, und sie entscheidet in der Praxis die meisten Vergaben.

Sie ist auch der kleinere Teil dessen, was Sie am Ende bezahlen.

Über die Lebensdauer eines Geschäftssystems entfällt nur ein Bruchteil der Gesamtkosten auf die erste Fassung. Der weitaus größere Teil entsteht in den Jahren danach — durch Wartung, Sicherheit, Anpassung an geänderte Anforderungen, Infrastruktur, Migration und den Aufwand, das Wissen über das System am Leben zu halten. Genaue Prozentwerte kursieren viele; wir nennen hier bewusst keinen, weil wir keinen belegen können. [QUELLE ERGÄNZEN: belastbare Untersuchung zum Verhältnis Erstentwicklung zu Betriebskosten, sonst qualitativ belassen.]

Uns interessiert ohnehin weniger die Prozentzahl als die Frage, warum diese Kosten im Entscheidungsmoment unsichtbar sind — und was man dagegen tun kann.

Warum die Betriebskosten im Angebot fehlen

Es gibt dafür drei Gründe, und keiner davon ist Böswilligkeit.

Erstens: Der Anbieter kennt sie oft selbst nicht. Wer Systeme baut und übergibt, erfährt nie, was Jahr sechs kostet. Diese Rückmeldung erreicht ihn nicht. Er hat ehrliche Angebote geschrieben und trotzdem keine Erfahrungsbasis für die Frage.

Zweitens: Betriebskosten sind schwer vergleichbar und deshalb im Wettbewerb ein Nachteil. Ein Anbieter, der eine realistische Zehnjahresrechnung aufmacht, sieht neben einem, der es nicht tut, teurer aus. Die Marktlogik bestraft Ehrlichkeit an dieser Stelle.

Drittens: Auf Auftraggeberseite entscheidet häufig ein Investitionsbudget, kein Betriebsbudget. Die Erstentwicklung wird als Projekt genehmigt, der Betrieb muss später jedes Jahr neu erkämpft werden. Damit ist strukturell garantiert, dass der Betrieb unterfinanziert startet.

Das Ergebnis kennt fast jedes Unternehmen: Nach dem Go-live läuft das System eine Weile gut. Dann kommen die ersten Änderungswünsche, für die niemand ein Budget hat. Dann bleibt eine Aktualisierung liegen, weil sie keinen sichtbaren Nutzen bringt. Dann noch eine. Vier Jahre später steht die Frage im Raum, ob man nicht besser alles neu macht — und die Antwort ist teuer.

Was nach dem Go-live tatsächlich anfällt

Wir betreiben seit 2012 unser eigenes Produkt LingoHub. Das heißt: Wir haben nie ein System übergeben und weitergezogen, sondern jede Entscheidung, die wir getroffen haben, über Jahre selbst bezahlt. Daraus ergibt sich eine ziemlich konkrete Liste dessen, was in einem laufenden System Geld kostet.

Abhängigkeiten aktuell halten. Jedes moderne System besteht zu einem erheblichen Teil aus fremdem Code — Bibliotheken, Frameworks, Laufzeitumgebungen. Dieser Code wird laufend aktualisiert, teils aus Sicherheitsgründen. Das ist kein Projekt, sondern ein Dauerzustand. Wer ihn ein Jahr aussetzt, bezahlt ihn im Folgejahr mit Zinsen, weil dann mehrere Hauptversionen gleichzeitig zu überspringen sind.

Hauptversionswechsel. Alle paar Jahre erreicht eine Framework- oder Datenbankversion das Ende ihres Supports. Dieser Wechsel ist unvermeidbar, er bringt fachlich keinen einzigen neuen Anwendungsfall, und er kostet trotzdem echten Aufwand. Wir haben das seit 2012 mehrfach durchlaufen — jedes Mal im laufenden Betrieb, ohne dass Kunden etwas davon merken sollten.

Infrastruktur. Serverkosten, Datenhaltung, Datensicherung, Ausfallsicherheit. Diese Posten sind planbar, aber sie sind nicht konstant: Sie wachsen mit der Datenmenge, und Datenmengen wachsen fast immer schneller als angenommen. Eine Kalkulation, die den Infrastrukturpreis vom Starttag über zehn Jahre fortschreibt, ist falsch.

Monitoring und Bereitschaft. Damit jemand weiß, dass etwas nicht stimmt, bevor die Anwender anrufen, braucht es Werkzeuge, definierte Reaktionszeiten und Menschen, die im Ernstfall erreichbar sind. Das ist ein eigener Kostenblock und in den meisten Erstangeboten überhaupt nicht enthalten.

Regulatorische Änderungen. Die DSGVO kam nicht als Projekt, sondern als Dauerzustand. Barrierefreiheitsanforderungen, Meldepflichten, branchenspezifische Vorgaben — solche Änderungen sind nicht verhandelbar und treffen ein System unabhängig davon, ob gerade Budget da ist.

Fachliche Weiterentwicklung. Sobald ein System genutzt wird, entstehen Anforderungen. Das ist ein Zeichen dafür, dass es funktioniert. Ein System, an dem nach drei Jahren niemand mehr etwas ändern will, ist meistens eines, das niemand mehr benutzt.

Wissenserhalt. Der teuerste Betriebsposten ist der, den niemand als Posten führt: dass Menschen das System verstehen. Wenn die einzige Person, die den Zahlungsabgleich kennt, das Unternehmen verlässt, ist das eine unbezahlte Rechnung, die irgendwann fällig wird.

Technische Schuld ist Zinseszins, nicht Kredit

Der Begriff technische Schuld wird oft als Kredit erklärt: Man nimmt eine Abkürzung und zahlt sie später zurück. Nach unserer Erfahrung ist das zu freundlich formuliert. Eine Abkürzung wirkt nicht linear, sondern multiplikativ, weil jede spätere Änderung durch dieselbe Stelle muss.

Ein Beispiel aus dem eigenen Betrieb, ohne erfundene Zahlen: Wir hatten eine Stelle im System, an der eine Abkürzung genommen wurde, weil ein Termin drückte. Sie funktionierte. Sie funktionierte auch drei Jahre später noch. Was sie tat, war, jede neue Anforderung in diesem Bereich um ein Vielfaches zu verteuern, weil man vor jeder Änderung erst die Abkürzung verstehen und absichern musste. Der Aufräumaufwand war am Ende ein Vielfaches dessen, was die saubere Umsetzung ursprünglich gekostet hätte.

Genau deshalb ist bei uns in jedem Betriebsvertrag ein fester Anteil jedes Zyklus für Struktur, Tests und Aufräumarbeit vorgesehen. Nicht aus handwerklichem Idealismus, sondern weil wir die Alternative bezahlt haben. Ein Betriebsvertrag ohne diesen Anteil wird jedes Jahr teurer, bis Weiterentwicklung wirtschaftlich nicht mehr darstellbar ist. Das ist der Mechanismus, der Systeme in die Neuentwicklung treibt — und die Neuentwicklung ist fast immer die teuerste aller Varianten.

Wie Sie Betriebskosten kalkulieren, bevor Sie unterschreiben

Sie brauchen dafür keine Fachabteilung. Sie brauchen fünf Fragen, die Sie jedem Anbieter stellen, und die Bereitschaft, die Antworten schriftlich zu verlangen.

1. Welche Technologien schlagen Sie vor, und wie lange werden diese Versionen noch unterstützt? Ein Anbieter, der darauf keine Antwort hat, hat über den Zeitraum nach dem Go-live nicht nachgedacht. Fragen Sie nach, wie viele Entwicklerinnen und Entwickler es für diesen Stack in Österreich gibt.

2. Was kostet der Betrieb im ersten vollen Jahr nach dem Go-live — als eigene Zahl? Infrastruktur, Wartung, Bereitschaft, ein Rahmen für Änderungen. Wenn diese Zahl nicht kommt, ist das die Antwort.

3. Wer kann das System außer Ihnen weiterentwickeln? Sie müssen den Anbieter nicht wechseln. Sie müssen es können. Verlangen Sie Repository-Zugang ab Tag eins, Dokumentation als Liefergegenstand und eine vollständige Rechteübertragung am Code.

4. Welcher Anteil des laufenden Aufwands geht in Struktur und Aufräumarbeit? Wenn die Antwort null lautet, ist das kein Sparpotenzial, sondern eine Stundung.

5. Was passiert bei einer Störung um 22 Uhr? Lassen Sie sich Reaktionszeit, Erreichbarkeit und Eskalationsweg beschreiben. Nicht als Vertragsformel, sondern als Ablauf.

Wenn Sie diese fünf Antworten von drei Anbietern nebeneinanderlegen, ist der Vergleich ein anderer als der reine Preisvergleich. Er ist auch der ehrlichere.

Die unbequeme Konsequenz

Eine Zehnjahresrechnung führt oft zu einem anderen Ergebnis als eine Projektkalkulation. Manchmal spricht sie dafür, weniger zu bauen. Manchmal dafür, ein bestehendes System schrittweise zu modernisieren, statt es zu ersetzen. Manchmal dafür, gar keine Individualsoftware zu bauen, weil Standardsoftware den Prozess ausreichend abbildet und der Betrieb bei jemand anderem liegt.

Wir sagen das auch dann, wenn es uns einen Auftrag kostet. Ein Vorhaben, das im Jahr vier unbezahlbar wird, ist für beide Seiten ein schlechtes Geschäft — für Sie sofort, für uns spätestens, wenn Sie es jemand anderem übergeben.

Wenn Sie ein bestehendes System haben, dessen Betriebskosten Sie nicht kennen: Genau dafür gibt es unsere Leistung Betrieb und Weiterentwicklung. Wir übernehmen auch Systeme, die wir nicht selbst gebaut haben — der Einstieg läuft über einen technischen Kurzcheck, nach dem beide Seiten wissen, worauf sie sich einlassen.

Und wenn Sie wissen wollen, woher diese Haltung kommt: Sie kommt daraus, dass wir seit 2012 unser eigenes Produkt betreiben und für jede Abkürzung selbst bezahlt haben.