Software ist die zentrale Zutat der Digitalisierung. Ohne sie sind innovative Produkte und Dienstleistungen nicht mehr denkbar. Die Wettbewerbsfähigkeit hängt entscheidend von der Fähigkeit ab, Software-intensive Produkte und Dienstleistungen schnell und mit höchster Qualität zu erstellen. In der Softwareentwicklung steht man damit vor der klassischen Make-or-Buy-Entscheidung.
Beide Varianten haben in Bezug auf Kosten, Qualität, Zeit sowie Ressourcen und Risiken ihre Vor-und Nachteile. Auf diese möchte ich an dieser Stelle allerdings nicht weiter eingehen, sie wurden bereits zuhauf diskutiert. Für mich ist der Fokus ein anderer: der immer weiter zunehmende Mix von Buy und mAKE = BAKE! Früher wurde im Rahmen der Softwareentwicklung viel zu oft in einem Schwarz-Weiß-Schema gedacht:
Make = Eigenentwicklung der Software
Buy = Standardsoftware (ggf. noch mit relativ teurer Anpassungsmöglichkeit)
Durch den technologischen Fortschritt gibt es hier mittlerweile ganz andere Möglichkeiten, den individuellen Anforderungen gerecht zu werden. Beim BAKE-Ansatz werden sowohl Buy-Risiken wie komplette Abhängigkeit, Know-how-Verlust sowie Standardsoftware-Inkompatibilitäten als auch Make-Risiken wie unterschätzte Entwicklungs- und Wartungsaufwände und eine lange Time-to-Market reduziert. Gleichzeitig entsteht durch den Zugriff auf das jeweilige Spezialwissen die Chance auf eine höhere Innovationsdynamik.
Neben den positiven Aspekten gibt es natürlich auch Herausforderungen: Hierzu zählen die Koordination mehrerer Verträge und Rechte sowie Technologiedifferenzen. Auch das oben genannte Risiko der Abhängigkeit kann nicht vollständig eliminiert, sondern nur reduziert werden. Aus meiner Sicht überwiegen die Vorteile aus dem BAKE-Ansatz allerdings in den meisten Fällen – insbesondere im Hinblick auf die Time-to-Market. Werfen wir also einen Blick auf die beiden BAKE-Optionen:
1. Eigenentwicklung im Zusammenspiel mit (bestehenden) Fremdlösungen
Viele bekannte Beispiele kommen aus der Automobilentwicklung. Die Fertigungstiefe der einzelnen Hersteller ist relativ gering, viele Teile werden von Spezialisten dazu gekauft. Das ist auch auf der Ebene der Softwareentwicklung möglich. Fremde Softwarekomponenten können einfach integriert werden – seien es Komponenten aus der Entwicklung anderer Unternehmenseinheiten oder Lösungen aus dem Open-Source-Umfeld bzw. von spezialisierten Softwarehäusern. Je nach Unternehmensausrichtung und Wertschöpfung können im Nachgang auch dedizierte Komponenten nachentwickelt oder gekauft werden (=Rückwärtsintegration). So lässt sich die “Buy-Komponente” ablösen.
Auch in der Reisebranche – hier bin ich primär unterwegs – gibt es viele Beispiele für Eigenentwicklungen im Zusammenspiel mit (bestehenden) Fremdlösungen. So u.a. im Umfeld nationaler und internationaler Reisebuchungslösungen, bei deren Entwicklung diverse Content-Schnittstellen für z.B. Flug, Hotel und Mietwagen benötigt werden. Diese liegen derzeit nicht standardisiert vor. Das bedeutet, dass jede benötigte Schnittstelle individuell angebunden und gepflegt werden muss. Für den API-Lieferanten heißt dies, dass er sehr viele Kunden direkt betreuen muss. Deshalb setzt der Markt auf API-Spezialisten, die den Content bündeln und standardisiert zur Verfügung stellen. Wie man in der Darstellung bereits erkennen kann, vereinfacht das nicht nur die Integration sowie die Kommunikation während und nach der Entwicklung, sondern reduziert auch die Komplexität. Darüber hinaus gewinnt man an Unabhängigkeit – ein Wechsel oder das Hinzunehmen einer Schnittstelle ist einfach möglich.
Schnittstellenintegration und -management ohne und mit API-Spezialist:
2. Maßgeschneiderte Fremdlösung in Verbindung mit eigenen Komponenten
Wenn Lösungen von der Stange nicht mehr reichen und eine Eigenentwicklung nicht sinnvoll ist, braucht es neue, individuelle Lösungsansätze. Was früher noch undenkbar war, ist mit der heutigen Technologie möglich: Individualsoftware zum Preis von Standardsoftware und zwar auf Basis wiederverwendbarer Komponenten. Oft spricht man hier auch von einem Baukastensystem oder White Labeling: Man wählt die gewünschten Bausteine aus, lässt ggf. Bausteine dazu bauen oder bringt eigene Bausteine mit. Diese können z.B. über einen Service-Manager oder Schnittstellen integriert werden. So erhält man eine individuelle Software in Verbindung mit dem eigenen Know-how. Spezialwissen, das zur Differenzierung am Markt dient, bleibt damit ausschließlich in den Händen des Unternehmens.
Auch hier wieder ein Praxisbeispiel aus der Reisebranche: Das Standard-Geschäftsreisebuchungssystem eines global agierenden Finanzinstituts stieß an seine Grenzen. Mit dem Standardset konnten Reiserichtlinien immer schlechter abgebildet werden und es fielen zeitaufwändige Sonderprogrammierungen an. Ziel war es deshalb, eine Software zu implementieren, die eigenständig und ohne großen Aufwand betreut und weiterentwickelt werden kann. Die Wahl fiel auf das Travel Management System von PASS, welches von uns als flexibles Baukastensystem angelegt wurde: neben einer komponentenbasierten Softwareentwicklung zeichnet es sich vor allem durch eine integrierte Rules Engine (Open Source) aus. Diese ermöglicht Kunden, – unabhängig vom Hersteller – Know-how einzupflegen und es internen wie externen Anwendern zur Verfügung zu stellen.
Mein Rezepttipp
Was ist nun der perfekte Buy-or-Make-Mix? So pauschal lässt sich das leider nicht sagen. Er hängt von vielen Faktoren ab. Zu nennen sind hier: Time-to-Market, Gesamtkosten und -einsparungen (Projekt- und Supportzeit), technologische Aspekte (Non-Functional-Requirements) und Risiken. Außerdem spielen interne Faktoren (Strategie, Know-how und Ressourcen) sowie externe Rahmenbedingungen (Lösungsverfügbarkeit und vertragliche Rahmenbedingungen) eine Rolle. Ich empfehle daher folgendes Vorgehen:
Viel Erfolg beim Backen bzw. bei der Softwareentwicklung!
Bildquelle: Shutterstock
