In meinem letzten Beitrag habe ich darauf hingewiesen, wie scheinbar einfache Entscheidungen im Kontext einer diversen und komplexen Unternehmens-IT zu einer Herausforderung werden können. Zum Beispiel, wenn es darum geht, ein Softwaresystem zu kaufen oder selbst zu entwickeln, werden wichtige Aspekte, wie Opportunitätskosten, Wertschöpfung und Abhängigkeit von selbst gebauten Lösungen, leicht übersehen.
Unternehmen können es sich nicht leisten, für jede Entscheidung in eine Analyse-Paralyse zu verfallen. Gleichzeitig dürfen sie, besonders wenn es um grosse Summen geht, auch nicht ihrem Bauchgefühl folgen. Erfahrene Führungskräfte und Architekten greifen daher auf Heuristiken zurück, wie in unserem Fall: Entwickle das, was das Unternehmen von der Masse abhebt, kaufe den Rest. Ganz einfach, oder? Jetzt müssen Sie aber noch entscheiden, ob das benötigte System Ihr Unternehmen von der Konkurrenz abheben würde. Gute IT-Entscheidungen hängen daher von guten Geschäftsentscheidungen ab. Im Folgenden finden Sie einige Regeln, die Ihnen helfen können, eine genauere Grenze zwischen Kaufen und selber Entwickeln zu ziehen.
- Es fängt immer mit dem Geschäft an
Es gibt eine alte Weisheit, die gemeinhin Einstein zugeschrieben wird: „Wenn ich eine Stunde Zeit hätte, um ein Problem zu lösen, würde ich 55 Minuten damit verbringen, über das Problem nachzudenken und fünf Minuten über die Lösung“. Dieser Ratschlag gilt ganz besonders für die IT. Denn wenn man das Geschäftsproblem erst einmal gründlich verstanden ist, wird die IT-Entscheidung schnell offensichtlich.
So entschied sich McDonald’s beispielsweise nach mehreren Versuchen, Point-of-Sale-Software von der Stange zu beschaffen, für den Bau eines eigenen integrierten Kassensystems. Dieses System unterstützt nicht nur die Kundenerfahrung beim Bestellen und Bezahlen, sondern auch die betriebliche Effizienz. Denn die Restaurants von McDonald’s sind im Grunde Einzelhandelsstandorte, die mit einem Produktions-Backend, mehreren Lieferkanälen (Drive-Thru, Schalter, Lieferung, Service am Tisch) und mehreren Bestellkanälen (Mobil, Schalter, Kiosk) gekoppelt sind. Die Vorteile einer In-House Lösung wurden noch deutlicher, als sich die Erwartungen der Kunden in Richtung Treueprogramme, neuen Marketingkampagnen, Vorbestellungen und Omnichannel-Engagement zu verschieben begannen. Die Verwendung einer kommerziellen Plattform hätte bedeutet, dass man auf einen Anbieter hätte warten müssen, bis dieser eine Verschiebung der Kundenerwartungen branchenweit erkannt und entsprechend mit der Umgestaltung der Software reagiert hätte, wodurch jede mögliche Differenzierung zunichte gemacht worden wäre.
- Bauen Sie nicht nach, was bereits vorhanden ist
Der Bau einer Fast-Kopie eines bestehenden Systems führt kaum zu den erhofften Ergebnissen. Bei der Entscheidung Buy vs. Build geht es nicht darum, eine Zelle Ihrer existierenden IT-Landschaft entweder mit einem neuen System zu füllen. Vielmehr soll die IT-Landschaft so umgestaltet werden, dass sie zur Geschäftsstrategie passt. Dann bauen Sie genau das, was zu dieser neuen Landschaft passt.
- Schnelligkeit begünstigt den Eigenbau
Im Fall von McDonald’s hat sich die maßgeschneiderte Lösung wirklich ausgezahlt, als die Branche zu einem anderen Geschäfts- oder Engagementmodell überging. Bei einer kommerziellen Lösung müssten Sie hingegen warten, bis der Anbieter die gewünschte Funktion bereitstellt. In einer sich langsam entwickelnden Branche ist es vertretbar, sechs bis zwölf Monate auf eine Lösung zu warten. In einer schnelllebigen Welt, die von Geschwindigkeitsvorteilen bestimmt wird, kann jedoch ein sechsmonatiger Vorsprung vor der Konkurrenz das Spielfeld erheblich zu Ihren Gunsten verschieben. Dies ist genau der Grund, warum so viele digitale Unternehmen Lösungen intern bauen, obwohl sie hohe Opportunitätskosten haben. Und denken Sie nicht nur an die heute benötigten Funktionen, sondern berücksichtigen Sie auch die Möglichkeit, dass aufgrund des Wettbewerbsdrucks oder der technologischen Entwicklung neue Anforderungen entstehen werden. In der heutigen, schnelllebigen Welt rückt dieser Tag immer näher.
Über den Autor
Als Enterprise Strategist bei Amazon Web Services berät Gregor Hohpe führende Anbieter im Bereich Technologie bei der Transformation ihrer Technologieplattform und ihrer Organisation. Dank seiner Erfahrung als Smart Nation Fellow der Regierung von Singapur und als Chief Architect bei der Allianz SE verbindet er die Unternehmensstrategie mit der technischen Entscheidungsfindung und umgekehrt. Er teilt seine Gedanken zur Architektur und Architekten gerne in seinen Büchern, unter anderem Der Softwarearchitektenaufzug und Cloud-Strategie.
Dieser Beitrag ist der zweite von zwei Teilen, die dieses Thema beleuchten sollen. In der Zukunft lesen Sie hier mehr dazu.
