Wann sich individuelle Software wirklich lohnt

Fast jede Firma, die „individuelle Software entwickeln lassen” sucht, hat vorher etwas anderes versucht: eine Standardlösung mit zehn Excel-Tabellen drumherum, ein Tool, das für einen anderen Zweck gebaut wurde und irgendwie zweckentfremdet läuft, oder drei SaaS-Abos, die per Copy-Paste synchron gehalten werden. Die Frage ist selten „Software oder nicht”, sondern wann sich der Wechsel von Behelfslösung zu echtem System lohnt.

Der Grund, warum diese Frage so schwerfällt, ist, dass Behelfslösungen selten auf einmal versagen. Sie werden schleichend unbequemer, ein Workaround nach dem anderen, bis irgendwann eine einzelne Person im Unternehmen den gesamten Prozess im Kopf trägt und niemand sonst ihn erklären kann. Bis dahin fühlt sich jede einzelne Behelfslösung für sich genommen vertretbar an.

Die Anzeichen, die wir immer wieder sehen

Ein Prozess lebt in Tabellenblättern. Wenn eine zentrale Geschäftslogik — Preisberechnung, Verfügbarkeitsprüfung, Freigabekette — in einer Excel-Datei steckt, die eine Person pflegt, ist das kein Prozess mehr, sondern ein Risiko mit einem einzigen Ausfallpunkt. Fällt diese Person aus oder verlässt sie die Firma, geht mit ihr das Wissen, wie die Datei überhaupt funktioniert.

Mehrere Tools, keine gemeinsame Wahrheit. Ein CRM hier, ein Ticketsystem dort, eine Buchhaltungssoftware daneben — jedes mit einer eigenen Version derselben Kundendaten. Niemand traut den Zahlen mehr vollständig, und am Monatsende gleicht jemand von Hand ab, was eigentlich automatisch übereinstimmen sollte.

Standardsoftware, die auf Passung getrimmt wurde. Ein Tool für einen anderen Zweck, mit Workarounds und Zusatzfeldern so lange erweitert, bis es kaum noch an sein ursprüngliches Konzept erinnert — und trotzdem nicht das tut, was gebraucht wird. Jedes Update des Anbieters wird dann zum Risiko, weil niemand mehr sicher weiß, welcher Workaround beim nächsten Versionswechsel bricht.

Wachstum, das die Behelfslösung nicht mehr trägt. Was mit fünf Mitarbeitenden per Zuruf funktioniert hat, bricht bei fünfzig zusammen. Der Moment, in dem das auffällt, ist selten der beste Moment, um erst anzufangen — meist ist er der Moment, in dem der Prozess schon spürbar Fehler produziert.

Berichte, die niemand mehr zusammenstellen will. Wenn eine Monatsauswertung eine Person zwei Tage kostet, weil Zahlen aus drei Systemen von Hand zusammengetragen werden müssen, ist das kein Reporting-Problem, sondern ein Symptom derselben fehlenden gemeinsamen Datengrundlage.

Keines dieser Anzeichen allein rechtfertigt automatisch ein neues System — manchmal reicht eine bessere Konfiguration der bestehenden Software, oder eine Integration zwischen zwei Tools, die bisher nicht miteinander sprechen. Individuelle Software lohnt sich erst, wenn der eigentliche Engpass ein Geschäftsprozess ist, den keine Standardsoftware abbildet, weil er zu spezifisch für das eine Unternehmen ist.

Wie wir ein solches Projekt anfangen

Wir fangen nie mit Code an. Zuerst steht ein Discovery-Workshop: wer nutzt das System, mit welchen Rollen und Rechten, welche Daten müssen rein und raus, was muss protokolliert werden. Daraus entsteht eine schriftliche Spezifikation — kein Pflichtenheft mit hundert Seiten, aber genug, damit beide Seiten dasselbe Projekt meinen.

Danach wird in Phasen geliefert, nicht in einem großen Sprung am Ende. Alle zwei Wochen gibt es eine Version, die tatsächlich benutzt werden kann, nicht nur eine Demo. Das hält die Richtung korrigierbar, statt erst nach Monaten zu merken, dass ein Bildschirm am Bedarf vorbeigebaut wurde.

Rollen, Rechte und Audit-Trails sind dabei kein Zusatzfeature, das man sich später überlegt. Wer im System was sehen und ändern darf, und wer im Nachhinein nachvollziehen kann, wer eine Freigabe erteilt hat — das sind Fragen, die in vielen Branchen ohnehin dokumentiert werden müssen, ob aus Revisionsgründen oder weil ein Kunde das verlangt. Ein System, das diese Fragen von Anfang an mitdenkt, muss sie nicht nachträglich um ein fragiles Berechtigungsmodell herumbauen.

Phase	Was entsteht
Discovery-Workshop	schriftliche Spezifikation, Rollen- und Rechtemodell
Iteration 1–2	nutzbare erste Version, Kernprozess
Weitere Iterationen	Reporting, Exporte, Audit-Trail
Übergabe	vollständiger Quellcode, Repository, Dokumentation

Wem das System gehört

Der Quellcode, das Repository und die Dokumentation gehören der Kundschaft — bei jedem Meilenstein, nicht erst am Projektende. Das ist keine Kulanz, sondern die logische Konsequenz von individueller Software: Ein System, das für ein einziges Unternehmen gebaut wurde, ist wertlos, wenn dieses Unternehmen es nicht selbst weiterbetreiben kann, falls es das will.

Was das kostet

Wir nennen an dieser Stelle bewusst keine Zahl, weil jede Zahl ohne Umfang irreführend wäre. Nach dem Discovery-Workshop steht entweder ein Festpreis pro Phase oder, bei Systemen, die sich absehbar weiterentwickeln, eine monatliche Kapazitätsvereinbarung. Beides folgt aus dem, was der Workshop zeigt — nicht aus einer Preisliste.

Der Unterschied zwischen diesen beiden Modellen ist selten eine Frage des Budgets, sondern eine Frage des Systemtyps. Ein System mit klarem Endzustand — ein Buchungstool mit definiertem Funktionsumfang, ein Portal, das eine bestimmte Aufgabe löst — passt zu einem Festpreis pro Phase. Ein System, das mit dem Geschäft mitwächst und laufend neue Anforderungen bekommt, passt besser zu einer Kapazitätsvereinbarung, weil sich der Umfang von vornherein nicht endgültig festschreiben lässt.

Was oft übersehen wird: die Übergangsphase

Der Wechsel von Excel-Tabellen zu einem echten System passiert selten an einem einzigen Stichtag. In der Praxis läuft eine Zeit lang beides parallel, während Mitarbeitende sich umgewöhnen und alte Daten migriert werden. Diese Übergangsphase gehört in die Planung, nicht in die Überraschungen danach — wir legen deshalb schon im Discovery-Workshop fest, welche historischen Daten übernommen werden müssen und in welcher Reihenfolge Teams auf das neue System umsteigen, statt alle am selben Tag umzustellen.

Die Regel, nach der wir entscheiden

Individuelle Software lohnt sich, sobald der Engpass ein Prozess ist, den kein Standardtool abbildet — nicht, sobald ein Standardtool nur unbequem wird.

Wer sich nicht sicher ist, auf welcher Seite dieser Grenze das eigene Problem liegt, bekommt die ehrlichste Antwort in einem Gespräch, nicht in einem Angebot ungesehen. Mehr zum Vorgehen steht bei individueller Software.