Make-or-Buy: selbst entwickeln, zukaufen oder partnern

Warum reicht der Kostenvergleich nicht?

Weil er eine Momentaufnahme vergleicht und die Frage nach der Fähigkeit ausblendet. Zwei Beispiele zeigen die Grenze.

Erstes Szenario: Ein Zulieferer rechnet die Eigenfertigung eines Bauteils mit 11 Euro, der Zukauf liegt bei 9. Die Rechnung sagt Zukauf. Wenn dieses Bauteil aber die Toleranz enthält, für die Kunden euch nehmen, gibt ihr mit dem Zukauf den Grund eurer Beauftragung aus der Hand. In fünf Jahren kennt der Lieferant euren Kunden.

Zweites Szenario: Ein Maschinenbauer entwickelt seine Bediensoftware selbst, weil die eigene Elektronikabteilung Kapazität hat. Der Vergleich rechnet nur die Entwicklungsstunden. Nicht gerechnet sind Pflege über zehn Jahre, Schulung, Sicherheitsupdates und die Leute, die für neue Anforderungen dauerhaft gebunden bleiben.

Die brauchbare Frage lautet deshalb: wofür nehmen uns Kunden. Was darauf einzahlt, bleibt im Haus. Der Rest wird beschafft, unabhängig davon, wer es billiger könnte.

Ein Argument taucht in diesen Diskussionen regelmäßig auf und trägt seltener als gedacht: freie Kapazität. „Die Maschine läuft sowieso“ rechnet die Auslastung von heute gegen eine Bindung von Jahren. Wenn die Kapazität in zwei Jahren gebraucht wird, zahlt ihr den Eigenbau dann doppelt, nämlich in verdrängten Aufträgen. Freie Kapazität rechtfertigt einen Anlauf, keine dauerhafte Entscheidung.

Welche vier Kriterien zählen neben dem Preis?

Sie lassen sich in einer Tabelle nebeneinanderlegen und machen die Entscheidung nachvollziehbar, auch wenn sie gegen die Rechnung ausfällt.

Die Umkehrbarkeit wird am häufigsten übersehen. Eine Eigenentwicklung bindet Leute, eine Beschaffung bindet Verträge. Beides lässt sich beenden, aber zu sehr unterschiedlichen Kosten. Diese Differenz gehört in die Entscheidung.

Was gehört bei einer Eigenentwicklung in die Rechnung?

Mehr als die Entwicklungsstunden. Vier Posten fehlen in den meisten internen Kalkulationen.

• Pflege über die Lebensdauer. Eine Software oder ein Sonderbauteil begleitet euch zehn Jahre. Die Pflege kostet jährlich einen Anteil der Entwicklung und bindet dieselben Leute.
• Personenabhängigkeit. Wenn zwei Leute die Lösung verstehen, ist das ein Risiko mit Namen. Dokumentation und ein dritter Kopf kosten extra.
• Verpasste Alternativen. Die Leute, die entwickeln, arbeiten nicht an etwas anderem. Dieser Posten steht in keiner Kalkulation und ist bei knapper Entwicklungskapazität der größte.
• Anlaufzeit bis zur Reife. Die erste Fassung ist nicht die, mit der ihr in den Markt geht. Zwei Iterationen sind normal.

Mit diesen vier Posten fällt eine Eigenentwicklung selten billiger aus als der Zukauf. Sie bleibt trotzdem richtig, wenn das erste Kriterium aus der Tabelle oben zutrifft.

Umgekehrt hat auch der Zukauf Posten, die im Preis nicht stehen. Die Einbindung in eure Abläufe, die Abhängigkeit von den Terminen des Lieferanten, der Aufwand für Qualitätssicherung beim Wareneingang und die Frage, wer beim Kunden haftet, wenn das zugekaufte Teil ausfällt. Bei Software kommen Schnittstellenpflege und Versionswechsel hinzu. Ein ehrlicher Vergleich stellt beide Listen nebeneinander, statt nur die eine aufzumachen.

Wann ist eine Partnerschaft der bessere Weg?

Wenn ihr die Fähigkeit braucht, sie aber nicht besitzen müsst und wenn der Partner am Ergebnis beteiligt ist.

Typische Fälle im Mittelstand: eine Softwarekomponente, die euer Produkt ergänzt. Eine Dienstleistung, die ihr mit anbieten wollt, ohne Personal dafür aufzubauen. Ein Vertriebszugang in einem Markt, in dem euer Name nichts sagt.

Eine Partnerschaft ist allerdings nur so gut wie ihre Ausstiegsregel. Was passiert, wenn der Partner verkauft wird, wenn er euren Wettbewerber aufnimmt oder wenn seine Prioritäten wechseln. Diese drei Fälle gehören in den Vertrag, bevor das erste Projekt läuft.

Dazu eine praktische Faustregel: Wenn mehr als ein Fünftel eures Umsatzes an einer Partnerschaft hängt, ist sie keine Partnerschaft mehr. Sie ist eine Abhängigkeit und gehört wie eine behandelt, also mit einem zweiten Weg im Hintergrund.

Wie entscheidet ihr im Führungsteam?

Mit einer Vorlage, die beide Wege beschreibt, und mit einer Person, die entscheidet. Runden entscheiden solche Fragen selten, weil jede Seite gute Argumente hat.

Bewährt hat sich eine Seite mit fünf Punkten: die Aufgabe, die beiden Wege mit Kosten über fünf Jahre, die vier Kriterien aus der Tabelle mit einer Einschätzung, die Empfehlung und die Frage, unter welcher Bedingung die Entscheidung neu bewertet wird. Der letzte Punkt nimmt der Diskussion die Schärfe, weil niemand für die Ewigkeit entscheidet. Eine solche Seite entsteht in zwei Stunden, wenn die Zahlen vorliegen, und sie ist ein Jahr später noch lesbar.

Vorsicht bei einem Muster, das regelmäßig auftritt: Wenn die Abteilung, die entwickeln möchte, auch die Vorlage schreibt, fällt der Vergleich zugunsten der Eigenentwicklung aus. Dagegen hilft, beide Wege von je einer Person zu vertreten und die Entscheidung bei einer dritten zu lassen.

Was tun, wenn eine alte Entscheidung falsch war?

Sie überprüfen, sobald sich eines der vier Kriterien geändert hat. Das ist der einzige sinnvolle Anlass, und er kommt häufiger als gedacht.

Konkret: Ein Zukaufteil wandert in den Kern, weil Kunden nach genau dieser Eigenschaft fragen. Ein selbst gebautes Werkzeug ist am Markt inzwischen als Standard verfügbar, gepflegt und günstiger. Ein Lieferant wird von einem Wettbewerber übernommen.

Eine Umkehr ist unangenehm, weil sie eine frühere Entscheidung sichtbar korrigiert. Sie ist trotzdem billiger als das Festhalten, und sie wird leichter, wenn bei der ersten Entscheidung aufgeschrieben wurde, unter welcher Bedingung sie neu zu bewerten ist. Dann führt die Überprüfung einen Beschluss aus statt einen Fehler einzugestehen.

Eine Umkehr braucht außerdem einen Übergang. Wer eine Eigenentwicklung ablöst, hält sie mindestens eine Produktgeneration lang lauffähig, weil Bestandskunden weiter damit arbeiten. Wer einen Lieferanten austauscht, baut den neuen parallel auf, bevor er den alten kündigt. Beides kostet ein Quartal und verhindert, dass eine richtige Entscheidung an ihrer Ausführung scheitert.