Build or buy — ist einerlei

Ja, manchmal kann sich auch das störrischste Unternehmen nicht mehr drücken – neue Software will angeschafft werden – ist ja auch bald Weihnachten und so. 🎄

Und wenn die IT im eigenen Hause etwas auf sich hält, Fachabteilungen schon voll auf No-Code (oder Excel!) abfahren oder man auch noch eine eigene Entwicklungsabteilung hat, dann stellt sich die traditionelle Frage:

Build or Buy

Schade nur, dass keine echte Entscheidung ist. Denn, das muss ich dir leider mal sagen, beides sind nur Extreme eines Kontinuums auf einer extrem durchlässigen Skala.

Unternehmenssoftware, abseits vom primitivsten vielleicht, ist niemals einfach nur Buy. Und Build, ja Build kann total präsent und ausschlaggebend sein, auch wenn du in der Praxis nichts, wirklich nichts davon mitbekommst. Schräg, oder?

Blicken wir erstmal auf Buy. Eigentlich ist das eine tolle Sache. Schlüsselfertig landet die Software vor meiner Eingangstüre, wird einmal flugs von der IT installiert und los geht’s. Das reinste Weihnachtswunder! Wahnsinn, oder? Nur leider auch glatt gelogen. Vertriebler, die dir so etwas andrehen wollen, setzt du besser gleich wieder vor die Tür.

Software ist immer Arbeit. Im einfachsten Fall geht es nur um Installation, Support und Wartung. Das allein kann schon auf Trab halten, wenn man’s selbst machen muss. Gut, dass es Software-as-a-Service gibt. Das deckt im Idealfall das alles ab. Anpassen muss man so eine Software oft genug dennoch. Denn die eigenen Prozesse und Daten müssen ja abbildbar sein. Und die eigene Sicherheitsstrategie will abgebildet sein. Und dann noch der Datenschutz! Oft genug soll es auch einen Datenaustausch geben, der muss ja auch irgendwo herkommen.

Die Software will also auch noch (und das nicht nur initial, sondern immer wieder einmal) konfiguriert werden. Und Konfiguration ist ein weiter Begriff. Das kann von einfachen Einstellungen über komplexe Prozesse bis in die Erstellung angepasster Oberflächen gehen. Und vom Anpassen einiger Zahlen bis zu recht komplexen Low-Code-Lösungen. Spätestens hier betreten wir also den Bereich Build.

Auch den können wir noch auslagern. An Consultingfirmen zum Beispiel, was in vielen Bereichen wie ERP und PLM sogar der Standard wäre. Oder an Systemhäuser, Agenturen oder Freelancer, die mir die passenden Module in die Software hinein programmieren, wie man so schön sagt (aber mal ehrlich, im Grunde genommen ist auch das nur eine Form von Konfiguration). Oder man geht noch weiter auf Build-Seite herüber und sucht sich einen Entwickler für eine passgenaue Individualsoftware, die das Problem löst. Das kann extern passieren oder sogar mit dem eigenen Entwicklungsteam, wenn es nichts anderes zu tun hat.

Die Unterscheidung Build or Buy ist also keine absolute. Eigentlich ist sie überhaupt keine Entscheidung, denn es ist immer Build.

Die Entscheidung, die ich als Unternehmen treffen muss, ist, wie viel Build ich selbst erledigen möchte und wie viel ich auslagere. Und natürlich auch, wie viel Build ich brauche. Viele Menschen, gerade Berater, setzen ja gern auf Standardisierung. Weil das, offensichtlich (Hah! Ja, bestimmt..) alles einfacher macht und die Komplexität reduziert. Mit dem Ziel, weniger absolutes Build zu haben.

Hmm.

Wer schon mal eine ERP-Einführung gemacht hat oder auch nur die Idee gekommen ist, das ERP-Beratungshaus zu wechseln, weiß, dass das in der Realität in aller Regel nicht klappt.

Und das ist nicht das einzige Problem. Ich empfehle das generell nicht übereilt zu entscheiden, selbst wenn ein Berater das empfiehlt. Selbst wenn ich dieser Berater bin (okay, ich würd’s nicht empfehlen, aber trotzdem sollte man das ja der Vollständigkeit erwähnen). Gerade in KMUs. Aber auch bei großen Mittelständlern.

Denn mit jedem Schritt in Richtung Standardisierung erhöhe ich das Risiko, die Stärken und Alleinstellungsmerkmale zu torpedieren. Mittelständler sind so effektiv, weil sie ihre Stärken ausspielen. Und das spiegelt sich in ihren Strukturen und Prozessen wider. IT-Systeme, die dem Unternehmen etwas nützen, müssen diese Strukturen und Prozesse abbilden. Sonst gehen die Stärken und damit der Wettbewerbsvorteil verloren.

Das ist im Übrigen keine Einladung, alles blind so weiterzufahren, wie es ist.

Change happens!

Nutzlose Prozesse gehören nicht ins ERP, sondern in die Tonne. Veraltete Strukturen gehören modernisiert. Und auch diese Veränderungen müssen sich in der Software widerspiegeln.

Denn Conway’s Gesetz (dass sich jeder IT-Entscheider an die Wand plakatieren sollte) gilt nämlich nicht in beide Richtungen. Zur Erinnerung, das Gesetz besagt, dass die Struktur von Systemen, die von einer Organisation entwickelt werden, immer die Kommunikation und damit das Wirken der Organisation widerspiegeln.

Chaostruppen bauen Chaosprodukte und damit auch Chaos-IT. Standardisierte IT-Systeme sorgen aber umgekehrt nicht für mehr Ordnung im eigenen Laden. Denn die standardisierten Systeme, die für die (oft aus gutem Grund) etablierte Praxis nicht funktionieren, bleiben links liegen. Und werden, ob man das will oder nicht, durch Guerilla-Prozesse und Schatten-IT ersetzt. Das ist nicht das, was du brauchst. Und erst recht nicht das, was du verdient hast.

Also lieber mit Besonnenheit die Sache angehen. Stärken stärken und Schwächen schwächen. Mehr Build wagen!

Wir helfen euch übrigens nicht nur bei der Entscheidung Build or Build. Sondern übernehmen als verlängerte Werkbank auch die Build-Anteile, die ihr gewissenhaft und passend zu eurer Unternehmenskultur erledigt sehen wollt.

Nur mal so als Tipp. 🎅🏼 Ist ja auch bald Weihnachten und so… 🎄