Warum individuelle Software teurer ist als sie aussieht

Was im Angebot steht — und was nicht

Ein Angebot für individuelle Software listet auf, was gebaut wird. Es listet selten auf, was nicht gebaut wird — und diese Lücke ist teurer als die Summe auf der letzten Seite.

Was steht typischerweise drin: die beschriebenen Funktionen, eine Anzahl von Entwicklungstagen, ein Übergabetermin. Was fehlt fast immer: die Testabdeckung, die Migration bestehender Daten, die Dokumentation für den Betrieb, die Einarbeitung der Mitarbeitenden und das Verhalten der Anwendung unter Last. Nicht weil die Agentur es verschweigt — sondern weil es zum Zeitpunkt des Angebots noch nicht klar ist, wie viel davon anfällt.

Was „fertig" bedeutet, ist nicht definiert

Eine Funktion kann technisch korrekt implementiert sein und trotzdem nicht das tun, was jemand im Alltag braucht. Ein Formular speichert Daten — aber was passiert, wenn jemand es zweimal abschickt? Was, wenn ein Pflichtfeld leer bleibt, weil der Browser es anders rendert als erwartet? Was, wenn fünfzig Personen gleichzeitig dasselbe tun?

Diese Fragen tauchen im Angebot nicht auf, weil sie im Moment der Preisfindung niemand gestellt hat. Im Projektverlauf kosten sie Zeit — und diese Zeit steht in keiner Kalkulation.

Was Daten mitbringen

Fast jedes Unternehmen, das neue Software einführt, hat bereits Daten. In Excel-Listen, in einer alten Datenbank, in einem System, das abgelöst werden soll. Der Umzug dieser Daten in eine neue Struktur ist selten trivial:

Feldnamen stimmen nicht überein.
Datumformate wurden nie einheitlich geführt.
Duplikate und Lücken müssen vor der Migration bereinigt werden.
Historische Einträge folgen Regeln, die nirgends aufgeschrieben sind.

Eine Migration, die im Angebot mit zwei Tagen veranschlagt ist, dauert häufig das Dreifache — nicht weil jemand schlecht gerechnet hat, sondern weil der tatsächliche Zustand der Daten erst beim Anfassen sichtbar wird.

Was Sicherheit kostet

Anmeldung, Zugriffskontrolle, verschlüsselte Übertragung — das klingt nach Standard. Und ist es auch, bis jemand fragt: Wer darf welche Daten sehen? Kann eine Mitarbeiterin Einträge anderer Standorte öffnen? Was passiert, wenn ein Account kompromittiert wird? Jede dieser Fragen ist eine Anforderung. Anforderungen, die im Erstgespräch nicht gestellt wurden, stehen nicht im Angebot.

Das ist kein Vorwurf — es ist die Natur von Software. Ein Angebot beschreibt, was man sich vorstellt. Was man sich vorstellt, ist nie vollständig. Die Frage ist nur, wann die Lücken auftauchen: vor dem Start oder danach.

Womit die eigentliche Arbeit beginnt

Bevor eine Zeile Code geschrieben wird, muss jemand verstehen, was das System eigentlich tun soll. Das klingt einfach. Es ist der aufwendigste Teil des Projekts.

In einem ersten Workshop werden Prozesse beschrieben, wie sie in der Theorie ablaufen. Oft stellt sich nach zwei Stunden heraus, dass zwei Personen aus derselben Abteilung denselben Prozess unterschiedlich beschreiben — beide haben recht, weil beide Varianten tatsächlich vorkommen. Was im Alltag als Ausnahme gilt, ist in Wirklichkeit ein Regelfall, der nur nie aufgeschrieben wurde.

Was aufgeräumt wirkt, ist es selten

Unternehmen, die seit Jahren mit Tabellen, E-Mails und Telefonaten arbeiten, kennen ihre eigenen Abläufe sehr genau — aber meistens nicht in einer Form, die sich direkt in Software übersetzen lässt. Das Wissen steckt in den Köpfen der Menschen, die diese Aufgaben jeden Tag erledigen. Es ist zuverlässig. Es ist nirgendwo dokumentiert.

Ein Softwareprojekt beginnt deshalb damit, dieses Wissen sichtbar zu machen. Nicht als Kritik, sondern weil Software nichts anderes tut, als Entscheidungsregeln umzusetzen, die ihr jemand vorher mitteilen muss. Eine Regel, die nicht explizit beschrieben ist, landet entweder als Sonderfall im System — oder fehlt.

Die Fragen, die niemand erwartet

Was passiert, wenn ein Auftrag nach der Bestätigung geändert wird? Wer darf eine Bestellung stornieren — und bis zu welchem Zeitpunkt? Was, wenn zwei Personen gleichzeitig denselben Eintrag bearbeiten? Darf das System eine Buchung automatisch ablehnen, oder soll immer jemand die letzte Entscheidung treffen?

Diese Fragen sind nicht technisch. Sie sind organisatorisch. Und die Antworten darauf existieren meistens — nur nicht schriftlich, und nicht immer einheitlich. Eine Buchhalterin beantwortet die Frage nach der Stornoregel anders als der Vertriebsleiter. Beides ist richtig. Das System kann trotzdem nur eine Regel umsetzen.

Wer entscheidet bei Ausnahmen — und nach welchem Kriterium?
Welche Schritte sollen automatisch laufen, welche brauchen einen Menschen dazwischen?
Was passiert, wenn eine Voraussetzung fehlt: Fehler, Warnung oder Weiterarbeiten?

Diese Klärung kostet Zeit. Sie ist keine Zusatzleistung und kein Verzögerungsgrund — sie ist die Voraussetzung dafür, dass das, was danach gebaut wird, zu dem Betrieb passt, der es betreibt. Projekte, die diesen Schritt abkürzen, produzieren zuverlässig laufende Software, die am Ende des Tages nicht ganz das tut, was gebraucht wird.

Manchmal dauert die Anforderungsklärung so lange wie die eigentliche Entwicklung. Das überrascht, weil sie unsichtbar ist: Am Ende stehen keine Bildschirme, keine Funktionen, keine Demos — sondern ein Dokument, das beschreibt, was das System entscheiden soll, und wer dafür die Verantwortung trägt. Diesen Aufwand erkennt man im ersten Angebot fast nie.

Warum jede Änderung mehr kostet als die letzte

Im ersten Jahr nach dem Go-live läuft der Austausch mit dem Entwickler noch flüssig. Ein Feld ergänzen, eine Ansicht anpassen, eine neue Exportoption hinzufügen — das geht schnell, weil das System noch überschaubar ist und die, die es gebaut haben, noch jede Ecke kennen.

Zwei Jahre später hat sich etwas verändert. Nicht dramatisch, aber spürbar: Dieselbe Änderung, die damals zwei Tage kostete, kostet jetzt fünf. Die Erklärung, die Sie bekommen, klingt immer gleich: „Das hängt leider mit mehreren anderen Stellen zusammen."

Was „zusammenhängt" in der Praxis bedeutet

Jede Funktion, die in eine Software eingebaut wird, benutzt andere Funktionen — manchmal direkt, manchmal indirekt. Ein Dokumententyp, der neu hinzukommt, muss in der Suche auftauchen, in der Rechteverwaltung berücksichtigt werden und in bestehenden Exporten erscheinen. Wer das beim Einbauen nicht mitdenkt, schafft eine Stelle, die beim nächsten Eingriff aufbricht.

Das ist kein Fehler, der durch mehr Sorgfalt vollständig vermeidbar wäre. Es ist eine Eigenschaft jeder Software, die über einen längeren Zeitraum wächst: Abhängigkeiten akkumulieren sich. Je länger das System läuft, desto mehr Teile müssen bei einer Änderung mitgedacht werden.

Der Preis früher Entscheidungen

Manche Stellen in einer Software sind so grundlegend, dass eine Änderung dort alles andere berührt. Wie Dokumente einem Vorgang zugeordnet sind. Wie Zugriffsrechte vergeben werden. Wie Daten zwischen zwei Bereichen des Systems fließen. Diese Entscheidungen fallen meist in der ersten Projektphase, wenn der Zeitdruck groß und das Bild der Anforderungen noch unvollständig ist.

Später stellt sich heraus, dass eine andere Struktur besser gepasst hätte — für einen neuen Prozess, für eine neue Kundenkategorie, für eine Anforderung, die beim Start schlicht noch nicht absehbar war. Die Frage ist dann nicht mehr, ob man es ändern kann. Die Frage ist, was es kostet, es zu ändern, ohne dass zehn andere Dinge dabei aufhören zu funktionieren.

Was das für Ihren Entwicklungsaufwand bedeutet

Eine realistische Kalkulation für laufende Weiterentwicklung sieht anders aus als eine für den Erstaufbau. Im Erstaufbau baut man auf grüner Wiese; Änderungen an einem neuen System betreffen wenig. Im laufenden Betrieb hat jede Änderung Kontext: bestehende Daten, bestehende Nutzer, bestehende Prozesse, die nicht unterbrochen werden dürfen.

Hinzu kommt, dass Änderungen geprüft werden müssen — nicht nur die neue Stelle, sondern alle Stellen, die mit ihr zusammenhängen. Je mehr das System gewachsen ist, desto mehr gibt es zu prüfen. Wer das nicht einplant, erlebt es als Kostenüberschreitung, die niemand erklären kann, weil niemand am Anfang den Aufwand sauber beziffert hat.

Eine neue Benutzerrolle klingt nach zwei Stunden Arbeit — und kostet fünfzehn, weil jeder Prozessschritt die Rolle kennen muss.
Ein neues Pflichtfeld in einem Formular klingt einfach — bis man sieht, dass alle bisherigen Datensätze dieses Feld nicht haben und nachgefüllt oder ausgenommen werden müssen.
Eine geänderte Berechnungsformel klingt nach einer Zeile — bis klar ist, dass tausende bereits berechneter Werte in den Berichten damit nicht mehr stimmen.

Das sind keine Ausnahmen. Das ist der normale Verlauf eines Systems, das in ernsthafter Benutzung ist. Die Frage ist nicht, ob dieser Moment kommt — sondern ob der ursprüngliche Vertrag ihn einkalkuliert hat.

Was nach dem Go-live auf Sie zukommt

Das Projekt ist fertig. Die Software läuft. Alle haben sich die Hand gegeben. Was dann folgt, ist selten ein ruhiger Betrieb.

Im ersten Jahr nach dem Start ändert sich etwas, das niemand vorhergesehen hat. Nicht aus Nachlässigkeit — sondern weil Software in einer Welt läuft, die sich weiterbewegt. Betriebssysteme werden aktualisiert. Browser ändern ihr Verhalten. Externe Anbieter, auf die das System im Hintergrund setzt, passen ihre Abläufe an — und was bislang reibungslos lief, läuft plötzlich nicht mehr, ohne dass irgendjemand aktiv etwas angefasst hat.

Ein Buchhaltungsprogramm wechselt sein Format für den Datenexport. Eine Bank ändert das Verfahren für den automatischen Kontenabgleich. Das neue Steuergesetz greift ab Januar und betrifft eine Berechnung, die bislang fest eingebaut war. Jede dieser Änderungen klingt klein. Jede davon landet bei jemandem auf dem Tisch.

Wer kümmert sich — und was kostet das?

Wartung ist kein Bonus. Sie ist der Preis dafür, dass ein System über Zeit verlässlich bleibt. Wer das nicht einplant, stellt irgendwann fest, dass die Person, die das System kennt, nicht mehr erreichbar ist — oder dass niemand im Haus genau weiß, wie man eine Änderung beauftragen würde, ohne von vorn anfangen zu müssen.

Das betrifft besonders die Fälle, in denen ein einzelner Entwickler oder ein kleines Studio die Arbeit übernommen hat. Solange die Zusammenarbeit läuft, ist der Zugang gesichert. Endet sie — aus welchem Grund auch immer — steht man vor einem System, das man besitzt, aber nicht versteht. Die Dokumentation, falls eine existiert, erklärt das Was, selten das Warum.

Mitarbeiter kommen. Mitarbeiter gehen.

Wer das System eingeführt hat, weiß, wie es funktioniert. Wer zwei Jahre später dazukommt, lernt es von jemandem, der selbst nie ganz sicher war. Schulungsunterlagen veralten. Prozesse, die einmal in der Software abgebildet waren, werden von Hand weitergeführt — weil sich niemand traut, das System anzufassen, oder weil die Änderung zu teuer erscheint.

Das ist kein Versagen. Es ist die gewöhnliche Reibung, die entsteht, wenn ein Werkzeug in eine Organisation eingebettet ist, die sich verändert — und das Werkzeug sich nicht mitverändert.

Funktionen, die niemand mehr benutzt, aber keiner abschalten will, weil man nicht weiß, was dann passiert.
Fehler, die schon lange bekannt sind und mit denen man sich arrangiert hat.
Anfragen an den Entwickler, die im Postfach landen und dort bleiben.

Nach dem Go-live beginnt nicht der ruhige Teil. Er beginnt der lange Teil.

Welche Entscheidungen am Anfang das Ende bestimmen

Die meisten Entscheidungen, die später teuer werden, wirken im Moment, in dem sie getroffen werden, nicht wie Entscheidungen. Sie wirken wie selbstverständliche Annahmen.

Wer das letzte Wort hat

In vielen Projekten gibt es am Anfang mehrere Personen, die Anforderungen formulieren dürfen: die Geschäftsführung, den Vertrieb, den Innendienst, manchmal noch eine externe Beraterin. Die Software soll für alle passen. Was das bedeutet, wenn jede dieser Personen in der dritten Woche etwas anderes priorisiert, ist am ersten Tag nicht Thema. Projekte ohne eine einzige verantwortliche Person auf Kundenseite enden selten dort, wo sie beginnen — und die Abweichung ist nie kostenlos.

Wie viel die erste Version können soll

Ob die erste Version zehn Dinge können soll oder drei, ist keine technische Entscheidung. Sie entscheidet darüber, wann die Software erstmals produktiv eingesetzt wird, wie viele Prozesse vorher beschrieben werden müssen und wie hoch die Kosten für eine Richtungskorrektur sind, wenn sich in der Praxis herausstellt, dass eine Annahme falsch war. Je mehr die erste Version können soll, desto mehr Annahmen stecken drin — und desto mehr davon werden sich als unvollständig erweisen.

Mit wem gesprochen wird

Besonders folgenreich ist die Frage, wer die Anforderungen formuliert. Wer beschreibt, wie die Arbeit sein soll, beschreibt meistens nicht, wie sie tatsächlich ist. Wer täglich mit dem System arbeiten wird, kennt die Ausnahmen: die Rechnung, die anders aussieht als alle anderen; die Kundin, die in drei Systemen unter unterschiedlichen Namen geführt wird. Diese Ausnahmen sind kein Randproblem — sie sind oft der Kern der Aufgabe. Werden sie erst nach dem Go-live sichtbar, kosten sie das Mehrfache ihrer ursprünglichen Berücksichtigung.

Wie viel Eigenleistung das Unternehmen einplant

Eine letzte Entscheidung, die am Anfang kaum als solche wahrgenommen wird: Wie viel Zeit das Unternehmen selbst einbringt. Eine Softwareentwicklung, die ohne intensive Beteiligung der späteren Nutzerinnen und Nutzer auskommt, gibt es nicht. Wer das annimmt, stellt meistens fest, dass er es nicht angenommen hat — sondern gehofft. Die Stunden für Abstimmungen, Freigaben und das Testen realer Fälle sind kein Aufwand, den man delegieren kann. Sie fallen an, ob sie geplant werden oder nicht.