In jedem Unternehmen, das wir betreten, kommt früher oder später dieselbe Frage: „Sollen wir etwas Eigenes bauen oder etwas Fertiges kaufen?". „Kommt darauf an" ist wahr, aber nutzlos. Dieser Text zeigt, worauf es wirklich ankommen sollte — und welche Fallen auf beiden Seiten lauern, wenn Sie ein Unternehmen mit 10–50 Personen führen und keinen Konzern mit eigenem Entwicklerteam.
In der Praxis fallen die meisten KMU in eine von zwei Extremfallen. Die erste lautet: „Kaufen wir Fertiges, der Anbieter versichert, dass 90 % der Anforderungen abgedeckt sind" — und ein Jahr später stellt sich heraus, dass es nur 55 % sind, und der Rest besteht aus teuren „Customizings", die sich nicht mehr updaten lassen. Die zweite lautet: „Bauen wir es selbst, am Markt passt sowieso nichts" — und nach zwei Jahren hat das Unternehmen eine Anwendung, die nur ein einziger Entwickler versteht, der gerade gekündigt hat.
Beides lässt sich vermeiden. Man muss nur zweimal pro Woche an etwas Langweiliges denken: Ist das, was wir gerade auswählen, der Kern unseres Geschäfts — oder nur ein Werkzeug daneben?
Standard: kaufen. Warum fertige Software meistens gewinnt
Wenn der Prozess, den Sie unterstützen wollen, derselbe ist, den tausend andere Unternehmen ebenfalls fahren — Buchhaltung, Lohn, Lager, Fakturierung, einfaches CRM — dann ist mit 95 % Wahrscheinlichkeit ein fertiges System günstiger, sicherer und besser gepflegt als alles, was Sie auf Bestellung entwickeln lassen.
Warum? Weil die reine Entwicklung nur die Spitze des Eisbergs ist. Darunter sitzen:
- Wartung — Updates für neue Steuerformate (in Polen: JPK, KSeF), neue E-Rechnungs-Standards, MwSt.-Änderungen, DSGVO-Anpassungen. Der Anbieter von Comarch Optima, enova365 oder Subiekt GT macht das einmal für alle Kunden. Bei einer Eigenentwicklung zahlen Sie jede einzelne Änderung selbst.
- Sicherheit — Patches, Audits, Passwort-Richtlinien, MFA-Integration. Ein vernünftiges SaaS hat das in der Lizenz inkludiert.
- Branchenwissen — ein fertiges ERP kennt Split Payment, Reverse Charge, Sondersteuerregelungen. Ihr Entwickler lernt das auf Ihre Kosten.
- Kontinuität — wenn das Unternehmen von 15 auf 35 Personen wächst, skaliert das Standardsystem einfach über Lizenzen. Eine Eigenentwicklung muss oft neu geschrieben werden.
Kurzfassung: Bauen Sie keine eigene Buchhaltung, keine eigene Lohnabrechnung, kein eigenes CRM von Grund auf. Das sind Bereiche, in denen der Produktwettbewerb dicht ist und Sie dort keinen Wettbewerbsvorteil aufbauen können.
Wann Eigenentwicklung tatsächlich Sinn ergibt
Es gibt aber Situationen, in denen fertige Software grundsätzlich nicht passt und der Versuch, sie per Anpassung zurechtzubiegen, schlechter ausgeht als ein Projekt von null. Die Anzeichen:
- Kernprozess, in dem Sie sich vom Markt unterscheiden. Sie haben eine eigene Kalkulationslogik, einen eigenen Produktkonfigurator, eine eigene Produktionsplanung, die der Wettbewerb nicht hat. Genau das ist Ihr Vorteil — und der passt nicht in den Standardrahmen eines fertigen ERP.
- Ein wiederkehrender, hochvolumiger Prozess, den kein fertiges Modul abdeckt. Häufig ist das ein Variantenkonfigurator, ein Angebotskalkulator, ein Generator für technische Dokumente oder ein Dashboard für Vorarbeiter in der Produktion.
- Eine Integration, die der Markt nicht anbietet. Ein Lieferant verlangt Daten in einem ungewöhnlichen Format, eine Behörde fordert einen speziellen Bericht, ein Großkunde schreibt sein eigenes EDI vor. All das taucht in Angeboten als „Anpassung" auf — ein kleines Spezialtool wird günstiger.
- Ein klar umrissener, schmaler Funktionsumfang. Eine Anwendung, die einen einzigen Schmerzpunkt löst (Angebot, Kalkulation, Produktionsmeldung), hat 80 % weniger Umfang als ein „umfassendes ERP" — und ist deshalb realistisch in 2–4 Monaten umsetzbar, nicht in 2 Jahren.
Faustregel: Bauen Sie, was Ihr Wettbewerbsvorteil ist. Kaufen Sie alles andere.
Ein Beispiel aus der Praxis — wenn sich die Eigenentwicklung in einem halben Jahr amortisiert
Bei einem unserer Kunden — einem 28-Personen-Hersteller von Stahlkonstruktionen — sah die Lage so aus. Sie hatten enova365 für Buchhaltung, Lager und Verkauf. Mit dem fertigen System keine Probleme. Aber die Angebotserstellung war ein Albtraum: Jedes Angebot kostete einen Konstrukteur 30–120 Minuten in Excel mit Makros — Stahlverbrauch, Lackierkosten, Transport, Marge. Es gab einen Konstrukteur, und es gingen 40 Anfragen pro Woche ein. Die Hälfte bekam nie rechtzeitig ein Angebot, Kunden wanderten ab.
Der enova-Partner bot ein „dediziertes Angebotsmodul" für rund 90 000 PLN plus Wartung an. Nach Sichtung des Umfangs zeigte sich, dass 40 % der eigentlichen Logik damit nicht abgedeckt wären und ein paralleler Excel weiterhin nötig bliebe. Wir bauten stattdessen eine separate Webanwendung in .NET, integriert mit enova über REST API: Der Produktkatalog synchronisiert sich aus enova heraus, angenommene Angebote landen als Verkaufsbeleg in enova, die Rechnung läuft anschließend den Standardweg.
Kosten: rund 65 000 PLN, 3 Monate Arbeit. Ergebnis: Die Angebotserstellung sank von 30–120 Minuten auf 6–8 Minuten. Der Konstrukteur war kein Engpass mehr. Die Zahl der ausgestellten Angebote pro Monat stieg von etwa 90 auf über 250. Nach 5 Monaten hatte sich das Projekt allein durch die höhere Angebots-Auftrags-Konvertierung amortisiert. Die Anwendung ist klein (ein Kalkulator-Bildschirm, ein Listen-Bildschirm), die Dokumentation umfasst 12 Seiten, ein neuer Entwickler ist nach einem Tag eingearbeitet.
Das war kein „Eigen-ERP". Es war ein kleines Werkzeug, das eine Aufgabe besser löst als jedes Produkt am Markt. Deshalb hat es funktioniert.
Die „Customizing"-Falle fertiger Systeme
Das Schlechteste aus beiden Welten ist die Mitte: ein Standard-ERP kaufen und dann auf sich zuschneiden. Jede einzelne Änderung klingt im Angebot sinnvoll („wir ergänzen ein Feld, ändern einen Workflow, bauen einen eigenen Ausdruck") — aber nach drei Jahren haben Sie ein System, das:
- ohne erneutes Umbauen Ihrer Anpassungen nicht mehr aktualisierbar ist
- teurer in der Wartung ist als eine Eigenentwicklung wäre
- immer noch nicht genau das tut, was Sie wollten
- an einen einzigen Implementierungspartner gefesselt ist
Wir haben Projekte gesehen, in denen die Summe der „kleinen Änderungen" an einem Standard-ERP über drei Jahre die Kosten für eine komplett dedizierte Anwendung von null überstieg. Und die Lizenz lief weiter, weil „dort ja die Buchhaltung drinsteckt".
Regel: Wenn schon in der Implementierungsphase mehr als drei Anpassungen auf Code-Ebene angeboten werden, ist das ein Warnsignal. Entweder haben Sie das falsche System gewählt — oder das, was Sie darin tun wollen, sollte eine eigene Anwendung sein, per API angebunden.
Ein kurzer Entscheidungstest
Bevor Sie etwas unterschreiben, beantworten Sie ehrlich diese fünf Fragen:
- Ist der Prozess, den die Software unterstützen soll, Kern Ihres Wettbewerbsvorteils — oder nur Backoffice-Infrastruktur?
- Gibt es ein fertiges System, das mindestens 80 % der Anforderungen ohne Code-Anpassung abdeckt? (Nicht „mit Customizing". Ohne.)
- Ist Ihr Prozess stabil genug, dass Sie ihn in den nächsten 3 Jahren nicht stark ändern werden?
- Haben Sie eine Person als fachlichen Projektverantwortlichen — nicht aus der IT, sondern jemand, der den Prozess in- und auswendig kennt?
- Haben Sie nach dem Go-live Budget für Wartung eingeplant? (Eine Eigenentwicklung ohne Wartungsbudget stirbt innerhalb von 2 Jahren.)
Drei oder mehr „Ja" bei Fragen 2 und 3 — kaufen. Drei oder mehr „Ja" bei 1, 4 und 5, „Nein" bei 2 — Eigenentwicklung in Betracht ziehen. „Nein" bei Frage 4 — bauen Sie gar nichts, solange diese Person nicht existiert.
Wie weiter
Die Build-vs-Buy-Entscheidung ist selten ein sauberes Entweder-Oder. In der Praxis fahren die meisten KMU, mit denen wir arbeiten, eine Hybrid-Konfiguration: ein fertiges ERP für Buchhaltung, Lager und Personal (Comarch Optima, enova365 oder Subiekt) plus eine oder zwei dedizierte Punktanwendungen für die wirklich differenzierenden Prozesse, per API integriert. So sieht ein gesunder IT-Stack in einem Unternehmen mit 20–40 Personen aus.
Wenn Sie über ein konkretes Projekt nachdenken und nicht wissen, auf welche Seite dieser Grenze es gehört — wir helfen Ihnen gerne, das durchzudenken. Das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Bauen Sie, was Ihr Wettbewerbsvorteil ist. Kaufen Sie alles andere. Der Rest ist Detail.