Wann sich ein eigenes System lohnt und wann ein fertiges Werkzeug reicht

Zwei Anfragen, die sich fast gleich anhören, liegen manchmal nur wenige Wochen auseinander. Die eine: „Können Sie uns nicht einfach eine eigene Software bauen — dann sind wir unabhängig.” Die andere, seltener ausgesprochen, aber genauso oft gemeint: „Müssen wir das wirklich selbst bauen, oder reicht nicht auch ein fertiges Tool?” Meine Antwort fällt in beiden Fällen unterschiedlich aus, obwohl die Frage fast identisch klingt. Der Grund dafür ist selten die Technik.

Zwei Fragen, eine Verwechslung

Die meisten Gespräche über „Eigenentwicklung oder fertiges Werkzeug” drehen sich um Funktionsumfang: Kann das Standard-Tool das, was wir brauchen? Kann eine Eigenentwicklung mehr? Das ist die falsche erste Frage, weil sie fast immer mit „kommt darauf an, wie viel wir investieren” beantwortet wird — mit genug Budget kann eine Eigenentwicklung praktisch alles, was ein Standard-Tool kann, plus das, was speziell für einen Betrieb zugeschnitten ist. Funktionsumfang ist also selten das eigentliche Entscheidungskriterium. Er verschiebt die Frage nur.

Die Frage, die tatsächlich entscheidet, stelle ich inzwischen vor jedem Funktionsvergleich: Wer trägt dieses System, wenn es in drei Jahren noch laufen soll — nicht am Tag der Einführung, sondern an einem x-beliebigen Dienstag drei Jahre später, wenn niemand mehr an das Projekt denkt, das es hervorgebracht hat?

Was ein Standard-Werkzeug mitbringt, das eine Eigenentwicklung nicht automatisch hat

Ein am Markt etabliertes Werkzeug — eine Warenwirtschaft, ein Ticketsystem, eine Buchhaltungssoftware — hat einen Hersteller, dessen Geschäftsmodell genau darin besteht, dieses eine Produkt über Jahre zu pflegen. Sicherheitslücken werden geschlossen, ohne dass der Kunde einen Auftrag dafür erteilen muss. Neue gesetzliche Anforderungen — eine geänderte Kassenordnung, eine neue Datenschutzvorgabe — fließen ins Produkt ein, weil sie für alle Kunden gleichzeitig relevant sind und sich der Aufwand für den Hersteller lohnt. Und findet ein Betrieb den ursprünglichen Ansprechpartner nicht mehr, gibt es trotzdem eine Dokumentation, ein Support-Team, eine Community aus tausend anderen Kunden, die dieselben Fragen schon einmal gestellt haben.

Nichts davon ist selbstverständlich bei einer Eigenentwicklung. Eine maßgeschneiderte Lösung hat in aller Regel genau einen Entwickler oder ein einziges kleines Team, das sie wirklich versteht. Fällt diese Verbindung weg — Kündigung, Insolvenz des Dienstleisters, schlicht andere Prioritäten —, bleibt ein System zurück, das niemand im Betrieb selbst warten kann und das kein zweiter Dienstleister ohne Weiteres übernimmt, weil ihm die stille, nirgends aufgeschriebene Logik fehlt, die sich über Monate in den Code eingeschlichen hat.

Was eine Eigenentwicklung kann, das kein Standard-Werkzeug bietet

Umgekehrt gilt genauso: Ein Standard-Werkzeug ist für den Durchschnitt aller seiner Kunden gebaut, nicht für einen einzelnen Betrieb. Wo ein Prozess wirklich eigen ist — weil er den Kern dessen ausmacht, was einen Betrieb von seinem Wettbewerb unterscheidet —, zwingt ein fertiges Tool früher oder später zu einem Kompromiss. Entweder der Prozess passt sich dem Werkzeug an, oder es entstehen Zusatztabellen, Umwege über Excel, manuelle Übertragungen zwischen Systemen, die genau die Fehleranfälligkeit erzeugen, die eine Software eigentlich vermeiden sollte.

Unser eigenes Auftrags-Cockpit ist dafür das Beispiel, das ich am besten kenne, weil ich täglich darin arbeite. Es bildet ab, wie bei uns Anfrage, Angebot, Auftrag und Wartungsvertrag zu einem einzigen zusammenhängenden Vorgang gehören — eine Struktur, die aus der Art entstanden ist, wie wir arbeiten, nicht umgekehrt. Kein am Markt verfügbares Tool hätte das ohne massive Zusatzkosten in der Anpassung nachgebildet, und selbst dann wäre es fremdes Denken in einem eigenen Prozess geblieben. Für diesen einen Teil unseres Geschäfts lohnt sich der dauerhafte Aufwand einer Eigenentwicklung, weil er genau dort ansetzt, wo wir uns von anderen unterscheiden wollen.

Die Frage, die vor jeder Empfehlung steht

Ein Standard-Prozess — Buchhaltung, Zeiterfassung, ein CRM für den durchschnittlichen Vertriebsalltag — profitiert fast immer von einem etablierten Werkzeug, weil der Hersteller die Tragfähigkeit über Jahre bereits mitliefert. Ein wirklich eigener Prozess kann eine Eigenentwicklung rechtfertigen — aber nur, wenn die Tragfähigkeit aktiv eingeplant wird, nicht als Nebengedanke, sondern als eigene Position im Budget: Wer kennt das System außer der ursprünglichen Entwicklerin oder dem ursprünglichen Entwickler? Gibt es eine Dokumentation, mit der ein zweiter Dienstleister in vertretbarer Zeit einsteigen könnte? Ist ein Wartungsvertrag vereinbart, der über den Projektabschluss hinausreicht, oder endet die Verantwortung faktisch mit der letzten Rechnung?

Diese Fragen klingen nüchtern, fast bürokratisch. Sie entscheiden trotzdem darüber, ob ein System in drei Jahren ein verlässliches Werkzeug ist oder eine stille Altlast, die niemand anzufassen wagt, weil niemand mehr versteht, warum sie so gebaut wurde, wie sie gebaut wurde.

Ein Test in drei Schritten

Bevor ich einem Kunden eine Eigenentwicklung vorschlage — statt, wie es öfter vorkommt, von einer abzuraten —, gehe ich drei Fragen durch, in genau dieser Reihenfolge.

Ist die Aufgabe eine Standard-Aufgabe oder eine Eigenheit des Betriebs? Buchhaltung ist überall ähnlich genug, dass ein etabliertes Tool sie besser abdeckt, als es eine Neuentwicklung je könnte. Der Prozess, mit dem ein Betrieb tatsächlich Kunden gewinnt oder Aufträge abwickelt, ist es oft nicht.

Gibt es für die Standard-Aufgabe einen Anbieter, der voraussichtlich auch in fünf Jahren noch existiert? Ein kleines, gerade erst gestartetes SaaS-Tool trägt ein eigenes Risiko — nur eines, das der Hersteller trägt, nicht der Kunde selbst, solange die Daten exportierbar bleiben.

Wer im eigenen Betrieb — nicht bei uns als Dienstleister — würde in drei Jahren wissen, dass es dieses System überhaupt gibt und wofür es gebaut wurde? Diese dritte Frage wird am seltensten gestellt und ist am wichtigsten. Eine Eigenentwicklung ohne eine Antwort darauf ist keine Investition in die Zukunft des Betriebs. Sie ist ein Risiko, das erst in drei Jahren fällig wird.

Der teuerste Fehler ist nicht die falsche Wahl, sondern die unbeantwortete Frage

In den Projekten, die später tatsächlich Ärger gemacht haben, lag der Fehler fast nie darin, dass jemand sich bewusst für die falsche Seite entschieden hat. Er lag darin, dass die Frage nie gestellt wurde. Ein Standard-Tool wurde eingeführt, ohne zu prüfen, ob der eigene Prozess wirklich zum durchschnittlichen Anwendungsfall passt — und drei Jahre später arbeitet ein ganzes Team mit Umwegen um eine Software herum, die eigentlich Arbeit abnehmen sollte. Oder eine Eigenentwicklung wurde beauftragt, ohne die Tragfähigkeit mitzudenken — und drei Jahre später sitzt ein Betrieb auf einem System, das funktioniert, aber niemand mehr anfassen will, aus Angst, etwas kaputt zu machen, das niemand mehr versteht.

Beides lässt sich vermeiden, nicht durch die eine richtige Antwort, sondern durch die Gewohnheit, die Frage überhaupt zu stellen, bevor eine Entscheidung fällt, die sich nicht mehr ohne Weiteres zurücknehmen lässt.

Was das für Ihre nächste Entscheidung bedeutet

Wenn bei Ihnen gerade eine ähnliche Entscheidung ansteht — ein neues Werkzeug für einen wiederkehrenden Prozess, oder die Frage, ob sich für einen ganz eigenen Ablauf eine maßgeschneiderte Lösung lohnt —, ist der ehrlichste erste Schritt nicht der Funktionsvergleich. Es ist die Frage, wer dieses System in drei Jahren trägt, wenn das aktuelle Projekt längst abgeschlossen ist. Wenn Sie diese Frage für Ihren konkreten Fall gemeinsam durchgehen möchten: Schreiben Sie mir. Ein erstes Gespräch kostet nichts, und danach ist meistens klar, auf welcher Seite Ihr Vorhaben steht.