Make-or-Buy-Entscheidung
Die Make-or-Buy-Entscheidung ist die Abwägung, ob ein Betrieb eine benötigte Software selbst entwickeln lässt oder ein fertiges Produkt kauft oder mietet; entschieden wird sie anhand der Abweichung der eigenen Abläufe vom Produktstandard, der Kosten über die gesamte Nutzungsdauer und der tragbaren Abhängigkeit von einem Hersteller.
Der Begriff stammt aus der industriellen Beschaffung und bezeichnet in der Softwareauswahl den Schritt vor der Frage, welches Produkt oder welcher Entwicklungspartner in Betracht kommt.
In einfachen Worten
Make steht für die eigene Herstellung, Buy für den Zukauf. Bei Software heißt Make: Ein Entwicklungspartner baut eine Anwendung nach den Anforderungen des Betriebs, und der Betrieb erhält die Nutzungsrechte am Ergebnis. Buy heißt: Der Betrieb lizenziert eine Standardsoftware, die ein Hersteller für viele Kunden pflegt, oder nutzt sie als Mietdienst im Browser. Zwischen beiden Polen liegt die angepasste Standardsoftware, die über Einstellungen und Erweiterungen an den Betrieb herangeführt wird. Die Entscheidung fällt deshalb in der Praxis zwischen drei Wegen. Ausgangsgröße ist die Frage, wie weit der eigene Ablauf von dem abweicht, was ein fertiges Produkt vorsieht. Kleine Abweichungen lassen sich per Konfiguration abbilden. Große Abweichungen erzeugen entweder Umbauten im Produkt oder Umwege im Arbeitsalltag. Beides kostet Geld an unterschiedlichen Stellen: der Umbau beim Dienstleister, der Umweg in der Arbeitszeit der eigenen Mitarbeitenden.
Wozu brauche ich das?
Die Abwägung steht an, wenn ein Altsystem abgelöst wird, ein neuer Geschäftsbereich eine eigene Anwendung braucht oder die vorhandene Software die Abläufe nur noch mit Nebenlisten abdeckt. Sie gehört vor die Anbieterauswahl, weil ein Angebotsvergleich zwischen mehreren Herstellern die Frage nach der Eigenentwicklung bereits beantwortet voraussetzt. Grundlage ist ein Lastenheft, das den Ablauf einschließlich der Sonderfälle beschreibt. Erst daran lässt sich messen, welchen Anteil der Anforderungen ein Produkt ohne Umbau erfüllt und welcher Anteil eine Anpassung oder eine Eigenentwicklung verlangt.
Beispiel aus der Praxis
Ein Hersteller von Industrietoren mit eigenem Montagedienst sucht eine Software für die Einsatzplanung seiner Monteure. Drei Wege stehen zur Wahl: ein Mietdienst für Außendienstplanung, das Planungsmodul der vorhandenen Auftragssoftware oder eine eigene Anwendung. Der Betrieb spielt zwanzig reale Einsätze aus dem Vorjahr in allen drei Varianten durch. Der Mietdienst bildet Termine und Routen ab, kennt aber keine Wartungsverträge mit festen Prüfintervallen, aus denen der Großteil der Einsätze entsteht. Das Planungsmodul kennt die Verträge, plant aber nicht nach der Qualifikation der Monteure. Eine Eigenentwicklung würde beides abdecken und den Betrieb dauerhaft an Pflege und Weiterentwicklung binden. Die Wahl fällt auf das Planungsmodul mit einer begrenzten Erweiterung für die Qualifikationsprüfung, weil diese Erweiterung über einen vorgesehenen Erweiterungspunkt des Herstellers angebunden wird und künftige Updates nicht berührt.
Wirtschaftlicher Nutzen
Eine bewusst getroffene Make-or-Buy-Entscheidung verhindert zwei teure Verläufe: das fertige Produkt, das nach der Einführung Stück für Stück umgebaut wird, bis es die Nachteile beider Wege vereint, und die Eigenentwicklung für eine Aufgabe, die jedes Produkt gleichwertig erfüllt. Der Vergleich über die Gesamtbetriebskosten zeigt, dass die Anschaffung bei beiden Wegen nur einen Teil der Rechnung ausmacht. Wer Kriterien und Begründung schriftlich festhält, kann die Entscheidung Jahre später überprüfen, wenn sich Abläufe oder Marktangebot verändert haben.
Typische Fehler
- Nur Anschaffungskosten verglichen – Anpassung, Betrieb, Schulung und spätere Ablösung fehlen in der Rechnung.
- Nach einer Produktvorführung mit Beispieldaten des Herstellers entschieden, ohne eigene Vorgänge durchzuspielen.
- Den Weg der angepassten Standardsoftware übergangen und nur zwischen Kauf und Eigenentwicklung gewählt.
- Den Ausstieg ausgeklammert – wie Daten und Quellcode bei einem Wechsel mitgenommen werden, wird vor dem Vertrag geklärt.
- Die Entscheidung allein der IT überlassen, obwohl nur die Fachabteilung beurteilen kann, wo ein Ablauf vom Standard abweichen muss.
Worauf achten?
- Vor dem Vergleich den Ablauf mit allen Sonderfällen schriftlich beschreiben.
- Jeden Weg mit denselben realen Vorgängen aus dem eigenen Bestand prüfen.
- Die Kosten über die gesamte geplante Nutzungsdauer gegenüberstellen, einschließlich der Ablösung.
- Für jeden Weg festhalten, wie ein späterer Wechsel abliefe: Datenexport, Dokumentation, Rechte am Code.
- Kriterien und Begründung der Entscheidung dokumentieren, damit sie später überprüfbar bleibt.
Häufig gestellte Fragen
Was bedeutet Make-or-Buy bei Software?
Die Abwägung zwischen einer Eigenentwicklung (Make) und dem Kauf oder der Miete eines fertigen Produkts (Buy). Als dritter Weg kommt die angepasste Standardsoftware hinzu, die zwischen beiden Polen liegt.
Welche Kriterien entscheiden zwischen Kauf und Eigenentwicklung?
Die Abweichung der eigenen Abläufe vom Produktstandard, die Kosten über die gesamte Nutzungsdauer, die Abhängigkeit vom Hersteller, die erwartete Lebensdauer der Abläufe und die Frage, ob die Anwendung später an einen anderen Dienstleister übergeben werden kann.
Wann ist Kaufen die bessere Wahl?
Wenn die Abläufe dem Branchenüblichen entsprechen, etwa in Buchhaltung, Lohnabrechnung oder Zeiterfassung. Eine Eigenentwicklung erzeugt dort keinen Vorsprung, und der Hersteller verteilt die Pflegekosten auf viele Kunden.
Wer sollte die Make-or-Buy-Entscheidung treffen?
Die Geschäftsführung auf Grundlage zweier Beiträge: Die Fachabteilung beschreibt, wo ihr Ablauf vom Standard abweicht und warum. Die IT oder ein externer Partner bewertet Aufwand, Betrieb und Ausstiegswege der einzelnen Varianten.