Make or Buy Software: kaufen, ergänzen oder selbst entwickeln?

Welche Entscheidung treffen Sie eigentlich?

Bei Make or Buy Software werden häufig drei Fragen zusammengezogen. Erstens: Nutzen Sie ein vorhandenes Produkt oder entwickeln Sie eine eigene Lösung? Zweitens: Wer erstellt und verändert die Software – Ihr Team, ein Partner oder beide? Drittens: Wer betreibt sie und übernimmt Support, Sicherheitsarbeit und Wiederherstellung?

Diese Entscheidungen können unterschiedlich ausfallen. Ein Entwicklungspartner kann Individualsoftware für Sie bauen; damit kaufen Sie Entwicklungsleistung und kein fertiges Standardprodukt. Ihr eigenes Team kann Standardsoftware konfigurieren und integrieren. Eine selbst entwickelte Anwendung kann wiederum auf einer gemieteten Cloudplattform laufen. „Selbst entwickeln“ bedeutet deshalb nicht automatisch, alles intern herzustellen und zu betreiben. Der offizielle Build-or-Buy-Beitrag des Government Digital Service beschreibt sowohl Kombinationen als auch die Beauftragung von Spezialisten für den eigenen Bau.

Standardsoftware wird für einen übergreifenden Bedarf angeboten. Sie passen Einstellungen, Rollen und vorgesehene Abläufe an Ihren Einsatz an. Individualsoftware wird für einen konkret abgegrenzten eigenen Bedarf entwickelt. Beide können weitere Komponenten und Dienste voraussetzen. Für Ihren Vergleich zählt deshalb der tatsächlich benötigte Funktionsumfang und nicht allein das Etikett.

Unterscheiden Sie außerdem Konfiguration von tiefen Anpassungen. Eine Einstellung innerhalb vorgesehener Produktfunktionen ist etwas anderes als eigener Code, der interne Strukturen eines Produkts voraussetzt. Die GDS-Guidance zur Beschaffungsstrategie benennt die Folgen solcher Anpassungen für Wartung, Weiterentwicklung und spätere Ablösung. Prüfen Sie diese Folgen bereits vor der Entscheidung.

Vier Optionen für eine bestehende SaaS-Lösung

Bei einer neuen Aufgabe beginnt der Vergleich mit verfügbaren Lösungen und möglichem Eigenbau. Wenn Sie bereits eine SaaS einsetzen, gibt es zusätzlich eine Ausgangslage mit eingespielten Nutzern, Daten und Integrationen. Nehmen Sie sie als eigene Option auf. Sonst vergleichen Sie zwei Veränderungen, ohne zu prüfen, ob eine Veränderung überhaupt nötig ist.

Das ist eine Prüfreihenfolge, kein verstecktes Ranking. Eine zusätzliche eigene Komponente kann sinnvoll sein, aber auch die gesamte Landschaft komplizierter machen. Ebenso ist eine Lizenzoptimierung nur dann eine ausreichende Antwort, wenn die fachlichen Anforderungen weiterhin erfüllt werden.

Beschreiben Sie jede Option als konkreten Zielzustand. „Eine eigene App“ ist noch keine Alternative, wenn niemand weiß, wie Benutzerverwaltung, Belege, Ausnahmen und die Rückmeldung aus dem Finanzsystem funktionieren sollen. „Ein anderes Standardprodukt“ bleibt ebenfalls unbewertet, solange nur seine Funktionsliste vorliegt.

Erst Ausschlusskriterien, dann Vorteile

Eine günstige Variante, die einen zwingenden Geschäftsfall nicht abbilden kann, wird nicht durch gute Bewertungen in anderen Kategorien passend. Legen Sie deshalb zunächst fest, welche Anforderungen jede Option erfüllen muss. Bewerten Sie erst danach Komfort, Anpassbarkeit und zusätzliche Funktionen.

Formulieren Sie Ihre fachlichen Mussanforderungen als überprüfbare Vorgänge. Beispielsweise: Eine Vertretung darf einen Antrag nur innerhalb ihrer zugewiesenen Zuständigkeit freigeben; der Vorgang muss anschließend mit den richtigen Angaben im Finanzsystem ankommen. „Flexibles Rollenmodell“ wäre dafür zu ungenau.

Genauso konkret sollten Sicherheits- und Betriebsanforderungen sein. Wer darf welche Daten sehen? Wie weisen Sie Änderungen nach? Wie wird ein fehlerhafter Release zurückgenommen, wie werden Daten wiederhergestellt und wer reagiert auf eine Störung? Für die sichere Entwicklungs- und Beschaffungssprache bietet das NIST Secure Software Development Framework, Version 1.1 eine offizielle Grundlage. Es macht ein Produkt nicht automatisch sicher, sondern beschreibt Praktiken, über die Sie mit dem liefernden Team sprechen können.

Prüfen Sie Datenzugang und Integrationen am konkreten Umfang. Können Sie die benötigten Daten vollständig abrufen? Kann eine Rückmeldung eindeutig einem Vorgang zugeordnet werden? Sind Fehlerzustände sichtbar und behandelbar? Eine vorhandene API beantwortet diese Fragen noch nicht.

Termin und Teamkapazität gehören ebenfalls zu den Voraussetzungen. Verfügbarkeit eines Standardprodukts ist nicht gleichbedeutend mit abgeschlossener Einführung. Umgekehrt erfüllt ein Plan für eigene Entwicklung die Anforderungen erst, wenn Machbarkeit und notwendige Fähigkeiten ausreichend belegt sind. Ist ein entscheidender Nachweis offen, markieren Sie die Option als ungeklärt, statt ihr aus Optimismus volle Punkte zu geben.

So vergleichen Sie die Gesamtkosten

Total Cost of Ownership, kurz TCO, bezeichnet hier die Gesamtkosten Ihrer jeweiligen Softwareoption. Vergleichen Sie den gleichen fachlichen Umfang über den gleichen Betrachtungszeitraum. Eine SaaS-Lizenzrechnung und das Budget für den ersten eigenen Prototyp haben unterschiedliche Grenzen und sind deshalb keine ausreichenden Gegenstücke.

Das folgende Raster ist eine Rechenhilfe ohne Beispielbeträge. Für jede Position tragen Sie ein, wer sie übernimmt, auf welcher Annahme die Schätzung beruht und wie sicher diese Annahme ist. Lassen Sie unbekannte Kosten offen; ein leeres Feld ist ehrlicher als eine unbelegte Null.

Bei einer vorhandenen Lösung sind frühere, nicht mehr veränderbare Ausgaben keine zukünftige Einsparung. Erfassen Sie, was ab jetzt tatsächlich weiter anfällt oder vermieden werden kann. Beachten Sie dagegen weiterhin, welche bereits bezahlten Leistungen Sie nutzen können und welche Vertragsbindungen eine Änderung beeinflussen.

Ordnen Sie Kosten zeitlich zu. Wenn eine Stilllegung außerhalb Ihres Betrachtungszeitraums liegt, zeigen Sie sie separat als späteres Szenario. Geben Sie nicht den vollständigen hypothetischen Exit einer Option in die Rechnung ein, während Sie ihn bei einer anderen auslassen. Und zählen Sie einen Entwicklungsaufwand nicht gleichzeitig als Personalkosten und nochmals als denselben externen Leistungsposten.

Teamkapazität verdient eine eigene Betrachtung: Welches andere Vorhaben verschieben Sie durch den Bau oder die Einführung? Halten Sie diese Opportunität sichtbar fest. Monetarisieren Sie sie nur mit einer nachvollziehbaren Grundlage und vermeiden Sie doppelt gezählte Arbeitszeit.

Prüfen Sie schließlich, was die Entscheidung kippen würde: eine andere Nutzerzahl, mehr Anpassungsbedarf, höhere Nutzungsentgelte oder ein längerer Parallelbetrieb. Rechnen Sie mit Ihren eigenen belegten Annahmen mehrere Szenarien. Wenn die bevorzugte Option nur unter einer einzigen optimistischen Annahme trägt, ist diese Annahme der nächste Prüfauftrag.

Beispiel: Nur die Freigabelogik selbst entwickeln

Illustratives Beispiel: Ein Unternehmen nutzt eine Standardlösung für Einkaufsanträge. Sie verwaltet Benutzer, Lieferanten, Belege und den Status der Vorgänge. Eine besondere Regel passt jedoch nicht: Bestimmte Beschaffungen benötigen neben der Kostenstellenfreigabe eine projektbezogene Genehmigung, deren Zuständigkeit sich aus internen Vereinbarungen ergibt.

Die erste Frage ist, ob die vorhandene Konfiguration diese Regel sauber abbilden kann. Die zweite ist, ob eine marktverfügbare Alternative sie besser erfüllt. Erst wenn beides nicht trägt, wird eine eigene Ergänzung interessant. Diese übernimmt dann die besondere Freigabeentscheidung, während die geeigneten Standardfunktionen erhalten bleiben.

Damit ist der Umfang des Eigenbaus genauer als „Einkaufssystem neu entwickeln“. Er umfasst die erforderlichen Projektinformationen, die Freigaberegel, die Berechtigungen und die Rückmeldung. Er umfasst nicht automatisch Lieferantenverwaltung, Belegarchiv oder alle Funktionen des bisherigen Produkts.

Die Systemgrenze erzeugt trotzdem technische Aufgaben. Was passiert, wenn der Standarddienst nicht erreichbar ist? Wenn dieselbe Rückmeldung erneut eintrifft? Oder wenn sich der Antrag während der Prüfung ändert? Solche Zustände gehören in die Anforderungen und Tests der Ergänzung. Sonst entsteht ein kleiner Prototyp, dessen Betrieb später überraschend groß wird.

Ein Adapter kann die eigene Fachlogik von den besonderen Datenstrukturen des Standardprodukts trennen. Das Microsoft-Muster einer Anti-Corruption Layer erklärt diese Übersetzung zwischen Systemen und weist auf ihren Wartungsbedarf hin. Eine solche Grenze ist kein kostenloser Schutz: Auch die Integrationskomponente braucht einen Verantwortlichen.

Wer trägt die Lösung nach dem Go-live?

Eine Softwareoption ist erst dann tragfähig, wenn Sie wissen, wer sie nach der Einführung verantwortet. Der fachliche Owner entscheidet über Regeln und Änderungen. Ein technischer Verantwortlicher kümmert sich um Support, Releases und Abhängigkeiten. Für Störungen, Wiederherstellung und Zugänge benötigen Sie ebenfalls klare Zuständigkeiten.

Bei eigener Software prüfen Sie nicht nur, ob aktuell Entwickler verfügbar sind. Prüfen Sie, ob das Team die Lösung erklären kann, neue Mitarbeiter sie übernehmen können und Budget für notwendige Änderungen vorgesehen ist. Ein einzelner Wissensträger oder eine undokumentierte Deploymentroutine kann eine erhebliche eigene Abhängigkeit schaffen.

Bei gekauftem Produkt bleibt zu klären, was der Anbieter wirklich übernimmt und was intern bleibt. Ein Service Level Agreement kann Reaktions- oder Verfügbarkeitszusagen enthalten; lesen Sie die konkrete Vereinbarung und den Umgang mit Ihrer eigenen Integration. Ein Supportvertrag für das Produkt betreibt nicht automatisch Ihre Sonderanpassung.

Wenn ein Partner entwickelt, vereinbaren Sie die praktische Übergabe: Quelltexte und benötigte Rechte, Konfigurationen, Zugänge, Dokumentation, Tests und Betriebsabläufe. Lassen Sie das übernehmende Team einen Release und einen Wiederanlauf erproben. Diese Anforderung macht aus der Vertragsfrage einen überprüfbaren technischen Vorgang.

Entwicklung, Kauf und Betrieb müssen nicht von derselben Partei erbracht werden. Ihre eigene Fähigkeit, Prioritäten und Risiken zu steuern, bleibt jedoch nötig. Auch der GDS-Beitrag zu langfristiger Verantwortung betont die erforderliche Aufsicht unabhängig davon, ob gebaut, gekauft oder kombiniert wird.

Was KI an der Entscheidung ändert

Wenn ein Team KI beim Analysieren, Programmieren oder Testen einsetzt, darf das in die Bewertung seiner konkreten Umsetzung eingehen. Ein schnell erzeugter Bildschirm oder ein lauffähiger Codeentwurf ist aber noch kein Beleg dafür, dass die benötigte Software insgesamt übernommen werden kann.

Prüfen Sie dieselben Aufgaben wie bei jeder anderen Option: Sind die Geschäftsregeln richtig? Sind Berechtigungen, Datenübernahme und Integrationen getestet? Können Änderungen überprüft, sicher veröffentlicht und bei Bedarf zurückgenommen werden? Ist der Betrieb einschließlich Störungen und Wiederherstellung vorbereitet? Ob ein Teil des Codes mit KI entstanden ist, beantwortet diese Fragen nicht.

Leiten Sie deshalb keine pauschale Einsparung und keinen generellen SaaS-Ersatz aus einer Demo ab. Nutzen Sie einen begrenzten, repräsentativen Vorgang, um die tatsächliche Umsetzung Ihres Teams zu prüfen. Entscheidend sind dabei auch Nacharbeit, Review und die verbleibenden offenen Aufgaben. Dasselbe gilt für Low-Code: Nehmen Sie Plattformbindung, Exportmöglichkeiten und künftige Änderungen in den Vergleich auf.

Eine Entscheidung, die Sie begründen können

Beginnen Sie mit einer kurzen Problembeschreibung: Was funktioniert heute nicht ausreichend, und welches fachliche Ergebnis muss sich verbessern? Begrenzen Sie anschließend den Umfang und markieren Sie die Mussanforderungen. IT, Fachbereich, Einkauf und die späteren Betriebsverantwortlichen sollten diese Beschreibung gemeinsam prüfen.

Erproben Sie für die verbleibenden Optionen denselben schwierigen Vorgang. Eine echte Ausnahme, eine Integration und ein nachvollziehbares Ergebnis sind aussagekräftiger als unterschiedlich vorbereitete Verkaufsdemos. Das GDS Service Manual zur Technologieauswahl empfiehlt, Nutzer- und Technologieannahmen sowie Schnittstellen früh mit Prototypen zu prüfen.

Halten Sie die Entscheidung auf einer Seite fest: gewählte Option, abgegrenzter Funktionsumfang, erfüllte Musskriterien, Kostenzeitraum und Annahmen, Verantwortliche sowie die wichtigsten offenen Punkte. Notieren Sie auch das stärkste Gegenargument und den Anlass für eine erneute Prüfung. So lässt sich später erklären, warum die Empfehlung unter den damaligen Bedingungen getragen hat.

Für die Bewertung einer konkreten bestehenden Anwendung beschreibt das SaaS Replacement Assessment von eBiz einen passenden Anschluss. Es stellt Wirtschaftlichkeit, Funktionskern, Daten, Integrationen und Betriebsmodell gegenüber, bevor Behalten, Ersetzen oder Neubau entschieden werden.