Standardsoftware kaufen oder selbst entwickeln lassen – nach welchen Kriterien entscheide ich Make-or-Buy?

Ja, dafür gibt es ein sauberes Raster. Der Denkfehler steckt meist am Anfang: Make-or-Buy ist keine Software-Frage, sondern eine Frage nach der strategischen Bedeutung des Prozesses. Daraus folgt der Rest.

Leitfrage zuerst: Ist der Prozess ein Differenzierungsmerkmal im Wettbewerb oder eine Commodity? Buchhaltung, Lohnabrechnung und Zeiterfassung macht jedes Unternehmen im Kern gleich – dafür Standardsoftware. Wenn dagegen die Auftragsabwicklung mit einer sehr speziellen Variantenkonfiguration der Grund ist, warum Kunden bei genau diesem Maschinenbauer kaufen, spricht das für eine eigene Lösung. Merksatz: Kernkompetenz behalten, Standardprozesse kaufen.

Danach das Kriterienraster – am besten in vier Blöcken, das strukturiert die Antwort automatisch:

• Wirtschaftlich: Anschaffungs- bzw. Entwicklungskosten, vor allem aber die Gesamtkosten über die Laufzeit (Lizenzen und Wartung, Betrieb, Anpassung, Schulung, Migration, spätere Weiterentwicklung). Dazu die Zeit bis zur Einsatzbereitschaft – Standard läuft in Monaten, eine Individualentwicklung dauert deutlich länger.
• Funktional: Abdeckungsgrad der Anforderungen (Fit-Gap-Analyse), Anpassbarkeit, Integration in die bestehende Systemlandschaft, Skalierbarkeit.
• Organisatorisch: vorhandenes IT-Know-how im Haus, Personal für Wartung, Akzeptanz bei den Anwendern, Aufwand für die Prozessanpassung – bei Standardsoftware passt sich oft das Unternehmen der Software an, nicht umgekehrt.
• Risiko und Recht: Abhängigkeit vom Anbieter (Lock-in) gegen Abhängigkeit vom eigenen Entwickler-Know-how, Zukunftssicherheit und Updatefähigkeit, Datenschutz und Revisionssicherheit, Ausfall des Dienstleisters, Gewährleistung.

Wichtig für die Beurteilung: Es sind nicht nur zwei Optionen. Zwischenformen gehören in jede gute Antwort – Standardsoftware mit Customizing (Konfiguration in den vom Hersteller vorgesehenen Grenzen, bleibt updatefähig), Branchenlösung (Standard, der die Besonderheiten der Branche schon kennt), Cloud/SaaS statt eigenem Betrieb, oder ein Standardkern mit einer kleinen individuellen Ergänzung an genau der einen kritischen Stelle. Für einen Mittelständler ist das in der Praxis fast immer die realistische Lösung.

Und die entscheidende Unterscheidung dabei: Customizing über vorgesehene Parameter ist harmlos, Individualprogrammierung im Standardsystem macht jedes Update zum Projekt. Wer das erwähnt, zeigt, dass er den Praxisunterschied kennt.

Zur Struktur deiner Antwort – das ist ja dein eigentliches Problem – gibt es ein Vorgehen, das in Klausuren immer trägt:

1. Anforderungen zuerst. Ohne Anforderungen kann man nichts beurteilen. Stichwort Lastenheft: Was muss das System können, unterteilt in Muss-, Soll- und Kann-Anforderungen? Liefert die Aufgabe keine, formulierst du zwei bis drei plausible selbst und schreibst dazu, dass du sie annimmst. Benannte Annahmen kosten nie Punkte, unbegründete Behauptungen schon.
2. Quantitative Kriterien rechnen. Kostenvergleich über einen festen Zeitraum, z. B. fünf Jahre, mit allen Positionen: Lizenz oder Entwicklung, Einführung, Schulung, Migration, laufende Wartung, Betrieb. Das ist der Punkt, an dem die meisten scheitern, weil sie nur den Anschaffungspreis vergleichen – die Folgekosten drehen das Ergebnis regelmäßig um.
3. Qualitative Kriterien bewerten. Dafür ist die Nutzwertanalyse das Standardwerkzeug: Kriterien festlegen, gewichten (Summe 100 %), je Alternative Punkte vergeben (etwa 1 bis 5), gewichtete Summe bilden. Damit wird aus „passt besser“ eine nachvollziehbare Zahl. Wichtig: die Gewichtung begründen, denn sie entscheidet das Ergebnis – und genau diese Subjektivität ist auch der Standard-Kritikpunkt, den man am Ende nennt.
4. Empfehlung mit Begründung und Risiken. Ein Satz Entscheidung, zwei bis drei Sätze Begründung mit Bezug auf die höchstgewichteten Kriterien, dann die Gegenargumente ernst nehmen und sagen, wie man das Risiko begrenzt: Referenzkunden, Pilotphase, Exit-Klausel im Vertrag, Datenexportformat vertraglich sichern.

Kurz: Kriterien → Bewertung → Entscheidung → Risiken. Wenn du diese vier Blöcke als Zwischenüberschriften nimmst, sieht der Korrektor die Struktur sofort, und deine Argumente wirken nicht mehr wie Meinung, sondern wie ein Bewertungsverfahren.

Ein Schlusssatz, der fast immer trägt: Die Entscheidung fällt selten „Standard gegen Individual“, sondern über die Frage, wie viel Abweichung vom Standard sich das Unternehmen dauerhaft leisten will – denn jede Abweichung bezahlt man bei jedem Update erneut.