Selbst bauen oder kaufen?

Was ist die Ausgangslage?

Ein Serviceunternehmen mit mehreren Werkstätten will Wartungsberichte künftig digital mit Kunden teilen. Zwei Möglichkeiten stehen im Raum: eine eigene Anwendung oder eine gekaufte Standardlösung. Die Eigenentwicklung verspricht eine passgenaue Oberfläche, verlangt aber interne Entwicklerkapazität und langfristige Wartung. Die gekaufte Software steht schneller bereit, benötigt jedoch Anpassungen und einen mehrjährigen Vertrag. Das Management setzt einen Einführungstermin im nächsten Frühjahr. Die IT bevorzugt aus technischer Sicht klar Make, der Einkauf will Buy wegen planbarer Verträge. Du moderierst die Entscheidung und willst vermeiden, dass zwei Lager nur Argumente für ihren Favoriten sammeln.

Welche Ereignisse verändern die Entscheidungslage?

Zeit und Informationen sind eigens für dieses Lernbeispiel erfunden.

Fallvertiefung · Drei-Jahres-Vollkosten und strategischer Engpass

Die scheinbar günstige Eigenentwicklung bekommt ein Kostenblatt. Für das digitale Wartungsportal kalkuliert die IT zunächst nur 95.000 Euro externe Projektkosten. Die Geschäftsführung ergänzt interne Entwicklerstunden, Betrieb und regelmäßige Pflege. Daneben steht der Zukauf mit Einrichtungsgebühr, Lizenzen und interner Schnittstellenarbeit. Die Zahlen sind Annahmen für dieses Rechenbeispiel.

Die Rechnung ergibt unter den angegebenen Annahmen eine Differenz von 95.000 Euro zugunsten von Buy. Das ist kein empirischer Marktpreis. Neben den Zahlen prüft die Geschäftsführung drei strategische Fragen: Hebt die Komponente das Unternehmen im Wettbewerb ab? Können die Entwickler dafür von kritischen Kundenaufträgen abgezogen werden? Was passiert beim Ausfall oder Verkauf des Anbieters?

Die gekaufte Lösung scheidet aus, wenn ein zwingendes Daten-, Sicherheits- oder Integrationskriterium auch vertraglich nicht erfüllt werden kann. Dann helfen die 95.000 Euro Modellvorteil nicht. Bei beiden Wegen verlangt der Beschluss belastbare Supportzusagen, Datenexport und eine dokumentierte Exit-Strategie.

Entscheidungspunkt 1: Die Muss-Kriterien

STOPP: Die Standardsoftware erfüllt noch nicht jede Datenanforderung. Was ist der nächste Schritt?

Das Team legt vier harte Bedingungen fest, darunter Datenexport und verbindliche Schnittstellen. Beide Alternativen bleiben zunächst im Rennen, weil die Standardsoftware eine prüfbare Zusage für den Export anbietet. Bis zum Test gilt diese Zusage als offen.

Prüffrage: Welche Anforderung dürfte keinesfalls durch zusätzliche Komfortpunkte ausgeglichen werden?

Zwischenfazit: Muss vor Wunsch.

Entscheidungspunkt 2: Gewichte offenlegen

STOPP: Du hast eine Nutzwertmatrix vor dir. Wie wählst du Gewichte?

Das Gremium sieht, weshalb Buy unter diesen Annahmen vorne liegt. Wer das Tempo weniger stark gewichtet, kann zu einem anderen Ergebnis kommen. Die Gruppe hält die Gewichte mit Datum fest und beauftragt einen Test der kritischen Schnittstelle.

Prüffrage: Welches Gewicht würdest du vor Kenntnis des Ergebnisses vertreten?

Zwischenfazit: Ein Punktesieg ist abhängig von den Gewichten.

Entscheidungspunkt 3: Den Kippwert prüfen

STOPP: Die Software erfüllt die zugesagte Schnittstelle nur mit teurer Sonderentwicklung. Was tust du?

In der Geschichte testet die Gruppe beide Schnittstellen und erhält neue Kostenspannen. Die Entscheidung fällt weiterhin zugunsten von Buy, unter zwei Bedingungen: verbindliche Exit-Klausel und gesicherter Datenexport. Die Gruppe dokumentiert, bei welchem Preisaufschlag oder Funktionsverlust sie neu entscheiden würde.

Prüffrage: Welche Änderung wäre groß genug, deinen Favoriten zu kippen?

Zwischenfazit: Die Matrix macht Annahmen prüfbar.

Gegenprüfung · Drei-Jahres-Vollkosten und strategischer Engpass

Rechenregel: Die genannten 95.000 Euro Kostendifferenz gelten nur bei den frei gewählten Positionen. Finanzierung, Ausfallkosten, Kündigungsfristen, Wechselaufwand und Wert der aufgeschobenen Entwicklungsarbeit sind hier nicht vollständig quantifiziert. Die Nutzwertanalyse ergänzt die TCO-Rechnung. Beide gehören in die Vorlage.

Welche Denk- und Organisationsfehler werden im Rückblick sichtbar?

Make or Buy ist eine Entscheidung über den künftigen Betrieb samt Anschaffungspreis. Bei Make liegen Kontrolle und Anpassung näher im Unternehmen; dafür entstehen eigene Wartung, Personalausfall- und Sicherheitsrisiken. Bei Buy können Updates und Support leichter planbar sein; dafür wächst möglicherweise die Bindung an einen Anbieter. Die Nutzwertanalyse hilft, unterschiedliche Kriterien nebeneinanderzustellen. Kriterien und Gewichte wählen Menschen, deshalb bleibt sie eine Abwägung. Zur Kontrolle: Make = 0,30 × 2 + 0,25 × 5 + 0,25 × 2 + 0,20 × 4 = 3,15. Buy = 0,30 × 5 + 0,25 × 3 + 0,25 × 4 + 0,20 × 2 = 3,65. Vor einem Beschluss in der Praxis müssen Bewertungsskalen und Gesamtkosten vollständig erklärt sein. Fehlende Muss-Kriterien dürfen nicht in einem hohen Durchschnitt verschwinden.

Mehr zu den Methoden hinter diesem Fall findest du unter Nutzwertanalyse und Entscheidungsmatrix.

Welche Lehren lassen sich übertragen?

1. Muss-Kriterien definieren: Datenexport, Sicherheit und notwendige Funktionen zuerst prüfen.
2. Lebenszykluskosten rechnen: Entwicklung, Betrieb, Integration und Ausstieg berücksichtigen.
3. Gewichte vorab festlegen: Ergebnissteuerung durch nachträgliche Gewichtung vermeiden.
4. Kippwerte suchen: Prüfen, welche Preis- oder Leistungsänderung die Wahl umdreht.
5. Verantwortung sichern: Der Einkauf und die IT brauchen klare Rollen bei späteren Entscheidungen.

Die Matrix ist vor allem dann problematisch, wenn das Management vorab bereits beschlossen hat, wer gewinnen soll. Dann verwandeln scheinbar neutrale Zahlen die Präferenz in ein technisches Artefakt. Hilfreich ist ein gemeinsamer Workshop mit Kundenservice, IT, Controlling und Datenschutz, der die Muss-Kriterien vor der Anbieterbewertung dokumentiert. Danach rechnet das Team Szenarien: erwarteter Betrieb, teurere Integration und später Anbieterwechsel. Auch eine Option mit höherem Nutzwert kann strategisch schwächer sein, etwa wenn der Organisation die Leute für die Wartung fehlen. Solche Grenzen gehören ausdrücklich neben die Gesamtpunktzahl.

Was würdest du in deiner eigenen Situation entscheiden?

Häufige Fragen