Die Frage wird meistens als Entweder-oder gestellt: fertige Software kaufen oder etwas bauen lassen. So gestellt ist sie nicht beantwortbar, weil sie zwei Extreme vergleicht, zwischen denen die realistischen Optionen liegen.
Tatsächlich gibt es vier Positionen, und sie bilden ein Spektrum:
- Standardprodukt – so nutzen, wie es geliefert wird.
- Konfiguriertes Standardprodukt – Felder, Status, Rollen, Vorlagen und Automatisierungen innerhalb des vom Hersteller vorgesehenen Rahmens.
- Open-Source-Anwendung – etabliertes Produkt, selbst oder durch einen Dienstleister betrieben, mit Zugriff auf Daten und Erweiterungspunkte.
- Eigenentwicklung – eine Anwendung, die es so nicht gibt.
Ihr Fall liegt an genau einer Stelle dieses Spektrums. Dieser Beitrag beschreibt, woran Sie erkennen, an welcher.
Nicht das Produkt entscheidet, sondern wie oft Ihr Prozess vom Standard abweicht
Ein Prozess, den zehntausend Betriebe fast gleich abwickeln, gehört in ein Standardprodukt. Ein Prozess, der Ihr Geschäft von anderen unterscheidet, gehört das nicht. Zwischen diesen beiden Polen entscheidet nicht die Branche, sondern die Abweichungsfrequenz.
Fünf Größen ordnen einen Fall zuverlässiger ein als jeder Funktionsvergleich:
Wie oft weicht der reale Ablauf vom Standardweg ab? Einmal im Quartal ist eine Ausnahme. Bei jedem dritten Vorgang ist es der eigentliche Prozess, und der Standardweg ist die Ausnahme.
Wie stark weicht er ab? Ein zusätzliches Feld ist etwas anderes als eine zusätzliche Freigabestufe mit eigener Berechnungslogik und eigener Zuständigkeit.
Ist der Prozess unterscheidend oder nur notwendig? Lohnabrechnung ist notwendig. Die Art, wie Sie ein Angebot kalkulieren, kann unterscheidend sein. Notwendige Prozesse kauft man, unterscheidende baut man – oder man gibt den Unterschied auf.
Wie viele Systeme sind beteiligt? Ab drei Systemen mit manuellen Zwischenschritten ist die Frage selten „welches Produkt”, sondern „welche Verbindung”.
Wie stabil ist der Prozess? Ein Ablauf, der sich in den nächsten zwölf Monaten grundlegend ändern wird, verträgt kein Entwicklungsprojekt. Er verträgt eine Zwischenlösung.
Erst wenn diese fünf Antworten vorliegen, lohnt sich der Blick auf Produkte. Vorher werden Funktionslisten verglichen, die für den eigenen Fall gar nicht relevant sind.
Die vier Positionen im direkten Vergleich
| Position | Sinnvoll, wenn | Der typische Preis dafür |
|---|---|---|
| Standardprodukt | Der Prozess ist üblich, Abweichungen sind selten und verzichtbar. | Der Prozess passt sich der Software an. Änderungen an der Roadmap sind nicht beeinflussbar. |
| Konfiguriertes Standardprodukt | Die Grundfunktion passt, aber Rollen, Status und Formulare müssen anders aussehen. | Konfiguration muss gepflegt werden. Undokumentierte Einstellungen brechen beim nächsten Hauptversionswechsel. |
| Open-Source-Anwendung | Ein etabliertes Produkt bildet den Prozess ab, aber Datenort, Anpassbarkeit oder Betreiberwechsel sind wichtig. | Betrieb, Updates, Backups und Wiederanlauf liegen bei Ihnen oder Ihrem Dienstleister. |
| Eigenentwicklung | Der Prozess ist unterscheidend, verbindet mehrere Systeme oder wird von keinem Produkt sauber abgebildet. | Anschaffungskosten, Weiterentwicklung über Jahre und eine dauerhaft verantwortliche Person. |
Die dritte Spalte ist die wichtigere. Jede Position kostet etwas – nur an unterschiedlicher Stelle und zu unterschiedlichen Zeitpunkten.
Diese Fragen stellen Sie dem Anbieter, bevor Sie unterschreiben
Die meisten Fehlentscheidungen entstehen nicht bei der Auswahl, sondern beim Ausstieg drei Jahre später. Die folgenden Fragen gehören vor die Unterschrift, nicht in die Kündigung. Lassen Sie sich die Antworten schriftlich geben.
Daten und Export
- Gibt es einen vollständigen Export, den wir selbst auslösen können, ohne Ticket und ohne Zusatzkosten?
- Enthält er Anhänge, Verknüpfungen, Historie und Zeitstempel – oder nur die Stammdaten?
- Ist das Format dokumentiert und ohne Ihre Software lesbar?
- Bitte einmal vorführen. Ein Beispielexport aus einem Testsystem beantwortet die Frage in zehn Minuten.
Vertrag und Ausstieg
- Welche Kündigungsfrist gilt, und wie lange bleiben die Daten nach Vertragsende abrufbar?
- Was kostet die Datenübergabe, was kostet eine Migrationsunterstützung?
- Wer besitzt Erweiterungen, die auf unsere Kosten entstanden sind?
- Liegt ein Vertrag zur Auftragsverarbeitung vor? Nach Artikel 28 Absatz 3 DSGVO muss darin geregelt sein, dass der Auftragsverarbeiter nach Abschluss der Verarbeitung alle personenbezogenen Daten „nach Wahl des Verantwortlichen entweder löscht oder zurückgibt”. Wer diese Wahl vertraglich nicht anbietet, hat ein Problem – und Sie hätten es mit ihm.
Konfiguration und Updates
- Welche der von uns benötigten Anpassungen sind in Ihrer Produktdokumentation beschrieben, und welche sind Sonderweg?
- Welche davon überstehen den nächsten Hauptversionswechsel ohne Nacharbeit?
- Wie oft erscheinen Hauptversionen, und wie lange werden ältere mit Sicherheitsupdates versorgt?
Schnittstellen
- Gibt es eine dokumentierte API mit Lese- und Schreibzugriff auf die Daten, die uns interessieren?
- Welche Mengenbegrenzungen gelten, und ab welchem Tarif?
- Ist die API Teil des Produkts oder ein kostenpflichtiges Zusatzmodul?
Preisentwicklung
- Wie ist der Preis heute und bei doppelter Nutzerzahl?
- Welche Funktionen liegen in höheren Tarifstufen, und welche davon brauchen wir absehbar?
Ein Anbieter, der diese Fragen bereitwillig beantwortet, ist nicht automatisch der richtige. Aber ein Anbieter, der bei Export und Ausstieg ausweicht, ist verlässlich der falsche.
„Das konfigurieren wir uns passend” wird häufiger zum teuersten Weg
Konfiguration wirkt wie der sichere Mittelweg: kein Entwicklungsprojekt, kein neues System, alles innerhalb des Produkts. Sie wird teuer, wenn drei Dinge zusammenkommen.
Sie verlässt den dokumentierten Rahmen. Es gibt einen Unterschied zwischen einer vom Hersteller vorgesehenen Einstellung und einer Konstruktion aus Hilfsfeldern, Skripten in einer Low-Code-Ebene und Umgehungen, die zufällig funktionieren. Das Zweite ist Softwareentwicklung – nur ohne Versionsverwaltung, ohne Tests und ohne dass jemand es so nennt.
Sie wird nicht dokumentiert. Konfiguration entsteht in Sitzungen, nicht in Dateien. Nach zwei Jahren weiß niemand mehr, warum ein Status existiert und welcher Bericht davon abhängt. Beim Hauptversionswechsel muss dann rekonstruiert werden, was nie aufgeschrieben wurde.
Sie hängt an einer Person. Häufig an einer externen, tageweise abgerechneten. Der Aufwand fällt nicht als Projekt auf, sondern verteilt sich über Jahre auf Beratungstage, die einzeln klein wirken.
Zwei Prüffragen trennen tragfähige Konfiguration von aufgeschobener Entwicklung:
- Steht die Anpassung so in der Produktdokumentation des Herstellers?
- Übersteht sie das nächste Hauptversionsupdate ohne manuelle Nacharbeit?
Zweimal Nein heißt: Sie entwickeln bereits. Dann ist es ehrlicher – und meist billiger – es auch so zu planen, mit Repository, Dokumentation und benannter Verantwortung. Genau an dieser Stelle beginnt die Entscheidung über individuelle Software sinnvoll zu werden, nicht bei der Frage, ob die Oberfläche gefällt.
Rechnen Sie über fünf Jahre, nicht über die Einführung
Die Einführungskosten sind der Teil, den beide Seiten kennen. Entschieden wird an den anderen.
Stellen Sie für jede Option dieselbe Tabelle auf, mit Ihren eigenen Zahlen:
| Posten | Häufig unterschätzt bei |
|---|---|
| Einführung, Datenübernahme, Schulung | allen Optionen |
| Lizenz oder Abo, hochgerechnet auf die Nutzerzahl in drei Jahren | Standard und konfiguriertem Standard |
| Pflege der Konfiguration, Nacharbeit nach Updates | konfiguriertem Standard |
| Betrieb: Hosting, Backup, Monitoring, Sicherheitsupdates | Open Source |
| Weiterentwicklung nach dem ersten Jahr | Eigenentwicklung |
| Integration in vorhandene Systeme | allen Optionen |
| Einarbeitung bei Personalwechsel | konfiguriertem Standard und Eigenentwicklung |
| Migration hinaus und Archivierung der Altdaten | allen Optionen |
Der letzte Posten wird fast immer vergessen und ist in Deutschland nicht verhandelbar. Nach § 147 Absatz 3 der Abgabenordnung sind Bücher, Inventare und Jahresabschlüsse zehn Jahre, Buchungsbelege acht Jahre und die übrigen aufbewahrungspflichtigen Unterlagen sechs Jahre aufzubewahren; § 257 HGB enthält die entsprechenden handelsrechtlichen Fristen. Die Unterlagen müssen während der gesamten Frist verfügbar und maschinell auswertbar bleiben, und die Finanzbehörde kann bei einer Außenprüfung verlangen, „dass die Daten nach ihren Vorgaben maschinell ausgewertet zur Verfügung gestellt werden”.
Für den Systemwechsel gibt es eine Erleichterung, aber erst später: Sofern noch keine Außenprüfung begonnen hat, genügt es nach § 147 Absatz 6 AO, dass der Steuerpflichtige die Daten „nach Ablauf des fünften Kalenderjahres, das auf die Umstellung oder Auslagerung folgt, […] ausschließlich auf einem maschinell lesbaren und maschinell auswertbaren Datenträger vorhält”. Bis dahin muss die auswertbare Form erhalten bleiben. Praktisch heißt das: Ein Systemwechsel kann bedeuten, das Altsystem noch fünf Jahre lauffähig oder die Daten in einem geprüften Ersatzformat vorzuhalten. Das gehört in die Kalkulation der neuen Lösung, nicht in die Überraschung des Folgejahres.
Hilfreich ist außerdem, dass seit dem 12. September 2025 die EU-Datenverordnung (Data Act, Verordnung (EU) 2023/2854) gilt. Sie schafft einen Rahmen für den Wechsel zwischen Anbietern von Datenverarbeitungsdiensten. Sie ersetzt keine eigene Ausstiegsplanung, gibt Ihnen aber ein Argument in der Vertragsverhandlung.
Wann Eigenentwicklung die falsche Entscheidung ist
Eine Entscheidungshilfe, die nie gegen die eigene Leistung ausfällt, ist Werbung. Diese Fälle sprechen klar gegen ein eigenes System:
- Der Prozess ist gesetzlich getrieben und standardisiert. Lohnabrechnung, Buchhaltung, Kassensysteme, Steuermeldungen. Hier kaufen Sie nicht Funktionen, sondern die Verpflichtung eines Herstellers, Rechtsänderungen nachzuziehen. Das selbst zu tragen, ist in einem KMU praktisch nie wirtschaftlich.
- Niemand kann den Prozess vollständig beschreiben. Wenn drei Beteiligte drei verschiedene Abläufe schildern, ist das Problem nicht die Software. Eine Eigenentwicklung friert dann eine Uneinigkeit in Code ein.
- Es gibt keine verantwortliche Person auf Ihrer Seite. Individuelle Software braucht jemanden, der Entscheidungen trifft, Prioritäten setzt und erreichbar ist. Ohne diese Rolle entstehen teure Missverständnisse.
- Budget nur für Jahr eins. Eine Anwendung ohne Weiterentwicklung veraltet nicht langsam, sondern an einem konkreten Tag – wenn eine Abhängigkeit ein Sicherheitsupdate braucht.
- Der Prozess soll sich absehbar grundlegend ändern. Dann ist ein Zwischenschritt sinnvoller als ein System für einen Zustand, den es bald nicht mehr gibt.
- Der Auslöser ist Unzufriedenheit mit der Oberfläche. Eine unbeliebte, aber funktionierende Software ist selten ein Entwicklungsprojekt wert.
Umgekehrt gibt es einen Fall, in dem die Rechnung fast immer für die Eigenentwicklung spricht: Wenn geschäftskritische Daten in Tabellenkalkulationen liegen, mehrere Personen daran arbeiten und niemand sagen kann, welche Datei die gültige ist. Dann geht es nicht um Komfort, sondern um Nachvollziehbarkeit – nachzulesen in Excel als kritisches System ablösen.
Die realistische Antwort ist meistens eine Kombination
In der Praxis endet die Einordnung selten bei einer der vier Positionen. Sie endet bei einer Kombination, in der das Kernsystem bleibt und nur die relevante Lücke geschlossen wird:
- Standard-CRM plus eigenes Kundenportal
- vorhandenes ERP plus automatisierter Dokumentenworkflow
- Open-Source-Ticketsystem plus Anbindung an die Telefonanlage
- Microsoft 365 plus internes Freigabetool
Der Vorteil ist nicht der geringere Aufwand, sondern der kleinere Fehlerradius. Wenn sich die Entscheidung als falsch erweist, betrifft sie ein Modul und nicht die gesamte Systemlandschaft.
In einer Stunde zur Einordnung
Sie brauchen dafür keinen Beratungsprozess. Nehmen Sie den Prozess, der aktuell am meisten Ärger verursacht, und arbeiten Sie diese Reihenfolge ab:
- Schreiben Sie den realen Ablauf auf – den, der stattfindet, nicht den, der vorgesehen ist. Halten Sie fest, wo Daten aus einem System heraus- und in ein anderes hineinkopiert werden.
- Zählen Sie die Ausnahmen der letzten vier Wochen und teilen Sie sie durch die Gesamtzahl der Vorgänge.
- Entscheiden Sie, ob dieser Prozess unterscheidend oder nur notwendig ist.
- Prüfen Sie beim vorhandenen System, ob eine dokumentierte Konfiguration die Lücke schließt.
- Falls nicht: Stellen Sie zwei bis drei Anbietern die Fragen aus dem Abschnitt oben – vor allem die zum Export.
- Stellen Sie die Fünfjahrestabelle für die zwei aussichtsreichsten Optionen auf.
Danach ist die Frage entweder beantwortet oder so präzise gestellt, dass ein Gespräch mit einem Dienstleister etwas bringt. Beides ist ein Fortschritt gegenüber der Grundsatzdiskussion.
Handlungsaufruf
Wenn Sie an dieser Stelle unsicher sind, hilft ein Blick auf den Ablauf mehr als ein weiterer Produktvergleich. TakFlow ordnet Ihren Fall zwischen Konfiguration, Integration, Open Source und Eigenentwicklung ein – einschließlich der Empfehlung, das vorhandene System zu behalten, wenn es trägt.
Weiterführend: Individuelle Software entwickeln lassen · Open Source, Self-Hosting und Betrieb · Open Source und digitale Souveränität
Quellenhinweise
- § 147 AO – Ordnungsvorschriften für die Aufbewahrung von Unterlagen – Aufbewahrungsfristen, Datenzugriff und die Fünfjahresregel beim Systemwechsel
- § 257 HGB – Aufbewahrung von Unterlagen, Aufbewahrungsfristen – handelsrechtliche Fristen und Anforderungen an die Aufbewahrung auf Datenträgern
- Verordnung (EU) 2016/679 (DSGVO), Artikel 28 – Pflichten des Auftragsverarbeiters, Löschung oder Rückgabe der Daten
- Europäische Kommission: Data Act – Geltungsbeginn 12. September 2025 und Rahmen für den Anbieterwechsel
- Open Source Initiative: The Open Source Definition – was eine Lizenz erfüllen muss, um als Open Source zu gelten