Was Software nach dem Launch wirklich kostet

Der Moment, in dem ein Projekt als fertig gilt – und was er verschweigt

Irgendwann kommt die E-Mail: Das System ist abgenommen, die letzte Rechnung geht raus, das Projekt ist geschlossen. Für alle Beteiligten ist das ein eindeutiger Punkt. Für den Betrieb ist es der Beginn von etwas anderem.

Was „fertig" bedeutet, hängt davon ab, wer es definiert. Im Entwicklungsvertrag steht ein Leistungsumfang – und das System erfüllt ihn. Die Formulare funktionieren, die Daten werden gespeichert, die Berechnungen stimmen. Das ist korrekt, und es ist unvollständig.

Was in keinem Abnahmeprotokoll steht

Ein Softwaresystem gilt als fertig, wenn es das tut, was vereinbart wurde. Nicht mehr. Was vereinbart wurde, war eine Beschreibung von Abläufen – aber Beschreibungen von Abläufen sind Annäherungen. Sie stammen aus Gesprächen, die vor dem Bau geführt wurden, mit Menschen, die damals noch nicht wussten, wie sich das System in der Praxis anfühlen würde.

Der Handwerker, der morgens die Aufträge eingibt, hat das nicht mitentwickelt. Die Verwalterin, die am Monatsende die Auswertung braucht, war in keinem Meeting. Der Außendienstmitarbeiter, der unterwegs auf sein Telefon angewiesen ist, hat kein Pflichtenheft gesehen.

Sie arbeiten jetzt mit dem, was fertig ist.

Die Lücke zwischen Abnahme und Alltag

Diese Lücke ist nicht das Ergebnis schlechter Planung. Sie ist das Ergebnis eines grundlegenden Problems: Anforderungen entstehen vor dem System, aber das Wissen darüber, was tatsächlich gebraucht wird, entsteht erst durch die Arbeit mit dem System.

Ein Unternehmen, das eine Buchungslösung einführt, stellt oft erst nach einigen Wochen fest, dass bestimmte Ausnahmen im Tagesgeschäft häufiger vorkommen als angenommen. Eine Firma, die ihren Rechnungseingang digitalisiert, entdeckt, dass ein Teil der Lieferanten Formate verwendet, die nicht abgedeckt sind. Das ist keine Fehlleistung. Das ist der normale Abstand zwischen Planung und Wirklichkeit.

• Abläufe, die sich nach der Einführung verändern – weil Mitarbeitende das System anders nutzen als erwartet
• Anforderungen, die erst sichtbar werden, wenn der erste echte Fehlerfall eintritt
• Auswertungen, die jemand braucht, die aber in keinem Gespräch vorkamen
• Oberflächen, die technisch korrekt sind, aber in der täglichen Arbeit Zeit kosten

Keiner dieser Punkte macht das System schlecht. Sie machen „fertig" zu einem vorläufigen Urteil.

Das Projekt schließt – und gleichzeitig öffnet sich die Liste dessen, was als Nächstes geändert werden soll. Diese Liste existiert in jedem Unternehmen, das mit eigener Software arbeitet. Sie wächst mit dem Betrieb. Der Unterschied liegt nicht darin, ob sie entsteht. Er liegt darin, was die nächste Änderung tatsächlich kostet.

Was sich verändert, sobald echte Nutzer mit dem System arbeiten

In der Testphase arbeiten meistens dieselben drei Personen mit dem System, die es auch bestellt haben. Sie kennen den Hintergrund, sie wissen, was gemeint war, und sie füllen Lücken mit diesem Wissen. Das ist kein Testen — das ist Bestätigen.

Wenn das System dann breiter eingesetzt wird, beginnt etwas anderes. Kolleginnen und Kollegen, die an der Konzeption nicht beteiligt waren, bringen ihre eigene Logik mit. Sie nennen Dinge anders. Sie erwarten, dass bestimmte Schritte in einer anderen Reihenfolge möglich sind. Sie klicken dort, wo kein Button ist, weil es für sie der naheliegende Weg wäre.

Workarounds entstehen schnell und still

Was dann passiert, ist selten dramatisch — es ist leise. Jemand führt eine eigene Tabelle nebenher, weil das System eine bestimmte Auswertung nicht liefert. Jemand anderes verschickt Ergebnisse per E-Mail weiter, weil die Exportfunktion nicht das Format produziert, das der Empfänger braucht. Ein dritter Weg entsteht, ohne dass ihn jemand beschlossen hat.

Diese Umgehungslösungen sind nicht das Problem. Sie sind das Symptom. Sie zeigen, wo das System und der tatsächliche Arbeitsablauf auseinandergehen — an Stellen, die im Gespräch vor dem Bau nie aufgetaucht sind, weil niemand ahnte, dass sie relevant werden könnten.

Der Unterschied zwischen geplantem und tatsächlichem Gebrauch

Ein Buchungssystem wurde für Einzeltermine gebaut. Im dritten Monat stellt sich heraus, dass ein erheblicher Teil der Buchungen immer wiederkehrende Termine betrifft. Die Nutzerinnen und Nutzer lösen das, indem sie jeden Termin einzeln anlegen. Das funktioniert — aber es kostet Zeit, und es produziert Daten, die sich später schlecht auswerten lassen.

Ein Verwaltungstool wurde mit einer Suchfunktion ausgeliefert, die nach Name und Datum filtert. Wer das System täglich nutzt, sucht nach etwas anderem: nach Status, nach Zuständigkeit, nach offenen Rückmeldungen. Die vorhandene Suche hilft dabei nicht weiter.

Solche Beobachtungen landen meistens nicht als förmliche Anforderung beim Entwickler. Sie werden intern besprochen, halbwegs gelöst oder still akzeptiert. Erst wenn die Reibung groß genug wird — oder wenn jemand fragt — kommt heraus, wie weit das System vom tatsächlichen Gebrauch entfernt ist.

Das ist kein Fehler in der Planung. Es ist die normale Folge davon, dass kein Pflichtenheft vollständig abbilden kann, wie sich Arbeit in der Praxis verhält. Der Unterschied zwischen dem System, das geliefert wurde, und dem System, das gebraucht wird, zeigt sich erst, wenn beide aufeinandertreffen.

Warum jede Anpassung mehr kostet als die vorherige

Die erste Änderung nach dem Launch ist meistens die günstigste. Das liegt nicht daran, dass das Entwicklungsteam damals mehr Zeit hatte. Es liegt daran, dass das System zu diesem Zeitpunkt noch überschaubar war — wenige Abhängigkeiten, wenige Stellen, die sich gegenseitig beeinflussen.

Jede Anpassung danach verändert dieses Verhältnis. Ein neues Feld im Formular bedeutet nicht nur das Feld. Es bedeutet: Wo wird der Wert gespeichert? Welche anderen Stellen im System lesen ihn? Was passiert mit den bestehenden Einträgen, die dieses Feld noch nicht kennen? Was muss angepasst werden, damit Exporte, Auswertungen oder automatische Abläufe weiterhin stimmen?

Das ist kein Zeichen schlechter Arbeit. Es ist die normale Entwicklung eines Systems, das im Einsatz ist.

Warum Änderungen teurer werden, obwohl sie kleiner wirken

Eine Anpassung, die beim ersten Mal zwei Stunden dauerte, kann beim dritten Mal zehn Stunden dauern — nicht weil sie schwieriger ist, sondern weil das System inzwischen komplexer ist. Jede frühere Entscheidung war eine Vereinbarung: Diese Stelle im System macht das so. Andere Stellen verlassen sich darauf.

Wenn sich eine dieser Vereinbarungen ändern soll, muss zuerst verstanden werden, wo überall sie gilt. Das ist die eigentliche Arbeit — und sie ist unsichtbar. Niemand sieht sie im Angebot, niemand sieht sie in der Rechnung, und doch ist sie der größte Teil der Zeit.

• Eine Umbenennung eines Feldes kann fünf andere Stellen im System betreffen, die denselben Begriff kennen.
• Ein neuer Schritt in einem Ablauf kann bestehende Auswertungen unbrauchbar machen, weil sie auf den alten Ablauf gebaut wurden.
• Eine kleine Erweiterung kann dazu führen, dass ältere Daten im System plötzlich unvollständig wirken — nicht weil sie falsch sind, sondern weil das System jetzt mehr erwartet.

Wer das erste Mal Software in Auftrag gibt, erlebt das selten. Wer ein System zwei oder drei Jahre betreibt, erlebt es fast immer.

Die Entscheidungen von damals

Viele der Kosten, die heute entstehen, wurden vor Monaten oder Jahren festgelegt — nicht absichtlich, sondern weil jede Architekturentscheidung Folgeentscheidungen erzwingt. Wie Daten strukturiert sind, wie Prozesse abgebildet wurden, was als Ausnahme behandelt wurde und was als Regel: Das alles ist eingebaut.

Eine Software, die ursprünglich für zwanzig Nutzer gedacht war und jetzt zweihundert hat, trägt diese Herkunft in sich. Sie läuft — aber jede Änderung trifft auf Konstruktionen, die für andere Verhältnisse entworfen wurden.

Das lässt sich nicht rückgängig machen. Es lässt sich nur kennen — damit die nächste Entscheidung mit diesem Wissen getroffen wird, nicht trotz seiner Abwesenheit.

Wenn das System anfängt, selbst Arbeit zu machen

Irgendwann läuft das System, und niemand muss mehr etwas anstoßen. Anfragen kommen rein, werden kategorisiert, bekommen eine Antwort. Berichte erscheinen am Montagmorgen im Postfach. Daten wandern von einer Stelle zur nächsten, ohne dass jemand die Maus bewegt. Das ist der Moment, auf den alle hingeplant haben.

Was in diesem Moment oft übersehen wird: Die Arbeit ist nicht verschwunden. Sie hat nur die Form gewechselt. Früher hat jemand eine Aufgabe erledigt und dabei gesehen, wenn etwas nicht stimmte. Das System sieht das nicht. Es führt aus, was ihm einmal mitgegeben wurde — auch dann, wenn sich die Wirklichkeit inzwischen verändert hat.

Was automatisiert läuft, wird seltener geprüft

Ein Makler, dessen Interessentenliste sich automatisch aktualisiert, schaut seltener hin als früher, als er sie selbst gepflegt hat. Das ist rational — genau dafür wurde das System gebaut. Aber es bedeutet auch: Wenn ein Eintrag seit Wochen falsch befüllt wird, fällt das später auf. Nicht sofort.

Das gilt für jeden automatisierten Ablauf. Eine Benachrichtigung, die nicht mehr zugestellt wird. Eine Berechnung, die auf einem Wert basiert, der sich geändert hat. Ein Bericht, dessen Spalten schon lange nicht mehr das zeigen, was der Name verspricht. Niemand hat etwas falsch gemacht. Niemand hat etwas bemerkt.

Überwachung ist keine Aufgabe, die sich von selbst ergibt

Was automatisiert läuft, muss kontrolliert werden — regelmäßig, absichtlich, von jemandem, der versteht, was das System tun soll und was es tatsächlich tut. Das ist in keinem Angebot als eigene Position ausgewiesen. Es ist auch keine Aufgabe, die nach dem Go-live irgendwo sichtbar auf jemanden wartet. Sie entsteht still, und sie bleibt liegen, bis ein Fehler sie sichtbar macht.

Nicht jedes Unternehmen hat jemanden, der diese Rolle ausfüllen kann. Nicht jede Fachanwendung macht es leicht, den Unterschied zwischen „läuft" und „läuft richtig" zu erkennen. Das ist keine Kritik an der Software — es ist eine Eigenschaft automatisierter Systeme, die vor der Entscheidung bekannt sein sollte.

• Wer prüft, ob die automatisch versendeten Nachrichten noch korrekt sind?
• Wer bemerkt, wenn ein Bericht stillschweigend leer bleibt?
• Wer weiß, welche Abläufe überhaupt automatisiert laufen?

Diese Fragen haben keine technische Antwort. Sie sind organisatorisch — und sie stellen sich erst, wenn das System bereits in Betrieb ist.

Was kein Angebot ausweist – und warum das so bleibt

Ein Angebot entsteht zu einem Zeitpunkt, an dem das System noch nicht existiert. Es beschreibt, was gebaut werden soll – nicht, was danach anfällt. Dieser Unterschied ist kein Versäumnis und kein Trick. Er ist strukturell.

Wer ein Haus bauen lässt, weiß, dass Heizung und Versicherung im Bauvertrag nicht stehen. Bei Software ist dasselbe weniger selbstverständlich, weil das Produkt am Ende wie ein fertiges Ding aussieht. Es läuft, es öffnet sich, es tut, was es soll. Der Eindruck, jetzt sei es bezahlt, ist naheliegend – und meistens falsch.

Was Angebote nicht enthalten können

Bevor echte Nutzerinnen und Nutzer mit einem System arbeiten, weiß niemand, welche Fragen sie stellen werden. Welche Abläufe sich als umständlicher herausstellen als angenommen. Welche Ausnahme im dritten Monat auftaucht, die im Pflichtenheft nicht vorgesehen war, weil sie im Tagesgeschäft des Auftraggebers als Selbstverständlichkeit gilt.

Ein Angebot, das diese Fragen beantworten wollte, müsste die Zukunft kennen. Das kann es nicht. Deshalb endet es mit der Abnahme.

Was dann trotzdem kommt

• Eine gesetzliche Vorgabe ändert sich – ein Formular, eine Pflichtangabe, ein Datenschutzhinweis. Das System muss angepasst werden, ob jemand es beauftragt oder nicht.
• Der Browser eines Kunden wird aktualisiert und zeigt eine Maske anders an als zuvor. Nicht falsch, aber verwirrend genug, damit Anfragen kommen.
• Ein Datenlieferant, an den das System angebunden ist, ändert sein Format. Nichts im eigenen Code hat sich bewegt, trotzdem funktioniert die Übergabe nicht mehr.
• Das Volumen wächst. Was bei fünfzig Einträgen pro Monat reibungslos läuft, beginnt bei fünfhundert zu stocken.

Kein Angebot kann diese Ereignisse einpreisen, weil keines davon zum Zeitpunkt des Angebots feststeht. Wann ein Gesetz geändert wird, welcher Browser welche Version wann ausrollt, ob ein Drittanbieter sein Format anpasst – das sind externe Tatsachen, die unabhängig vom Projekt eintreten.

Warum das so bleibt

Es ist nicht so, dass Anbieter diese Kosten verstecken. Die meisten benennen sie – als Wartungsvertrag, als Stundensatz für spätere Arbeiten, als jährliche Pauschale. Nur fällt das im Auswahlprozess selten ins Gewicht, weil zwei Zahlen leichter zu vergleichen sind als eine Zahl und eine Unsicherheit.

Was bleibt, ist eine Lücke zwischen dem, was abgezeichnet wurde, und dem, was ein System in Betrieb tatsächlich kostet. Diese Lücke ist nicht vermeidbar. Sie ist kleiner, wenn man sie von Anfang an einplant – und größer, wenn man sie erst entdeckt, wenn die erste Rechnung nach der Abnahme kommt.