15. Juni 2026 · Morten Babakhani
Die Frage stellt sich in jedem HR-IT-Vorhaben, und sie wird meist mit einem Reflex beantwortet: Standard, weil weniger Risiko. Das ist häufig richtig und nicht immer.
Wann Standard klar überlegen ist
Bei allem, was gesetzlich getrieben ist und sich ändert. Entgeltabrechnung, Sozialversicherungsmeldungen, Bescheinigungswesen, steuerliche Regeln. Diese Logik pflegt der Hersteller, und er pflegt sie für tausend Kunden. Wer das selbst baut, kauft sich eine dauerhafte Verpflichtung, die nichts mit dem eigenen Geschäft zu tun hat.
Auch bei Prozessen, die überall gleich sind: Urlaubsantrag, Stammdatenpflege, Organisationsverwaltung. Hier ist Anpassung an den Standard billiger als Anpassung des Standards.
Wann Eigenentwicklung günstiger wird
Wenn der Prozess Ihr Unterschied ist. Ein Auswahlverfahren, das anders aufgebaut ist als üblich, lässt sich in einem Standardwerkzeug nur mit Verrenkungen abbilden. Diese Verrenkungen kosten bei jedem Release erneut.
Wenn die Anpassung teurer ist als die Neuentwicklung. Das kommt häufiger vor, als man denkt. Sobald mehr als eine Handvoll Erweiterungen nötig sind, sollten Sie beide Wege rechnen — mit Betrieb über fünf Jahre, nicht mit Anschaffungskosten.
Wenn Sie an ein Nutzungsmodell gebunden werden, das nicht passt. Lizenzen pro Person sind für einen Prozess, der einmal im Jahr hundert Menschen betrifft, unwirtschaftlich.
Wenn Sie die Daten nicht hergeben wollen. Manche Verarbeitungen möchte man nicht in einer fremden Cloud haben. Das ist eine legitime Entscheidung, sie kostet und man sollte sie bewusst treffen.
Was in der Rechnung meist fehlt
Auf der Seite der Eigenentwicklung: Betrieb, Bereitschaft, Sicherheitsaktualisierungen, Dokumentation, Einarbeitung neuer Entwickler, Barrierefreiheit, Datenschutz-Folgenabschätzung. Wer nur die Entwicklungszeit rechnet, rechnet um die Hälfte zu niedrig.
Auf der Seite des Standards: Anpassungsaufwand über die Laufzeit, Testaufwand bei jedem Release, Schnittstellenpflege, Schulung bei jeder Oberflächenänderung, und die Verhandlungsposition bei der nächsten Preisrunde.
Wie wir es entscheiden
Wir nehmen Standard, wo Regeln von außen kommen, und bauen selbst, wo der Prozess das Unterscheidungsmerkmal ist. Für unsere eigene Plattform gilt dasselbe Kriterium, das wir Kunden empfehlen: Sie existiert, weil Auswahlverfahren im Standard nicht so abzubilden waren, wie sie fachlich sein müssen — nicht, weil Eigenentwicklung grundsätzlich besser ist.
Und wir schreiben die Entscheidung mit Begründung auf. In zwei Jahren fragt jemand, warum es so gebaut wurde. Wenn dann niemand antworten kann, wird die Diskussion von vorn geführt.
Die Rechnung über fünf Jahre
Beide Wege gehören auf ein Blatt, mit denselben Positionen und derselben Laufzeit. Auf der Kaufseite: Lizenz oder Abonnement, Einführung, Anpassungen, Testaufwand je Release, Schnittstellenpflege, Schulung. Auf der Bauseite: Entwicklung, Betrieb und Bereitschaft, Sicherheitsaktualisierungen, Dokumentation, Einarbeitung neuer Entwickler, Prüfungen.
Zwei Positionen fehlen fast immer, und sie kehren die Rechnung häufig um: der Testaufwand bei zugekauften Systemen mit jedem Release — und die Bereitschaft bei eigenen Systemen, also die Frage, wer nachts erreichbar ist.
Rechnen Sie außerdem den Preispfad: Was kostet das Abonnement im vierten Jahr, wenn die Nutzerzahl steigt? Diese Zahl steht selten im Angebot und entscheidet oft die Sache.