Wenn eine kleine Änderung so viel kostet wie ein Neubau

Die Anfrage, die nach einem Nachmittag klingt

Der Anruf beginnt immer ähnlich. Man hat eine Idee notiert, einen Wunsch, der beim letzten Kundengespräch aufgekommen ist oder der sich in der eigenen Arbeit als Lücke zeigte. Die Formulierung klingt in sich schlüssig: „Wir bräuchten da noch ein Feld." Oder: „Könnten Sie das Datum auch im Bericht anzeigen?" Oder: „Wenn jemand den Status ändert, sollte das eigentlich auch dort sichtbar sein."

Das sind keine unvernünftigen Wünsche. Sie entstehen aus echten Situationen: aus einem Kunden, der nach einer Information fragt, die das System zwar kennt, aber an der falschen Stelle zeigt. Aus einem Kollegen, der sich eine Tabelle aus zwei Fenstern zusammenkopiert, weil die Ansicht beide nicht gleichzeitig zeigt. Aus dem Montag, an dem jemand festgestellt hat, dass eine Zahl nicht stimmte – und niemand mehr sagen kann, wo sie ursprünglich eingegeben worden ist.

Was diese Anfragen gemeinsam haben: Sie klingen nach einem Nachmittag.

Nicht weil die Menschen, die sie stellen, die Arbeit kleinreden. Sondern weil die Oberfläche eines Systems wenig darüber verrät, was darunter liegt. Eine Schaltfläche sieht aus wie eine Schaltfläche. Ein Feld sieht aus wie ein Feld. Was beim ersten Entwurf vor drei oder fünf Jahren entschieden wurde und was diese Entscheidungen heute bedeuten, ist von außen nicht zu erkennen.

Das ist keine Kritik an den Anfragenden. Es ist die normale Erfahrung mit jedem System, das man nicht selbst gebaut hat. Die Oberfläche ist das, was sichtbar ist – und sie gibt nichts preis über das, was sie trägt.

Anfragen, die so klingen

Ein zusätzliches Suchfeld in einer Listenansicht
Eine Benachrichtigung per E-Mail, wenn sich ein Auftragsstatus ändert
Eine neue Spalte in einem Bericht, der bereits anderweitig genutzt wird
Der Export einer Tabelle in einem anderen Format als bisher
Eine Anzeige, die zwei Informationen zusammenführt, die bislang auf zwei Seiten stehen

Keine dieser Anfragen ist abwegig. Viele davon werden am Ende auch umgesetzt. Der Unterschied liegt nicht im Wunsch, sondern in dem, was zwischen dem Wunsch und dem fertigen Ergebnis liegt – und dass dieser Abstand selten dort liegt, wo man ihn zunächst vermutet.

Was der erste Entwurf festgelegt hat

Jede Fachanwendung beginnt mit einem Gespräch über Anforderungen. Was soll das System können? Wer arbeitet damit? Wie sehen die Abläufe aus? Die Antworten auf diese Fragen fließen in den ersten Entwurf ein — und dieser Entwurf entscheidet mehr, als in diesem Gespräch je besprochen wurde.

Nicht die Farben oder die Formularbeschriftungen. Sondern die Fragen, die das System später beantworten kann, und die, die es nie beantworten wird.

Annahmen, die zur Struktur werden

Ein konkretes Beispiel: Ein System wird gebaut, um Aufträge nach Standort zu verwalten. Jeder Auftrag gehört zu genau einem Standort. Das ist die richtige Entscheidung für ein Unternehmen mit drei Filialen und klarer Zuständigkeit. Zwei Jahre später möchte dieselbe Geschäftsführung wissen, welche Kunden standortübergreifend kaufen. Die Daten liegen vor. Aber die Verbindung, die diese Frage beantworten würde, ist nicht vorhanden — weil sie beim ersten Entwurf nicht gebraucht wurde.

Das ist kein Fehler. Es ist eine Entscheidung, die zum damaligen Zeitpunkt sinnvoll war und heute zur Grenze geworden ist.

Was sich nicht einfach ergänzen lässt

Ähnliches gilt für Zugriffsrechte. Ein System, das zwischen „darf" und „darf nicht" unterscheidet, kann diese Unterscheidung später nicht beliebig verfeinern — etwa in „darf sehen", „darf bearbeiten" und „darf freigeben". Die Erweiterung ist keine Ergänzung. Sie verändert, was als Fundament gebaut wurde. Alles, was darauf aufgebaut ist, muss neu bewertet werden.

Oder Preisberechnungen: Wenn die Logik dafür an einer Stelle im System sitzt, weil es beim Start nur eine Preisstruktur gab, ist eine zweite Preisstruktur nicht ein weiterer Eintrag in einer Tabelle. Sie ist ein Eingriff in eine Logik, die nie für diesen Fall gebaut wurde.

Wie Datensätze miteinander verknüpft sind — oder eben nicht
Wie Zugriffsrechte aufgebaut sind und welche Unterscheidungen sie zulassen
Wo Berechnungen stattfinden und wie flexibel diese Stellen sind
Ob das System für einen Mandanten oder für mehrere gedacht war

Diese Entscheidungen sind zum Zeitpunkt des ersten Entwurfs oft nicht als Entscheidungen erkennbar. Sie sind die Selbstverständlichkeiten des ersten Gesprächs. Und genau das macht sie so beständig: Niemand hat sie bewusst getroffen, also fragt auch niemand, ob sie noch gelten.

Wenn eine Anfrage später teurer wirkt als erwartet, liegt das häufig nicht daran, dass die Änderung schwierig ist. Sondern daran, dass sie an eine dieser frühen Weichenstellungen stößt — und die lässt sich nicht umgehen, ohne anzufassen, was der erste Entwurf als selbstverständlich vorausgesetzt hat.

Wenn mehrere Stellen gleichzeitig berührt werden

Manchmal liegt die Ursache für einen hohen Aufwand nicht in der Änderung selbst, sondern in der Zahl der Stellen, die sie berührt. Eine Anfrage, die nach einer kleinen Anpassung klingt, kann in einem System, das über Jahre gewachsen ist, an einem Dutzend verschiedener Orte etwas bedeuten.

Ein Beispiel: Ein Unternehmen möchte, dass ein Kundenname in der Rechnung anders formatiert wird — Vorname zuerst, dann Nachname, statt umgekehrt. Auf dem Bildschirm ist das eine Zeile. Im System ist es die Frage, an wie vielen Stellen dieser Name abgelegt, verarbeitet, ausgegeben und geprüft wird. Wenn sieben verschiedene Bereiche des Systems diesen Namen auf ihre eigene Weise behandeln, muss jeder davon einzeln angefasst werden.

Das passiert nicht, weil jemand schlechte Arbeit geleistet hat. Es passiert, weil Software beim Wachsen Verbindungen aufbaut. Was einmal eine einzelne Stelle war, wird mit der Zeit zu einem Knotenpunkt.

Was das in der Praxis bedeutet

Wenn eine Änderung an mehreren Stellen gleichzeitig wirken muss, entstehen Arbeitsschritte, die von außen vollständig unsichtbar sind:

Jede betroffene Stelle muss erst gefunden werden — das ist keine Suche im Sinne von Nachschauen, sondern ein Durcharbeiten des Systems, Schicht für Schicht.
Jede Änderung muss so abgestimmt sein, dass die anderen Stellen danach nicht anders reagieren als erwartet.
Jede betroffene Funktion muss anschließend geprüft werden — nicht nur die, die geändert wurde, sondern alle, die mit ihr in Verbindung stehen.

Das Ergebnis ist ein Aufwand, der sich nicht aus der sichtbaren Änderung erklärt, sondern aus der Struktur darunter. Wer das Angebot liest und denkt, die Zahl sei zu hoch, hat keine falschen Erwartungen — er sieht den Eingang, nicht das Gebäude dahinter.

Besonders häufig tritt das auf, wenn etwas, das anfangs an einer zentralen Stelle saß, im Laufe der Zeit an mehrere Orte kopiert wurde. Nicht aus Sorglosigkeit, sondern weil in dem Moment, als ein neues Modul gebaut wurde, die schnellste Lösung war, das Bestehende kurz zu wiederholen. Das funktioniert. Bis jemand das Original ändern möchte.

Es gibt Systeme, in denen ein geänderter Betrag an vierzehn Stellen auftaucht: in der Anzeige, in der Berechnung, in der Bestätigung per E-Mail, im Export, im Bericht, in der archivierten Version. Wer von außen fragt, warum das Anpassen eines Betrags drei Tage dauert, bekommt eine Antwort, die stimmt und trotzdem schwer zu glauben ist.

In solchen Momenten zeigt sich, was die frühen Entscheidungen wirklich gekostet haben — nicht beim Schreiben, sondern beim Lesen, Jahre später, wenn jemand etwas ändern möchte, das damals selbstverständlich wirkte.

Was zwischen der Anfrage und dem Angebot passiert

Wer eine Änderung anfragt, erwartet ein Angebot. Nicht sofort, aber in einigen Tagen. Was in dieser Zeit tatsächlich passiert, ist für die meisten Auftraggeberinnen und Auftraggeber nicht sichtbar — und genau deshalb klingt die Zahl, die dann kommt, so unverhältnismäßig.

Das Entwicklungsteam liest die Anfrage und beginnt zu suchen. Nicht nach der Stelle, an der die Änderung eingebaut werden soll — die ist oft schnell gefunden — sondern nach allem, was diese Stelle berührt. Ein Feld, das einen anderen Wert annehmen soll, ist nicht nur ein Feld. Es ist eine Angabe, die von drei verschiedenen Auswertungen gleichzeitig gelesen wird. Es ist ein Exportformat, das ein nachgelagertes System in einer bestimmten Form erwartet. Es ist eine Prüfregel, die an anderer Stelle im System ebenfalls greift. Und es ist möglicherweise eine gesetzliche Anforderung, die das ursprüngliche Design geprägt hat und nicht einfach umgangen werden kann.

Diese Suche dauert. Manchmal einen Tag, manchmal drei. Sie endet nicht immer mit einer klaren Antwort, sondern mit einer Liste von Fragen — die dann beim Auftraggeber landen: Warum wurde damals diese Regel eingebaut? Soll das neue Verhalten auch für bereits vorhandene Einträge gelten? Was passiert, wenn beide Zustände gleichzeitig aktiv sein können?

Wer diese Fragen bekommt, versteht oft nicht, warum sie gestellt werden. Die Anfrage schien eindeutig. Jetzt wirkt es, als ob das Team nicht vorbereitet ist oder die Sache hinauszögert. Beides stimmt in der Regel nicht.

Die Zahl und was hinter ihr steckt

Das Angebot, das schließlich eintrifft, enthält eine Zahl und eine Erläuterung. Die Zahl ist größer als erwartet. Die Erläuterung nennt Zusammenhänge, die wenig vertraut klingen. Dahinter steckt aber eine einfache Aussage: Die Stelle, an der die Änderung stattfinden soll, ist nicht isoliert. Sie hängt zusammen. Wer das eine ändert, muss das andere mitdenken — oder später teuer nacharbeiten.

Für den Auftraggeber ist das schwer einzuordnen. Die Software wurde als fertig übergeben. Dass "fertig" in diesem Zusammenhang bedeutet, dass alles funktioniert — aber nicht, dass jede spätere Änderung reibungslos einzubauen ist — das ist ein Unterschied, der selten erklärt wird. Er fällt erst dann auf, wenn eine Rechnung im Postfach liegt.

Die Wartezeit vor dem Angebot ist keine Vorsichtsmaßnahme, sondern Analysearbeit.
Rückfragen aus dem Projekt sind kein Zeichen mangelnder Vorbereitung — sie zeigen, dass jemand verstanden hat, was die Anfrage tatsächlich berührt.
Eine Zahl ohne Erläuterung ist selten hilfreich; eine Erläuterung ohne Kontext ist es ebenso wenig.

Was in dieser Phase oft fehlt, ist ein gemeinsames Bild davon, was die Änderung eigentlich bedeutet — technisch wie inhaltlich. Wer dieses Bild früh herstellt, spart sich später die Überraschung.

Warum das System beim Wachsen nicht von selbst mitwächst

Eine Software wird für einen bestimmten Moment gebaut. Für eine bestimmte Anzahl von Kunden, eine bestimmte Art von Anfragen, eine bestimmte Menge an Daten. Dieser Moment liegt oft zwei oder drei Jahre zurück, manchmal länger. Seitdem hat sich das Unternehmen verändert — aber das System nicht.

Das zeigt sich nicht als Fehlermeldung. Es zeigt sich darin, dass Listen immer langsamer werden. Dass eine neue Produktgruppe in keine der vorhandenen Kategorien passt. Dass zwei Standorte dieselben Nummern vergeben und das beim Monatsabschluss auffällt. Dass ein Bericht, der früher automatisch stimmte, seit dem Wachstum nur noch als Näherungswert gilt.

Was das System erwartet hatte

Jedes System enthält Annahmen darüber, wie die Welt aussieht. Wie viele Objekte ein Verwalter betreut. Wie viele Preislisten ein Anbieter pflegt. Ob ein Mieter immer in genau einer Einheit wohnt. Ob eine Rechnung immer genau einem Auftrag gehört. Diese Annahmen waren bei der Entwicklung vernünftig. Sie wurden selten dokumentiert, weil sie niemandem als Entscheidung auffielen — sie waren schlicht die Realität zu diesem Zeitpunkt.

Solange das Unternehmen innerhalb dieser Annahmen arbeitet, ist alles unauffällig. Sobald es darüber hinauswächst — ein zweiter Standort, eine neue Kundengruppe, eine Ausnahme, die zur Regel wird — beginnt das System zu drücken. Nicht weil es schlecht gebaut wurde, sondern weil es für eine andere Größe gebaut wurde.

Wo die Kosten entstehen, bevor jemand fragt

Softwaresysteme haben kein Bewusstsein für ihre eigenen Grenzen. Sie verlangsamen sich, sie liefern falsche Summen, sie schweigen an Stellen, an denen eine Antwort erwartet wird. Der Betrieb läuft trotzdem weiter — oft mit manuellen Korrekturen, die sich einschleichen und irgendwann als normal gelten.

Eine Immobilienverwaltung, die mit 80 Einheiten begann und heute 400 betreut, hat vielleicht drei Felder in einer Maske, die niemand mehr für ihre ursprüngliche Bedeutung nutzt — sie wurden umgewidmet, als der ursprüngliche Zweck wegfiel. Eine Software, die für Einzelaufträge ausgelegt war, wird für Rahmenprojekte mit Teillieferungen genutzt, weil es kein anderes Feld gibt. Beides funktioniert. Beides kostet täglich Zeit, die in keiner Kalkulation auftaucht.

Neue Mitarbeitende brauchen länger, um produktiv zu werden, weil jemand erklären muss, wie man mit dem System umgeht.
Berichte werden nach dem Export manuell bereinigt, weil die Datenstruktur das Wachstum nicht abbildet.
Ausnahmen werden als freie Textfelder gelöst — lesbar für eine Person, unsichtbar für alle Auswertungen.

Diese Kosten erscheinen in keiner Rechnung. Sie erscheinen in Meetings, in Übergaben, in dem stillen Wissen, dass bestimmte Dinge eben so gemacht werden. Wenn dann eine Änderung angefragt wird, die aus Sicht des Unternehmens klein klingt, trifft sie auf ein System, das jahrelang an seinen Grenzen betrieben wurde. Die Änderung selbst ist vielleicht tatsächlich nicht groß. Aber der Boden, auf dem sie umgesetzt werden soll, ist nicht mehr der, auf dem das System ursprünglich stand.