„Selber bauen ist immer teurer." Das ist der Satz, mit dem in den meisten Mittelständlern die Diskussion endet, bevor sie angefangen hat. Und er stimmt sogar — solange man nur die erste Zahl anschaut. Die Lizenz der Standardsoftware steht im Angebot, schwarz auf weiß, vergleichbar, abgesegnet. Was der Eigenbau kostet, ist eine Schätzung mit Unsicherheit. Eins davon klingt nach Risiko, das andere nach Sicherheit. Nur rechnet diese Gegenüberstellung den teuersten Posten nicht mit ein: den Customizing-Aufwand, den die Standardlösung über fünf Jahre verursacht, weil euer Prozess an zwei, drei Stellen eben nicht der Standard ist.
Für den IT-Leiter ist Build vs. Buy keine akademische Frage. Es ist die Entscheidung, die er vor der Geschäftsführung verantworten muss — und zwar nicht heute, sondern in drei Jahren, wenn das gewählte System entweder still läuft oder still nervt. Kauft er Standard und der Prozess passt nicht, biegt er jahrelang den Betrieb um die Software oder bezahlt jeden Sonderfall als Customizing-Projekt. Baut er selbst und unterschätzt den Betrieb, sitzt er auf einem System, das nur läuft, solange die richtigen Leute da sind. Beide Fehler sind teuer. Beide passieren, weil die Entscheidung als Glaubensfrage geführt wird statt als Rechnung.
Warum die Entscheidung so oft falsch gestellt wird
Build oder Buy wird in den meisten Häusern als Lagerfrage verhandelt, nicht als Sachfrage. Es gibt die Standard-Fraktion — meistens getrieben von dem nachvollziehbaren Wunsch, nichts selbst betreiben zu müssen, und vom Argument „das nutzen tausend andere auch". Und es gibt die Eigenbau-Fraktion, oft im Haus selbst, die genau weiß, wo der Standard nicht passt, und der ein zugekauftes Korsett zuwider ist. Beide haben recht, und beide haben unrecht — weil die Frage gar nicht „entweder oder" lautet. Sie lautet: an welchen konkreten Stellen weicht unser Prozess vom Standard ab, und was kostet uns genau diese Abweichung über die nächsten fünf Jahre?
Das ist eine langweilige Frage. Sie hat keine Pointe, sie taugt nicht für eine Grundsatzdiskussion, und sie zwingt beide Lager, ihre Überzeugung gegen eine Liste einzutauschen. Genau deshalb wird sie so selten gestellt. Es ist bequemer, sich für eine Seite zu entscheiden und die andere für naiv zu halten, als die zwei, drei Stellen ehrlich zu benennen, an denen das eigene Geschäft anders tickt als der Markt. Aber diese zwei, drei Stellen sind die ganze Entscheidung. Alles andere ist Geschmack.
Build vs. Buy ist keine Glaubensfrage.
Ein Projekt, an dem die Rechnung kippte
In einem unserer Projekte stand ein mittelständischer Hersteller vor genau dieser Entscheidung. Es ging um die Auftragsabwicklung, rund 7.000 Aufträge im Monat, und auf dem Tisch lag eine etablierte Standardlösung. Die Lizenz war klar kalkuliert, der Anbieter solide, die Demo überzeugend. Die interne Schätzung für eine Eigenentwicklung lag deutlich darüber — auf den ersten Blick eine eindeutige Sache. Der IT-Leiter sollte „Buy" unterschreiben und hatte ein ungutes Gefühl, das er nicht beziffern konnte.
Wir haben dann nicht über die Lizenz geredet, sondern den Prozess durchgegangen und gefragt: Wo genau macht ihr es anders als alle anderen? Es kamen drei Stellen heraus. Eine eigene, über Jahre gewachsene Logik zur Chargen- und Restmengenverwaltung, die kein Standard so abbildet. Eine Sonderkondition für rund vierzig Stammkunden, die quer durch die normale Preislogik läuft. Und eine Übergabe an die Produktionsplanung, die im Haus seit Jahren auf eine sehr spezifische Art funktioniert und die niemand antasten wollte, weil daran die halbe Fertigung hängt.