Warum Fachsoftware mehr kostet als der erste Preis zeigt

Das Angebot, das vollständig wirkt

Das Angebot kommt als PDF. Es nennt einen Preis und beschreibt, was entwickelt wird. Wer es liest und keine offenen Fragen findet, schreibt zurück, dass er unterschreibt.

Das ist der Moment, in dem die meisten Projekte bereits in einem Budgetrahmen stecken, der nicht für das Projekt passt, das sie tatsächlich bauen werden.

Ein Softwareangebot erfasst, was ein Team in einem bestimmten Zeitraum gegen Bezahlung liefert: was die Nutzer sehen werden, wie Daten gespeichert werden, wie das System mit anderen Programmen zusammenarbeitet. Was es nicht erfasst, ist das, was daneben entsteht — und was trotzdem jemanden Zeit und Geld kostet.

Was im Angebot fehlt

Dazu gehören typischerweise:

Die Überführung bestehender Daten in die neue Struktur — Excel-Listen, ein altes System, ein früherer Dienstleister, der die Daten in einem eigenen Format hält
Das Einrichten von Zugängen und Berechtigungen: wer darf was sehen, wer muss das abnehmen
Die Abstimmung mit dem IT-Dienstleister, der die technische Infrastruktur betreut und eigene Anforderungen hat
Eine Anleitung, die tatsächlich gelesen werden kann
Testläufe mit echten Fällen, nicht nur mit Musterdaten

Keiner dieser Punkte ist unvorhersehbar. Sie tauchen in jedem Projekt mit einem gewissen Umfang auf. Warum fehlen sie im Angebot trotzdem?

Wie ein Angebot entsteht

Ein Angebot schreibt jemand, der noch nicht genau weiß, wie das Projekt aussehen wird. Je früher im Prozess, desto mehr Lücken. Was gut beschrieben ist, bekommt einen Preis. Was noch unklar ist, bekommt einen Puffer — oder wird weggelassen.

Das ist keine Täuschung. Es ist die Natur von Festpreisangeboten: Sie preisen das Bekannte. Das Unbekannte bleibt außen.

Wer drei Angebote einholt und das günstigste wählt, vergleicht nicht drei vollständige Projekte miteinander. Er vergleicht drei unterschiedliche Versionen davon, was drei Teams für relevant und beschreibbar gehalten haben. Das günstigste Angebot kann das vollständigste sein — oder das, das am wenigsten aufgeschrieben hat.

Wie man liest, was nicht dasteht

Das Gespräch vor dem Angebot sagt mehr als das Dokument. Ein Team, das nach den Bestandsdaten fragt, nach wem das System abnimmt, nach dem zuständigen IT-Dienstleister und wie der Start aussehen soll — dieses Team hat das Projekt schon weiter gedacht als das Angebot zeigt.

Ein Angebot, das mit wenigen Gesprächen auskommt und trotzdem vollständig wirkt, hat die Komplexität nicht beseitigt. Es hat sie nur nicht aufgeschrieben.

Was nach dem ersten Release weiterläuft

Der Tag, an dem eine Software in Betrieb geht, wird oft als Abschluss behandelt. Für das Unternehmen, das sie nutzt, ist es der erste Tag.

Was danach kommt, steht selten im ursprünglichen Angebot. Nicht weil man es verschwiegen hätte, sondern weil es keine einmalige Leistung ist, sondern eine laufende. Und laufende Leistungen lassen sich schlecht in einem Festpreis darstellen, der für die Entwicklungsphase gilt.

Was sich nach dem Start unweigerlich verändert

Ein System, das im Oktober fertiggestellt wurde, läuft im folgenden Frühjahr in einer anderen Umgebung. Browser haben Updates erhalten. Das Betriebssystem auf den Geräten der Mitarbeiter hat sich geändert. Ein externer Dienstleister hat sein eigenes System angepasst, und die Übergabe zwischen beiden läuft nicht mehr fehlerfrei. Nichts davon ist dramatisch. Alles davon erzeugt Aufwand.

Hinzu kommt, was erst sichtbar wird, wenn Menschen das System wirklich benutzen. Der Mitarbeiter, der täglich damit arbeitet, findet nach drei Wochen heraus, dass ein bestimmter Schritt drei Klicks zu viel hat. Der Steuerberater stellt fest, dass ein Ausdruck nicht in dem Format kommt, das sein Programm versteht. Die Inhaberin möchte eine Auswertung, die bei der Anforderungsaufnahme niemand erwähnt hatte — weil damals niemand wusste, dass sie gebraucht wird.

Jede dieser Rückmeldungen ist berechtigt. Keine davon war im ursprünglichen Auftrag enthalten.

Was regelmäßig gewartet werden muss

Sicherheits-Updates der verwendeten Programme, die im Hintergrund anfallen und dennoch eingespielt werden müssen
Anpassungen, wenn sich gesetzliche Vorgaben ändern — Datenschutz, Steuerrecht, branchenspezifische Meldepflichten
Korrekturen von Fehlern, die erst nach einiger Zeit im laufenden Betrieb auftreten, weil bestimmte Situationen im Test nicht vorgekommen sind
Anpassungen an neue Versionen von Programmen, mit denen das System zusammenarbeitet

Wer diese Kosten nicht einplant, plant mit einem Budget, das nach dem ersten Release aufgebraucht ist — und danach beginnen die ungeplanten Ausgaben.

Manche Unternehmen regeln das über einen Wartungsvertrag mit einem festen monatlichen Betrag. Andere bezahlen fallweise, was ebenfalls funktionieren kann, in der Regel aber teurer wird — weil jede Anfrage neu bewertet und priorisiert werden muss. Welches Modell sinnvoller ist, hängt davon ab, wie häufig das System sich verändern muss. Und das weiß man oft erst, nachdem man es ein Jahr betrieben hat.

Was man vorher abschätzen kann: Ein System, das in einem stark regulierten Umfeld eingesetzt wird — etwa in der Immobilienwirtschaft, in der Finanzberatung oder im Gesundheitsbereich — wird häufiger Anpassungen brauchen als eines, dessen Anforderungen seit Jahren stabil sind. Das ist kein Mangel des Systems. Es ist der Preis dafür, dass sich der Betrieb des Unternehmens in der Software widerspiegelt. Und ein Betrieb ist selten statisch.

Wenn sich die Anforderungen mitten im Projekt verschieben

Ein Projekt beginnt mit einem Gespräch. Was gebraucht wird, klingt klar: ein Formular für neue Mieter, eine Übersicht für offene Posten, eine Möglichkeit, Besichtigungstermine zu verwalten. Das klingt nach drei Wochen Arbeit, vielleicht vier. Der Preis, der daraus folgt, wirkt nachvollziehbar.

Drei Monate später sieht die Situation anders aus. Nicht weil jemand Fehler gemacht hat — sondern weil sich herausgestellt hat, dass die Besichtigungsverwaltung mit dem Kalender der Kollegin zusammenpassen muss. Dass es zwei verschiedene Mieterarten gibt, die unterschiedliche Formulare brauchen. Dass die offenen Posten auch exportiert werden müssen, in ein Format, das die Buchhaltung kennt.

Jede dieser Erkenntnisse war beim ersten Gespräch real — sie war nur noch nicht sichtbar. Das ist kein Versagen des Auftraggebers. Wer ein System zum ersten Mal beschreibt, beschreibt, was er heute sieht. Was er morgen braucht, zeigt sich oft erst, wenn etwas davon tatsächlich läuft.

Das Problem ist nicht die Änderung selbst. Das Problem ist, was eine Änderung mitten im Bau kostet.

Ein Haus, bei dem der Grundriss nach dem Rohbau geändert wird, ist kein Haus mit einer Zusatzleistung. Es ist ein Haus, bei dem Teile abgetragen und neu errichtet werden. Bei Software gilt dasselbe Prinzip: Was in einem frühen Stadium eine Stunde dauert, dauert sechs Monate später einen Tag — weil inzwischen anderes darauf aufgebaut wurde, das ebenfalls angepasst werden muss.

Drei Situationen, die das greifbar machen

Eine Maklerin entscheidet sich, nachdem das Exposé-Modul fertig ist, für eine andere Nummerierung der Objekte. Das klingt nach einer kleinen Änderung. Die Nummerierung ist aber in der Datenbank, in den exportierten Dateien und in zwei anderen Modulen verankert. Die Änderung berührt all das.
Ein Verwalter möchte, dass Mieter eine digitale Unterschrift leisten können. Das war nie Teil des ersten Gesprächs. Es klingt nach einer Funktion, die man ergänzt. Tatsächlich verändert es, wie Formulare gespeichert, wie Versionen verwaltet und wie Dokumente archiviert werden — drei Bereiche, die neu durchdacht werden müssen.
Ein Handwerksbetrieb braucht ein Feld für den Subunternehmer. Das klingt nach einem Feld. Aber der Subunternehmer hat eigene Konditionen, eigene Abrechnungszeiten, eigene Kommunikationswege. Ein Feld wird zu einem Modul.

Das ist keine Ausnahme. Es ist der Normalfall in jedem Projekt, das länger als sechs Wochen läuft. Anforderungen verschieben sich nicht, weil die Beteiligten unvorbereitet waren — sie verschieben sich, weil man vieles erst dann wirklich versteht, wenn man es täglich benutzt. Eine Branche, in der Prozesse seit Jahren auf eine bestimmte Art laufen, merkt die Lücken im neuen System erst, wenn das alte nicht mehr danebenstehnt.

Verträge, die das nicht abbilden, führen zu einer Situation, in der keine Seite lügt und trotzdem niemand bekommt, was er erwartet hat. Die eine Seite hat geliefert, was vereinbart war. Die andere hat bekommen, was sie beschrieben hat — aber nicht, was sie gebraucht hätte. Der Unterschied zwischen beidem liegt nicht im guten Willen. Er liegt darin, was zu welchem Zeitpunkt sichtbar war.

Wann ein System zum Engpass wird

Ein System, das für dreißig Vorgänge im Monat entworfen wurde, läuft mit dreißig Vorgängen reibungslos. Bei dreihundert beginnen die Stellen sichtbar zu werden, die beim Entwurf niemand für kritisch gehalten hat.

Das ist kein Versagen der Entwicklung. Es ist das normale Ergebnis davon, dass Anforderungen sich ändern — und dass ein System, das vor zwei Jahren ausgeliefert wurde, auf den Stand von vor zwei Jahren gebaut ist.

Wenn Workarounds zur Routine werden

Der zuverlässigste Hinweis, dass ein System zu eng geworden ist, sind die Dinge, die niemand mehr erwähnt. Die Tabelle, die jeden Montagmorgen manuell befüllt wird, weil der Export nicht das richtige Format liefert. Die E-Mail-Kette, die parallel läuft, weil das System keine Freigabeschritte kennt. Die Person im Team, die weiß, was zu tun ist, wenn das System sich unerwartet verhält — und ohne die niemand weiterkommt.

Diese Workarounds sind nicht dramatisch. Sie entstehen langsam, ein kleiner Schritt nach dem anderen, und irgendwann sind sie Teil des Prozesses, nicht mehr Ausnahme von ihm. Wer neu ins Team kommt, lernt sie wie selbstverständlich mit.

Wenn Wachstum das System überfordert

Manchmal ist der Engpass nicht die Funktion, sondern das Volumen. Eine Immobilienverwaltung, die von siebzig auf zweihundert Einheiten wächst, stellt fest, dass die Monatsabrechnung nicht schneller wird, obwohl sie mehr Erfahrung hat. Die Suche dauert länger. Die Auswertungen, die früher sofort da waren, brauchen jetzt eine Weile. Niemand hat etwas falsch gemacht — das System ist schlicht für einen anderen Maßstab gebaut worden.

Ähnliches gilt für externe Anforderungen: eine neue gesetzliche Pflicht, die einen Schritt erfordert, den das System nicht kennt. Ein anderes Werkzeug, das angebunden werden soll und sich als eigenes kleines Projekt herausstellt. Ein Bericht, den die Steuerkanzlei jetzt jedes Quartal braucht, für den das System keine Vorlage hat.

Die stille Frage hinter dem Alltagsbetrieb

Der Moment, in dem ein System zum Engpass wird, ist selten ein Ausfall. Meistens ist es eine Summe aus kleinen Verzögerungen, aus Handgriffen, die eigentlich das System erledigen sollte, aus Fragen, die niemand mehr stellt, weil die Antwort immer dieselbe ist: So haben wir das immer gemacht.

Wer prüfen will, ob sein System ein Engpass ist, stellt sich eine Frage: Wie viel Zeit verbringt das Team damit, das System zu bedienen — und wie viel Zeit verbringt es mit der Arbeit, für die das System da sein sollte? Die Antwort darauf ist meistens bekannt. Sie wird selten laut ausgesprochen.

Die Rechnung, die zwei Jahre später kommt

Zwei Jahre nach der Inbetriebnahme sieht die Lage meistens anders aus als bei der Übergabe. Das System läuft. Es tut, wofür es gebaut wurde. Und dann ändert sich etwas — nicht im System, sondern um es herum.

Ein Steuergesetz tritt in Kraft, das ein neues Pflichtfeld in der Ausgangsrechnung verlangt. Eine Buchungsplattform ändert, wie sie Reservierungen weitergibt. Der Mitarbeiter, der das System täglich bedient hat, verlässt das Unternehmen. Sein Nachfolger findet weder eine Anleitung noch jemanden, der ihm erklären kann, wie bestimmte Ausnahmen eingetragen werden.

In allen drei Fällen ist die Frage dieselbe: Was kostet es jetzt, das System anzupassen? Und die Antwort überrascht. Nicht, weil jemand schlecht gearbeitet hat — sondern weil Software, die zwei Jahre im Betrieb war, in der Zwischenzeit Schicht um Schicht bekommen hat, die kein Einzelner mehr vollständig überblickt.

Wenn eine kleine Änderung groß wird

Ein Immobilienverwalter mit zwanzig Einheiten ließ sich vor einigen Jahren ein System für die Betriebskostenabrechnung bauen. Es passte genau auf seine Prozesse. Zwei Jahre später verlangte eine neue gesetzliche Vorgabe eine zusätzliche Aufschlüsselung. Der Entwickler war noch erreichbar. Sein Angebot für die Änderung entsprach einem Viertel des ursprünglichen Projektpreises — für etwas, das von außen wie eine Kleinigkeit aussah.

Das war kein Versagen. Es war die Konsequenz davon, dass ein zwei Jahre altes System von innen anders aussieht als von außen. Der Entwickler brauchte Zeit, sich wieder einzuarbeiten. Die neue Vorgabe saß an einer Stelle, die mehrere andere Teile des Systems berührte. Und die Stelle war damals aus gutem Grund so gebaut worden, wie sie war — nur dass dieser Grund jetzt im Weg stand.

Was in keinem ersten Angebot steht

Einarbeitungszeit, wenn das Projekt übergeben wurde oder der ursprüngliche Entwickler gewechselt hat
Anpassungen an gesetzliche Anforderungen, die zur Entstehungszeit nicht absehbar waren
Schulungsaufwand, wenn neue Mitarbeiterinnen und Mitarbeiter ein System übernehmen, das nie dokumentiert wurde
Folgekosten, wenn sich ein externer Dienst ändert, auf den das System angewiesen ist

Keiner dieser Punkte steht im Erstangebot — nicht, weil er versteckt wird, sondern weil er zum Zeitpunkt der Angebotslegung schlicht noch nicht existiert. Er entsteht später. Und er landet trotzdem in der Rechnung.

Wer Software anschafft oder beauftragt, rechnet mit dem Preis auf der ersten Seite. Was in Jahr zwei oder drei dazukommt, ist eine offene Variable. Sie hängt davon ab, wie stabil die eigenen Prozesse sind — und wie viel sich in der Umgebung bis dahin verschoben hat. Bei einer Lösung, die eng auf bestimmte Abläufe zugeschnitten ist, ist diese Variable selten null.