Individualsoftware neu gedacht: Ein besserer Rahmen für die Make-or-Buy-Entscheidung

Make or Buy – warum die Frage eigentlich zwei Fragen sind

Irgendwann steht jedes Unternehmen vor dieser Situation. Ein zentrales System hat seinen Zenit überschritten, ein Fachbereich braucht Funktionalität, die die vorhandene Software nicht liefert, oder die angehäuften Workarounds kosten mehr als sie wert sind. Jemand schlägt vor, sich am Markt umzuschauen – jemand anderes plädiert für eine maßgeschneiderte Lösung. Die darauffolgende Diskussion trägt fast immer denselben Titel: Make or Buy.

Die Frage ist vertraut. Genauer betrachtet stecken in ihr zwei eigenständige Fragen – und wer sie trennt, trifft fundiertere Entscheidungen.

Das Make-or-Buy-Framing legt eine Zweiteilung nahe: entweder entwickeln die eigenen Entwickler die Software, oder man kauft ein Produkt. Doch tatsächlich sind zwei unabhängige Fragen zu beantworten. Erstens: Gibt es ein Produkt, das den Anforderungen wirklich gerecht wird – oder muss der Prozess maßgeschneidert sein? Zweitens: Wenn Individualsoftware die richtige Wahl ist, wer baut sie dann?

Wer diese beiden Fragen trennt und in der richtigen Reihenfolge beantwortet, trifft nachweislich bessere Entscheidungen. Und da Agentic AI die Kostenrechnung individueller Softwareentwicklung gerade neu schreibt, lohnt sich eine Neubetrachtung der klassischen Entscheidungslogik.

Wann Individualsoftware die bessere Wahl ist

Produktkäufe versprechen handfeste Vorteile: Eine bewährte Plattform suggeriert kürzere Einführungszeiten, kalkulierbare Kosten und einen Hersteller, der die Infrastruktur verantwortet. Für viele Prozesse hält dieses Versprechen. Gehaltsabrechnung, Reisekostenmanagement, Standard-HR – das sind Commodity-Prozesse. Jedes große Unternehmen wickelt sie im Wesentlichen gleich ab. Ein gut gewähltes Produkt leistet hier gute Arbeit.

Das Problem entsteht, wenn dieselbe Logik auf Prozesse angewendet wird, die das Unternehmen tatsächlich differenzieren. Die Art, wie ein Versicherer Risiken bewertet und zeichnet. Die Logik, nach der eine Bank Kunden segmentiert und Kreditentscheidungen trifft. Der Workflow, mit dem ein Hersteller individuelle Aufträge koordiniert. Solche Prozesse lassen sich nicht standardisieren. Sie verkörpern jahrelange Weiterentwicklung, regulatorische Anpassung und hart erarbeitetes Wettbewerbswissen – und kein Produkt wurde für die spezifische Situation eines einzelnen Unternehmens gebaut. Das wäre auch wirtschaftlich nicht möglich.

Empirische Auswertungen mehrerer tausend Projekte zeigen:

• 55–75 % aller Enterprise-Software-Einführungen verfehlen ihre Ziele (Gartner, Panorama Consulting Group)
• Bei Projekten, die aus dem Ruder laufen: durchschnittliches Budget-Overrun 178 %, Zeitverzug 230 %
• Tatsächlich geliefert: nur 41 % der ursprünglich geplanten Funktionalität
• Typische Gesamtkosten: 3–4-faches des ursprünglichen Budgets

Der Grund liegt fast nie im Produkt selbst. Er liegt im Customizing, das nötig wird, um das Produkt an die Realität des Unternehmens anzupassen. Wer ein Standardprodukt anpasst, zahlt dafür erheblich – und gefährdet zugleich die Updatefähigkeit: Jede neue Produktversion erfordert Eingriffe in den proprietären Code. Je stärker ein Unternehmen customisiert, desto abhängiger wird es von spezialisierten Dienstleistern. Die eigene Weiterentwicklung richtet sich fortan nach der Produkt-Roadmap des Herstellers. Was das Unternehmen am Markt unterscheidet, nivelliert sich auf den kleinsten gemeinsamen Nenner des Produkts.

Produkte funktionieren – solange man sie in der richtigen Problemklasse einsetzt.

Kriterien zur Entscheidungsfindung

Der Einstieg ist einfach: zwei Fragen stellen statt einer.

Commodity-Prozesse – Gehaltsabrechnung, HR-Verwaltung, Standardworkflows – lassen sich mit einem gut gewählten Produkt fast immer am besten abdecken. Das Ziel ist Zuverlässigkeit und Kosteneffizienz, nicht Wettbewerbsdifferenzierung. Dafür sind Produkte gemacht. Aber dort, wo Unternehmen tatsächlich differenzieren – wie sie Risiken bewerten, Kunden segmentieren oder Produktion koordinieren – führt nur Individualsoftware zum Ziel. Diese Prozesse kodifizieren unternehmensindividuelle Wettbewerbslogik. Kein Produkt wurde für solch spezifische Situationen entworfen. Der Versuch, eines passend zu machen, erzeugt die oben beschriebenen Scheitermuster.

Ist Individual die richtige Wahl, folgt die nächste Frage: Wer baut? Hier wird das klassische Make-or-Buy-Framing aktiv irreführend. „Individual” bedeutet nicht „die eigene IT-Abteilung entwickelt es”. Es bedeutet Software nach unternehmensindividuellen Anforderungen – und diese Arbeit kann ein spezialisierter Partner genauso leisten wie interne Entwickler, oft besser. Interne Teams haben echte Grenzen: begrenzte Kapazität, breite Verantwortung über mehrere Initiativen, Bindungsprobleme bei spezialisierten Talenten, eine Kostenstruktur, die sich nicht elastisch an Projektbedarf anpasst. Ein spezialisierter Partner bringt das nötige Spezialwissen, klare Verantwortung und skalierbare Kapazität genau dann mit, wenn das Projekt sie braucht.

Der dritte Weg – einen Partner zu beauftragen, die Individualsoftware zu konzipieren, zu bauen und zu betreuen – ist derjenige, den das Make-or-Buy-Framing völlig ausblendet. Das Unternehmen behält das Eigentum. Die Geschäftslogik bleibt unter Unternehmenskontrolle. Entwicklungskompetenz wird eingekauft, ohne dass Fixkosten für ihren Aufbau und ihre Pflege im Haus entstehen. Diesen Weg gibt es seit Jahrzehnten – Agentic AI hat ihn ökonomisch so weit verbessert, dass er heute der internen Entwicklung in vielen Fällen vorzuziehen ist.

Wie Agentic AI die Kostengleichung verändert

Der klassische Einwand gegen Individualsoftware lautet: zu teuer, zu langsam. Ein Produkt lässt sich schneller einführen und – auf dem Papier – günstiger realisieren als eine maßgeschneiderte Lösung. Dieser Abstand hat sich deutlich verringert. In manchen Fällen ist er verschwunden.

Agentic AI – Werkzeuge, die über gesamte Codebasen hinweg planen, umsetzen, testen und dokumentieren – erzielt Produktivitätssteigerungen von 3 bis 10× in der Praxis, nicht nur in Hochrechnungen. Aus itestras eigenen Produktionsprojekten Anfang 2026:

• ERP-System, >1M Codezeilen: Neues Feature autonom entwickelt inklusive End-to-End-Tests – in unter 2 Stunden
• Mainframe-System, >1M Codezeilen: Vollständige Architekturdokumentation erzeugt – in 1 Stunde
• Übergreifend: 3–10× Effizienzgewinne; Analyse und Dokumentation tendenziell am oberen Ende, komplexe Feature-Entwicklung eher am unteren

Was früher Wochen erfahrener Entwicklerarbeit kostete, dauert heute Stunden. Was Monate brauchte, wird in Wochen realisierbar.

Die Konsequenz für die Entscheidung Produkt versus Individual ist unmittelbar. Wenn ein Expertenteam Individualsoftware schneller und günstiger liefern kann als der Aufwand, ein Produkt passend zu machen, löst sich der Trade-off, der Produkte einst attraktiv machte, auf.

Entscheidend dabei: Agentic AI reduziert nicht die Notwendigkeit von Expertenurteil. Code, der ohne tiefes Verständnis von Geschäftsanforderungen, regulatorischen Rahmenbedingungen und architektonischen Konsequenzen erzeugt wird, ist technisch funktionsfähig, aber strategisch falsch – und erzeugt diese Fehler schnell, was den Schaden verstärkt. Produktivitätsgewinne entstehen zuverlässig nur dort, wo erfahrene Ingenieure mit echtem Domänenwissen die KI an den entscheidenden Stellen führen. Erst dieses Zusammenspiel macht die neue Ökonomie zu verlässlichen Projektergebnissen.

Eigentum als strategischer Vermögenswert

Kostenvergleiche greifen zu kurz, solange sie Eigentum ausblenden.

Im Besitz des Unternehmens steigt Individualsoftware in ihrem Wert mit der Zeit. Jedes neue Feature, jede Anpassung bringt das System näher an die tatsächliche Wettbewerbssituation des Unternehmens – das Gegenteil des Produktpfads. Anders als ein schwer angepasstes Produkt, das mit jeder Schicht fragiler wird, steigt der strategische Nutzen einer maßgeschneiderten Lösung kontinuierlich.

Das bedeutet konkret:

• Künftige Entwicklung wird schneller und günstiger. Das Fundament ist für den unternehmensindividuellen Kontext gebaut, nicht für einen Marktdurchschnitt. Änderungen richten sich nach dem Geschäft, nicht nach Produktreleases.
• Abhängigkeitsschlingen werden vermieden. Code und Geschäftslogik gehören dem Unternehmen. Strategische Optionen bleiben in unternehmenseigener Hand.
• Upgrades bleiben unter Unternehmenskontrolle. Keine Abhängigkeit von der Hersteller-Roadmap. Keine Überraschungen durch Breaking Changes.
• Laufende Kosten sind kalkulierbar. Der Partner, der das System gebaut hat, betreut es unter vereinbarten SLAs – definierte Reaktionszeiten, tiefes Systemwissen, ohne Reibungsverluste beim Übergang.

Oft wird eingewandt, dass Individualsoftware dauerhaften Betriebsaufwand erzeugt, weil kein Hersteller die Verantwortung trägt. Moderne Expertenpartnerschaften funktionieren anders. Ein Individualsystem, das vom gleichen Partner betrieben wird, der es gebaut hat, vereint die Flexibilität individueller Software mit der Zuverlässigkeit verwalteter Systeme. Es ist weder Last noch laufendes Projekt – es ist eine Infrastruktur, die mit dem Unternehmen wächst.

Über mehr als 20 Jahre und 90+ Unternehmenskunden hat itestra Kernsysteme genau auf diese Weise entwickelt und betrieben – schlank, präzise zugeschnitten, frei von ungenutzter Produktfunktionalität, einfach zu weiterentwickeln.

Der richtige Einstieg

Für Unternehmen, die gerade eine Kernsoftware-Investitionsentscheidung vor sich haben, ist der hilfreiche erste Schritt zu klären, welche Frage eigentlich beantwortet werden muss.

Handelt es sich um einen Commodity-Prozess, bei dem Standardverhalten ausreicht und ein Produkt echten Wert schafft? Oder ist es ein differenzierender Prozess, bei dem die zugrunde liegende Geschäftslogik spezifisch für die Wettbewerbsposition des Unternehmens ist? Diese Antwort sollte vor jeder Produktevaluation und vor jeder Kapazitätsdiskussion stehen.

Fällt sie auf Individual, kommt die zweite Frage: intern entwickeln oder beim Experten beauftragen? Sie sollte ehrlich beantwortet werden – gegen die reale Kapazität, realistische Zeitrahmen und die vollständigen Kosten beider Wege, Verzögerungskosten eingerechnet.

Der Enterprise Business Solutions Health Check von itestra setzt genau hier an. In ein bis zwei Wochen werden die relevanten Prozesse analysiert, die Stellen identifiziert, an denen Individualsoftware den größten Nutzen bringt, und die realistischen Optionen mit konkreten Kosten- und Zeitschätzungen bewertet. Zum Festpreis, klar abgegrenzt – Analyse, nicht Verpflichtung.

Wer die zwei Fragen hinter der einen Make-or-Buy-Entscheidung auseinanderhält und in der richtigen Reihenfolge beantwortet, vermeidet die teuersten Fehler bei Kernsoftware-Investitionen.