Standard-Tool anpassen vs. eigenes bauen
Ein Standard-Tool deckt achtzig Prozent ab, und die fehlenden zwanzig kosten dich am meisten. Genau hier stellt sich die Frage: Standard-Tool weiter anpassen oder eigenes bauen? Customizing wirkt günstig, weil seine Kosten über Jahre verteilt und kaum sichtbar sind. Dieser Artikel zeigt dir, woran du die Grenzen eines Standard-Tools erkennst, welche versteckten Kosten beim Anpassen entstehen und mit welchen Kriterien du entscheidest, wann sich ein Neubau wirklich rechnet, und wann eben nicht.
Standard-Tool anpassen oder eigenes bauen: die Frage, die fast jeden KMU einmal trifft
Irgendwann steht jeder Betrieb an diesem Punkt. Ein Standard-Tool, ob CRM, ERP, Projektsoftware oder Branchenlösung, deckt den grössten Teil eurer Arbeit gut ab. Aber ein paar Abläufe passen nicht. Ihr arbeitet anders, als das Tool es vorsieht. Also fangt ihr an, es zurechtzubiegen. Ein zusätzliches Feld hier, eine Automatisierung dort, ein Workaround in einer Tabelle daneben. Jeder einzelne Schritt wirkt klein und vernünftig.
Ob ihr überhaupt ein Standard-Tool nutzen sollt, ist gar nicht die Frage. Für die meiste Arbeit ist das die richtige Wahl. Es geht um den Punkt, an dem das Anpassen teurer wird als ein eigenes Werkzeug. Dieser Punkt versteckt sich, und zwar aus einem einfachen Grund: Die Kosten des Anpassens fallen verteilt über Jahre an und tauchen nirgends gebündelt auf, während ein Neubau auf einer einzigen Rechnung steht. Die Zahl, die wehtut, ist sichtbar. Die Zahl, die dich langsam auffrisst, nicht. Das verzerrt jede Entscheidung.
Customizing ist nicht gleich Customizing: drei Stufen mit drei Kostenprofilen
Wer über Anpassen redet, meint oft völlig verschiedene Dinge. Es hilft, Customizing in drei Stufen zu trennen, denn sie verhalten sich grundverschieden.
Konfiguration ist die harmloseste Stufe. Du nutzt Einstellungen, die das Tool ohnehin vorsieht: Felder ein- und ausblenden, Rollen vergeben, Vorlagen anlegen, einfache Regeln definieren. Das ist gewollt, dokumentiert und überlebt jedes Update. Konfiguration ist fast immer richtig und treibt die Kosten kaum.
Eine Stufe weiter geht die Erweiterung über vorgesehene Schnittstellen. Du hängst dich an die API, nutzt Plugins aus einem Marktplatz, baust kleine Automatisierungen mit Zapier oder Make. Das reicht weiter als Konfiguration, bleibt aber im Rahmen dessen, was der Hersteller eingeplant hat. Der Aufwand steigt und bleibt beherrschbar.
Die dritte Stufe ist die gefährliche: Anpassung gegen die Logik des Tools. Hier biegst du das Werkzeug in eine Richtung, für die es nie gebaut wurde. Du erzwingst einen Prozess, den das Datenmodell nicht kennt, zweckentfremdest Felder, hältst Daten parallel in einer Schattentabelle, schreibst Skripte, die tief in die Mechanik greifen. Tückisch ist, dass sich das am Anfang anfühlt wie Stufe eins, aber ein völlig anderes Kostenprofil hat.
Wenn dir also jemand sagt, das lässt sich anpassen
, frag nach, welche Stufe gemeint ist. Stufe eins ist ein Haken im Setup. Stufe drei ist ein Projekt, das nie ganz fertig wird.
Wo ein Standard-Tool an seine Grenzen stösst
Ein Standard-Tool ist für den Durchschnitt vieler Betriebe gebaut, nicht für deinen. Das ist seine Stärke und seine Grenze in einem. Drei Bruchstellen tauchen dabei immer wieder auf.
Die erste sitzt im Datenmodell. Jedes Tool bringt eine feste Vorstellung mit, wie die Welt aussieht: was ein Kunde ist, was ein Auftrag ist, wie das zusammenhängt. Arbeitest du mit mehrstufigen Verträgen, ungewöhnlichen Abrechnungseinheiten oder einer eigenen Produktlogik, musst du dein Geschäft in ein fremdes Schema pressen. Das geht eine Weile gut, bis die Realität schlicht nicht mehr hineinpasst.
Die zweite liegt im Workflow. Das Tool gibt einen Ablauf vor, dein realer Ablauf weicht ab, gewachsen über Jahre und genau auf deinen Markt zugeschnitten. Jetzt hast du die Wahl. Passt du deinen Ablauf ans Tool an, änderst du, wie ihr arbeitet, und stösst auf Widerstand im Team. Passt du das Tool an deinen Ablauf an, landest du direkt in Stufe drei.
Die dritte betrifft die Integration. Kaum ein Tool steht allein. Es muss mit Buchhaltung, Lager, Webshop oder Maschinen reden. Standard-Schnittstellen decken den Standardfall, und genau dort enden sie, wo dein Setup speziell wird. Je eigener deine Systemlandschaft, desto mehr Klebearbeit fällt an, und diese Klebearbeit gehört am Ende niemandem so richtig.
Die versteckten Kosten des Anpassens, die auf keiner Rechnung stehen
Die Lizenz steht klar im Vertrag. Die teuren Posten stehen nirgends.
Da ist zuerst die Wartungslast. Alles, was du gegen die Logik des Tools baust, ist eine Sonderkonstruktion, die du selbst pflegst. Jede dieser Anpassungen ist im Grunde ein kleines Stück Software, undokumentiert, verstanden von ein, zwei Leuten. Gehen die, geht das Wissen mit.
Dann das Update-Risiko. Der Hersteller entwickelt sein Tool weiter, gut so. Nur kann jedes Update deine Anpassungen brechen, vor allem die aus Stufe drei. Statt zu arbeiten, reparierst du Workarounds. Im schlimmsten Fall traust du dich gar nicht mehr zu aktualisieren und sitzt auf einer alten Version fest. Damit verlierst du genau den Vorteil, für den du das Standard-Tool überhaupt gekauft hast.
Der dritte Posten ist die Abhängigkeit, oft Lock-in genannt. Je tiefer dein Geschäft mit einem fremden Werkzeug verwoben ist, desto schwerer kommst du wieder heraus. Steigt der Preis, ändern sich die Bedingungen oder verschwindet eine Funktion, fehlt dir die Verhandlungsmacht. Deine Daten und Abläufe stecken in einem System, das dir nicht gehört.
Am meisten unterschätzt wird der vierte Posten: die Reibung im Alltag. Ein Workaround kostet pro Person ein paar Minuten am Tag. Einzeln fällt das niemandem auf. Über ein Team und ein Jahr summiert es sich zu einem ernsten Betrag, und dazu kommen die Fehler aus Schattentabellen und manuellen Zwischenschritten. Wer das einschätzen will, rechnet besser in Treibern als in Fantasiezahlen: wie viele Personen, wie oft pro Tag, wie fehleranfällig der Schritt ist. Diese Treiber haben wir in was kostet ein MVP genauer aufgeschlüsselt.
Wann sich ein Neubau wirklich rechnet
Im Bau kostet ein eigenes Werkzeug mehr als ein paar Anpassungen am Standard-Tool. Über die Zeit kann es trotzdem die günstigere Variante sein. Der Umschlagpunkt liegt dort, wo mehrere dieser Bedingungen zusammenfallen.
Der angepasste Teil ist dein Kerngeschäft. Wenn ausgerechnet der Ablauf, der nicht ins Standard-Tool passt, dein Unterscheidungsmerkmal ist, gehört er nicht in fremde Hand. Ein Standard-Tool macht dich so gut wie jeden anderen, der dasselbe Tool nutzt. Beim Punkt, der dich vom Wettbewerb abhebt, willst du nicht durchschnittlich sein.
Die Anpassungen haben Stufe drei erreicht und wachsen weiter. Wer längst gegen die Logik des Tools arbeitet und für jede neue Anforderung den nächsten Workaround braucht, baut faktisch schon Software, nur auf einem Fundament, das im Weg steht statt zu tragen.
Die Reibung ist chronisch und skaliert mit dem Wachstum. Wächst der tägliche Mehraufwand mit jedem neuen Mitarbeiter und jedem neuen Kunden, wächst der Schaden mit. Ein eigenes Werkzeug hat hohe Anfangskosten, aber niedrige Reibung im Betrieb. Dieser Tausch lohnt sich, sobald das Volumen gross genug ist.
Du brauchst Kontrolle über Daten, Updates und Roadmap. Wenn Regulierung, Datenschutz oder die Planbarkeit deines Betriebs es nicht zulassen, dass ein externer Hersteller über Funktionen und Preise bestimmt, ist Eigentum am Werkzeug kein Luxus, sondern Voraussetzung.
Wann du die Finger vom Neubau lassen solltest
Genauso wichtig ist der umgekehrte Fall, denn er trifft häufiger zu, als die meisten Anbieter dir sagen. Solange dein Bedarf im Standard liegt, der angepasste Teil nicht dein Kern ist und du mit Konfiguration und sauberen Schnittstellen auskommst, ist der Neubau die teurere Wahl. Bevor du überhaupt so weit denkst, lohnt es sich, eine Standardlösung sauber zu evaluieren, statt sie vorschnell als unpassend abzuhaken. Ein eigenes Tool für ein Problem, das ein Standard-Tool gut löst, ist verschwendetes Geld.
Ein paar Einwände lohnen die nüchterne Prüfung, bevor du dich entscheidest. Das ist auch der Moment, eigenes SaaS für KMU grundsätzlich zu hinterfragen, statt es als Selbstzweck zu verfolgen.
Fühlt sich das Anpassen nur lästig an, oder kostet es messbar? Wenn niemand die Reibung in Personen, Häufigkeit und Fehlern benennen kann, fehlt die Grundlage für einen Neubau. Reibt es heute, oder wächst der Schmerz mit dem Betrieb mit? Ein einmaliger Ärger rechtfertigt keine Eigenentwicklung. Habt ihr jemanden, der das Werkzeug nach dem Launch jahrelang trägt? Eine eigene Software ohne Betrieb dahinter wird selbst zur Reibung, die du eigentlich loswerden wolltest. Drei Mal Nein, und der Standard bleibt die richtige Wahl.
Ein eigenes Werkzeug heisst nicht, alles neu zu bauen
Eigenes Bauen bedeutet nicht, jahrelang an einer Komplettlösung zu sitzen, bevor irgendetwas nutzbar ist. Der sinnvolle Weg läuft andersherum: den einen Ablauf herauslösen, der im Standard-Tool am meisten klemmt, und genau dafür ein schlankes Werkzeug bauen. Für alles andere bleibt das Standard-Tool im Einsatz. Du ersetzt nicht das System, du ersetzt das Stück, das die meiste Reibung erzeugt.
Genau dafür bauen wir Individualsoftware für KMU. Dabei zählt nicht nur, dass eine Software entsteht, sondern dass sie über Jahre läuft, gewartet wird und mit dem Betrieb mitwächst. Wir kennen den Unterschied aus eigener Erfahrung, weil wir mit Wortfreunde und Reazon eigene Produkte nicht nur gebaut haben, sondern selbst betreiben. Wer ein Werkzeug auch betreibt, baut es anders: weniger spektakulär, dafür wartbar, mit Blick auf die Kosten, die erst nach dem Launch entstehen. Das ist der Unterschied zwischen einer Software, die du besitzt, und einer, die dich besitzt.
Und die Erwartung ans Ergebnis sollte stimmen. Ein eigenes Werkzeug verschiebt die Kosten nach vorn: höher beim Bau, niedriger im Betrieb, dafür voll in deiner Kontrolle. Es ist kein Statussymbol. Es ist genau dann richtig, wenn das Anpassen eines Standard-Tools dich über die Jahre teurer zu stehen kommt als der Neubau, gemessen am ganzen Zeitraum und nicht am ersten Rechnungsblatt.
Drei Fragen, die die Entscheidung tragen
Wenn du an diesem Punkt stehst, dampft sich die Abwägung auf drei Fragen ein. Liegt der Teil, der klemmt, in deinem Kerngeschäft oder am Rand? Am Rand bleibt das Standard-Tool. Arbeitest du noch innerhalb vorgesehener Einstellungen und Schnittstellen, oder schon gegen die Logik des Tools? Wer gegen die Logik arbeitet und nicht mehr zurückkann, baut ohnehin Software. Wächst die tägliche Reibung mit deinem Betrieb mit, oder ist sie ein einmaliger Schmerz? Skaliert sie mit, skaliert der Schaden.
Drei Mal eher Eigenbau
ist ein deutliches Signal. Drei Mal eher Standard
genauso. Liegst du dazwischen, ist es selten falsch, mit dem Standard-Tool weiterzumachen und nur die teuersten Workarounds gezielt durch ein kleines eigenes Werkzeug zu ersetzen, statt alles auf einmal umzuwerfen. Die beste Entscheidung folgt deinen echten Treibern, nicht dem Bauchgefühl, selbst gebaut sei immer besser oder Standard immer günstiger.
Weitere Artikel
- KI: eigenes Modell, API oder fertiges Tool?
- Pflichtenheft, User Story oder Prototyp: wie du Anforderungen festhältst
- Branchensoftware vs. Individuallösung
- Web-App, Mobile-App oder PWA: was passt zu deinem Produkt?
- Eigene Infrastruktur statt Cloud: wann es sich lohnt
- Outbound vs. Inbound: womit ein junges SaaS startet