Die Frage taucht meist auf, wenn etwas klemmt: Das eingekaufte System kann genau das eine nicht, was im Betrieb täglich gebraucht wird. Oder es kann zu viel, und niemand findet sich zurecht. Dann steht der Gedanke im Raum, etwas Eigenes bauen zu lassen.
Wir entwickeln Individualsoftware, haben an dieser Antwort also ein Interesse. Umso wichtiger ist uns der Satz, den wir in Erstgesprächen öfter sagen, als man vermuten würde: Dafür braucht ihr uns nicht. Dieser Beitrag soll helfen, das selbst zu erkennen.
1. Gehört der Prozess zum Kerngeschäft?
Das ist die wichtigste Frage, und sie lässt sich meist in einem Satz beantworten. Buchhaltung, Lohnabrechnung, Textverarbeitung – das macht jeder Betrieb, und jeder macht es ungefähr gleich. Dafür gibt es gute Standardprodukte, und eine Eigenentwicklung wäre Geldverschwendung.
Anders sieht es bei dem Ablauf aus, der euer Geschäft ausmacht. Wenn ihr euren Kunden etwas anbietet, das andere so nicht anbieten, dann bildet vermutlich auch kein Standardprodukt diesen Ablauf ab. Genau dort entsteht der Wert einer eigenen Lösung.
2. Wer passt sich an wen an?
Ein Standardprodukt bringt einen Ablauf mit. Meistens ist das gut: Der Ablauf ist erprobt, und ihn zu übernehmen kostet nichts. Kritisch wird es, wenn ihr euren funktionierenden Ablauf ändern müsst, damit die Software mitspielt.
Ein praktischer Test: Zählt, wie viele Arbeitsschritte im Alltag nur deshalb existieren, weil das System es so verlangt. Doppelte Eingaben, Listen in Excel neben dem eigentlichen Programm, ein Zettel, auf dem etwas festgehalten wird, weil es im System kein Feld dafür gibt.
Wenn drei oder mehr solcher Schritte täglich anfallen, rechnet einmal nach: Fünf Minuten am Tag sind bei zehn Mitarbeitern rund 200 Arbeitsstunden im Jahr. Das ist der eigentliche Preis, den ein schlecht passendes System kostet – und er steht auf keiner Rechnung.
3. Wie viele Systeme sind beteiligt?
Viele Betriebe haben nicht ein Problem, sondern fünf Programme, die nichts voneinander wissen. Das Kassensystem kennt die Warenwirtschaft nicht, die Warenwirtschaft nicht die Buchhaltung, und dazwischen sitzt jemand und tippt ab.
Hier ist Eigenentwicklung oft nicht die Antwort – Schnittstellen sind es. Wenn die vorhandenen Systeme fachlich passen und nur nicht miteinander reden, ist es meist deutlich günstiger, sie zu verbinden, als sie zu ersetzen. Das ist auch das kleinere Risiko: Ihr behaltet, was funktioniert.
Zur Eigenentwicklung wird es erst dann, wenn die Systeme fachlich nicht passen und die Verbindung nur ein Symptom kaschieren würde.
4. Was kostet es über fünf Jahre?
Der häufigste Rechenfehler ist der Vergleich von Anschaffungspreis und Entwicklungskosten. Das ist, als würde man Miete und Kaufpreis eines Hauses nebeneinanderlegen.
| Standardsoftware | Eigenentwicklung | |
|---|---|---|
| Zu Beginn | gering bis keine | der größte Posten |
| Laufend | pro Nutzer und Monat, meist steigend | Wartung und Betrieb |
| Bei Wachstum | steigt mit der Nutzerzahl | bleibt weitgehend gleich |
| Bei Änderungen | abhängig vom Hersteller | beauftragbar, kostet aber |
| Beim Ausstieg | Datenexport, oft eingeschränkt | alles bleibt bei euch |
Zur Größenordnung, damit die Frage nicht abstrakt bleibt: Ein abgegrenztes Werkzeug – ein Buchungsportal, ein Gutscheinsystem, eine Tablet-App für den Außendienst – liegt erfahrungsgemäß im unteren fünfstelligen Bereich. Ein System, das euer Kerngeschäft vollständig abbildet, mit Warenwirtschaft, Schnittstellen und Migration von Altdaten, liegt deutlich darüber. Wer euch vor dem Konzeptgespräch eine belastbare Zahl nennt, hat entweder nicht zugehört oder rechnet später nach.
Die ehrliche Rechnung geht so: Nehmt die Lizenzkosten des Standardprodukts für eure Nutzerzahl, multipliziert sie mit sechzig Monaten, addiert den Aufwand für die Umwege aus Frage 2 – und legt das Ergebnis neben das Angebot. Manchmal gewinnt der Standard deutlich. Manchmal überrascht das Ergebnis.
5. Wem gehören die Daten?
Bei Standardsoftware liegen eure Daten meist beim Anbieter. Solange alles läuft, ist das bequem. Relevant wird es in drei Situationen: wenn ihr wechseln wollt, wenn der Anbieter die Preise erhöht, und wenn er den Betrieb einstellt.
Prüft konkret: Bekommt ihr einen vollständigen Export in einem lesbaren Format – nicht nur PDF-Berichte? Wie lange nach einer Kündigung? Und liegen die Daten in Deutschland oder der EU?
Bei Eigenentwicklung ist das eine Frage des Vertrags. Wir übergeben den Quellcode vollständig und hosten auf Wunsch bei euch – nicht aus Großzügigkeit, sondern weil das Gegenteil eine Abhängigkeit schafft, die niemand will. Achtet darauf, dass das schriftlich zugesichert wird; selbstverständlich ist es nicht.
6. Was passiert, wenn der Entwickler ausfällt?
Das ist das ernsteste Risiko bei Individualsoftware, und es wird gern verschwiegen. Ein Standardprodukt hat tausende Nutzer; wenn der Hersteller aufhört, merkt es die Branche und es gibt Alternativen. Bei einer Eigenentwicklung hängt ihr an einem Anbieter.
Vollständig ausschließen lässt sich das nicht. Entschärfen schon – durch drei Punkte, die vor Projektbeginn geklärt sein sollten:
- Quellcode-Übergabe – vollständig, nicht nur bei Vertragsende.
- Dokumentation – Architektur und Betrieb so beschrieben, dass ein fremdes Team einsteigen kann.
- Gängige Technik – verbreitete Sprachen und Datenbanken statt exotischer Speziallösungen, für die es kaum Entwickler gibt.
Wann Eigenentwicklung falsch ist
Vier Situationen, in denen wir von einem Projekt abraten:
- Der Prozess ist selbst noch unklar. Software zementiert Abläufe. Was im Betrieb noch nicht rund läuft, läuft danach nur schneller im Kreis. Erst klären, dann bauen.
- Es geht um eine reine Standardaufgabe. Buchhaltung, Lohn, Kalender – das gibt es fertig und besser, als wir es in vertretbarer Zeit bauen könnten.
- Niemand im Betrieb hat Zeit. Ein Projekt braucht auf eurer Seite eine Person, die entscheiden darf und ansprechbar ist. Ohne sie wird es teuer und trifft trotzdem nicht.
- Es soll ein Personalproblem lösen. Wenn zwei Abteilungen nicht miteinander reden, hilft keine Software.
Der Mittelweg, den viele übersehen
Die Frage wird oft als Entweder-oder gestellt, dabei liegt die Antwort häufig dazwischen: Standardprodukte für alles Allgemeine, und ein eigenes Werkzeug für den einen Ablauf, der euch ausmacht – verbunden über Schnittstellen.
Das ist meist die günstigste und robusteste Variante. Ihr zahlt Entwicklung nur für den Teil, der es wert ist, und behaltet für den Rest die Vorteile fertiger Software: Updates, gesetzliche Anpassungen, breite Nutzerbasis.
- Kerngeschäft eigen, Allgemeines gekauft.
- Erst den Prozess klären, dann Software bauen.
- Über fünf Jahre rechnen, nicht über den Anschaffungspreis.
- Quellcode, Dokumentation und Datenhoheit schriftlich sichern.
- Oft ist die Schnittstelle die bessere Antwort als das neue System.
Häufige Fragen
Wann lohnt sich Individualsoftware?
Wenn der Prozess, um den es geht, zu eurem Kerngeschäft gehört und euch von Wettbewerbern unterscheidet – und wenn kein Standardprodukt ihn abbildet, ohne dass ihr euren Ablauf verbiegt. Für Buchhaltung, Lohn oder Office reicht Standard fast immer. Für den Ablauf, der euer Geschäft ausmacht, oft nicht.
Ist Eigenentwicklung nicht immer teurer?
In der Anschaffung ja, über die Laufzeit nicht zwangsläufig. Standardsoftware kostet pro Nutzer und Monat, dauerhaft und meist steigend. Individualsoftware kostet einmal in der Entwicklung, danach nur noch Wartung und Betrieb. Rechnet beide Varianten über fünf Jahre – vorher lässt sich die Frage nicht beantworten.
Was passiert, wenn der Entwickler ausfällt?
Das ist das wichtigste Risiko bei Individualsoftware und lässt sich vertraglich entschärfen: vollständige Übergabe des Quellcodes an euch, dokumentierte Architektur und der Einsatz gängiger Technologien statt exotischer Speziallösungen. Dann kann ein anderes Team übernehmen. Lasst euch das vor Projektbeginn schriftlich zusichern.
Wie lange dauert so ein Projekt?
Ein abgegrenztes Werkzeug lässt sich in wenigen Wochen liefern, ein System für das Kerngeschäft braucht Monate. Wichtiger als die Gesamtdauer ist, wann ihr das Erste in der Hand habt: Wenn nach vier Wochen nichts Sichtbares vorliegt, stimmt etwas mit dem Zuschnitt nicht.
Können wir klein anfangen?
Das ist meistens der bessere Weg. Ein abgegrenzter Teil, der in Wochen läuft, bringt mehr als ein Großprojekt, das ein Jahr braucht – ihr seht früh, ob die Zusammenarbeit passt, und könnt aufhören, wenn nicht.