Individualsoftware vs Standardsoftware: wann sich der Eigenbau lohnt

Deutsche Käufer stellen uns die Frage fast immer in derselben Formulierung: Individualsoftware oder Standardsoftware? Die Wörter sind nicht Marketing. Individualsoftware ist Software, die für einen Auftraggeber geschrieben wird. Standardsoftware ist ein Produkt, das viele Unternehmen gleich konfigurieren. Meist kommt die Frage, nachdem schon ein Salesforce-, SAP- oder Branchentool-Angebot auf dem Tisch liegt, und nachdem jemand intern gesagt hat, man könne das doch „einfach anpassen".

Wir bauen Individualsoftware. Das macht uns parteiisch. Es macht uns auch zu der Partei, die am häufigsten nein sagt. Ein großer Teil unserer Software-Beratung besteht darin, einem Gründer oder IT-Leiter zu erklären, warum Standard die bessere erste Antwort ist. Der Rest besteht darin, die Fälle zu finden, in denen Standard über drei Jahre die teurere Lüge ist.

Wann Standardsoftware die richtige Antwort ist

Standardsoftware gewinnt, wenn Ihr Prozess dem Markt gleicht. Buchhaltung gleicht Buchhaltung. Ein Vertriebs-CRM für ein klassisches Innendienst-Außendienst-Modell gleicht tausend anderen. Projekttracking ohne branchenspezifische Pflichtfelder ebenfalls.

In diesen Fällen kaufen Sie nicht nur Software. Sie kaufen den Prozess des Herstellers, seine Updates, seine Schulungsunterlagen und eine Community, die dieselben Kanten schon abgeschliffen hat. Das ist wertvoll. Der Bitkom-Arbeitsmarktbericht zur unbesetzten IT-Stelle in Deutschland erinnert jedes Jahr daran, dass interne Kapazität knapp ist. Standardsoftware ist eine Art, knappe Entwicklerstunden nicht für gelöste Probleme auszugeben. Die Bitkom-Erhebung zu unbesetzten IT-Stellen ist hier die nützliche Folie: Wer Custom für Commodity-Prozesse bestellt, kauft sich in denselben Engpass ein, den der Markt schon hat.

Drei Tests, ob Standard reicht:

1. Können Sie den Prozess der Software beugen, ohne die Marge zu verlieren?
2. Bleiben mehr als zwei Drittel der Standardfunktionen angeschaltet?
3. Liegt die kritische Integration in einem vom Hersteller dokumentierten Konnektor, nicht in einer Sonderlocke?

Drei Ja: kaufen. Nicht bauen.

Wann Individualsoftware über drei Jahre günstiger ist

Custom lohnt sich, wenn der Prozess selbst die Differenz zum Wettbewerb ist. Ein Dispositionsalgorithmus, den die Konkurrenz nicht abonnieren kann. Ein Underwriting-Flow, der eure Schadenhistorie kennt. Ein Betriebsablauf, den kein Branchenpaket abbildet, weil eure Kunden ihn so verlangen.

Dann ist Standardsoftware keine Ersparnis. Sie ist eine Steuer auf jede Abweichung. Jede Abweichung wird zum Plugin, zum Custom-Objekt, zum teuren Beratungstag des Integrators. Nach 18 Monaten habt ihr gezahlt wie für Individualsoftware, besitzt aber den Kern nicht.

Wir rechnen Build vs Buy über drei Jahre, nicht über das erste Angebot. In den Scoping-Gesprächen, die wir führen, kippt die Rechnung oft an drei Stellen:

• Lizenz plus Sitze. Was im ersten Jahr freundlich aussieht, skaliert mit Köpfen, Transaktionen oder verbundenen Systemen.
• Anpassung. Der Integrator verkauft „konfigurierbar". Konfigurierbar endet, sobald euer Pflichtfeld nicht im Datenmodell vorkommt.
• Prozessbruch. Jemand im Betrieb arbeitet am System vorbei, in Tabellen, weil die Standardsoftware den echten Ablauf nicht abbildet. Diese Schatten-IT ist Teil der Vollkosten, auch wenn sie in keiner Lizenzzeile steht.

Unser Kostenleitfaden für App-Entwicklung in Deutschland zeigt, was ein eigener Build in diesem Markt typischerweise kostet. Zu Kosten, Leistungen und Auswahl des Partners siehe unseren Leitfaden zur Individualsoftware in Deutschland. Unser Angebotsvergleich zeigt, wie man Custom-Angebote normalisiert, bevor man sie gegen eine Lizenz legt. Beides gehört in dieselbe Tabelle.

Die teure Mitte: Standard, das sich wie Custom anfühlt

Das häufigste Scheitern, das wir später aufräumen, ist nicht „wir haben Custom gebaut und hätten kaufen sollen". Es ist „wir haben Standard gekauft und dann so lange umgebaut, bis es Custom war".

Typisches Muster: Ein CRM oder ERP geht live in der Standardkonfiguration. Nach sechs Monaten kommen Pflichtfelder, Sonderpreise, eine Anbindung an ein altes Warenwirtschaftssystem, eine Ausnahme für den größten Kunden. Nach zwölf Monaten liegt Custom-Code auf einem fremden Kern. Release-Notes des Herstellers werden zu Risiko-Terminen. Das Datenmodell gehört immer noch dem Anbieter.

An dem Punkt habt ihr drei schlechte Optionen: weiterzahlen und hoffen, den Custom-Anteil einfrieren, oder herausschneiden und neu bauen. Herausschneiden ist teurer als der Build, den ihr im ersten Jahr abgelehnt habt. Deshalb gehört die Frage „was muss in unserem Repo liegen?" an den Anfang, nicht an das Exit-Gespräch.

Eine Entscheidung in 90 Minuten, nicht in 80 Folien

Wir brauchen für Build vs Buy keinen Strategie-Offsite. Drei Fragen, auf einem Blatt, mit den Leuten im Raum, die den Prozess wirklich fahren:

Welcher Prozess erzeugt die Marge? Alles andere ist Commodity, bis das Gegenteil bewiesen ist. Commodity kauft man.

Was darf sich ändern, wenn die Software es verlangt? Wenn Vertrieb den Ablauf umbauen darf, ist Standard fast immer richtig. Wenn der Kunde den Ablauf diktiert, ist Custom der Default.

Was muss uns gehören, wenn der Anbieter die Preise verdoppelt? Code, Datenmodell, Integrationen, Trainingsdaten. Was auf dieser Liste steht, darf nicht in einer Lizenz stecken, die ihr nicht kontrolliert.

Was nach 90 Minuten unklar bleibt, ist der Custom-Kandidat. Nicht das ganze Unternehmen. Ein Prozess. Den scoped ihr eng, wie ein MVP, und lasst den Rest Standard.

Wenn ihr schon Angebote habt, schickt uns Scope und Lizenzmodell. Wir sagen euch, welche Zeile Custom ist und welche ihr kaufen solltet: Sprechen Sie mit uns.