In unserem ersten Artikel dieser Artikelreihe haben wir einen Alptraum-Rollout skizziert. Wir haben vorgestellt, wie man die Ausgangssituation eines Rollouts einschätzen und beurteilen kann, um das eigene Umfeld zu identifizieren. Nun geht es einen Schritt weiter!
Im Rollout Management ist es wie im Schach – jede Bewegung muss durchdacht sein. Dabei ist nicht nur die nächste Entscheidung wichtig, sondern auch mehrere Schritte vorauszudenken und auf unerwartete Änderungen angemessen zu reagieren. In diesem Beitrag tauchen wir tiefer in die Welt des Rollout Managements ein und beleuchten die Bedeutung der IT Architektur, die Chancen und Risiken sowie die Eignung verschiedener Rollout-Ansätze für unterschiedliche Softwarearten.
Bevor die Planung des Rollouts losgehen kann, muss eine fundamentale Entscheidung getroffen werden, die den Projektverlauf beeinflusst: Kaufen wir eine Software ein oder bauen wir sie selbst? Können wir sogar eine bestehende Software-Lösung wiederverwenden?
Die Make-or-Buy-Entscheidung zwischen Standardsoftware und Individualsoftware erfordert eine sorgfältige Abwägung der Vor- und Nachteile beider Optionen. Die Entscheidung hängt von verschiedenen Faktoren ab, darunter die vorhandenen IT-Ressourcen, der Anpassungsbedarf, die Kontrolle über die Softwareentwicklung und die strategische Ausrichtung des Unternehmens. Mit diesem Artikel unterstützen wir bei der Entscheidungsfindung, indem wir die wichtigsten Kriterien für Standard- und Individualsoftware gegenüberstellen.
Bei der Make-or-Buy-Entscheidung sollte stets geprüft werden, ob eine Software-Lösung wiederverwendet werden kann. Falls eine existierende Software die ermittelten Anforderungen treffend abbilden kann, ist diese i.d.R. zu bevorzugen.
Die Wiederverwendung einer bestehenden Software-Lösung ist sinnvoll, wenn
Standardsoftware, die bereits am Markt vorhanden und von einem Hersteller entwickelt ist, bietet signifikante Vorteile wie schnelle Verfügbarkeit, Risikoreduktion bei der Entwicklung, allgemeine Erprobung und umfassende Dokumentation. Sie ermöglicht auch eine Fokussierung auf das Kerngeschäft und die Optimierung von Prozessen. Die reibungslose Integration der gekauften Software in die bestehende IT Architektur ist hierbei entscheidend. Eine umfassende Analyse der vorhandenen Systeme ist also erforderlich: Wie gut lässt sich die Standardsoftware in die bestehende Systemlandschaft integrieren?
Bei Standardsoftware besteht der wesentliche Vorteil in der zügigen Bereitstellung einer fertigen Lösung, die am Markt erprobt ist, von einem Hersteller unterstützt wird und wenig bis keine Eigenentwicklung benötigt. Ein großes Hindernis ist die allgegenwärtige Systemanpassung, die bei der Einführung eines neuen Warenwirtschaftssystems bereits vielen Verantwortlichen Kopfzerbrechen bereitet hat. Diese Projekte können sehr kostenintensiv sein. Wenn ein Unternehmen seine bestehenden Prozesse nicht anpassen kann (oder will), so wird das Konzept „Standardsoftware“ durch hohe Anpassungsaufwände und Abweichungen vom Standard schnell ad absurdum geführt. Daher sollte man die bestehenden, ggf. unveränderbaren Prozesse in die Anforderungen aufnehmen und eine Nutzwertanalyse durchführen: Zu welchem Grad kann eine Standardsoftware diese Anforderungen tatsächlich abdecken, ohne dass diese angepasst werden muss? Zusätzlich ist eine Architekturbewertung ratsam, um festzustellen, wie gut die Software in die bestehende IT Architektur (und deren Zielbild) eingegliedert werden kann.
Eine Standardsoftware ist sinnvoll bei:
Eine selbst entwickelte Individualsoftware, maßgeschneidert für spezifische Anforderungen, bietet Vorteile wie Flexibilität, Anpassungsfähigkeit, Integration, Schlankheit und Herstellerunabhängigkeit. Gleichzeitig bringt sie Verantwortung mit sich. Das Einpflegen von Änderungen, die Weiterentwicklung sowie Betrieb und Wartung liegen in der Verantwortung der eigenen IT-Abteilung. Zusätzlich wird ggf. Nischenwissen benötigt, das am Arbeitnehmermarkt rar ist.
Bei der Entwicklung einer Individualsoftware können die Anforderungen (ohne ungewollte Zusätze) in einer schlanken Software-Lösung abgebildet werden. Hierfür ist entscheidend, dass das notwendige Fachwissen sowie entsprechende Erfahrungen in der eigenen IT vorhanden sind.
Für die Eigenentwicklung sprechen folgende Punkte:
Nun haben wir verschiedene Aspekte kennengelernt, die es bei der Make-or-Buy-Entscheidung zu berücksichtigen gilt. Aber eine Entscheidung steht dennoch aus. Wie kommt man nun zu einer treffsicheren und rationalen Entscheidung?
Bei der Entscheidung zwischen den verschiedenen Optionen kann eine Nutzwertanalyse hilfreich sein.
Dazu müssen klare Kriterien, die für die Organisation wichtig sind, definiert werden. Beispielsweise können dies Funktionen, Kosten, Zeit, Skalierbarkeit, Wartbarkeit und Benutzerfreundlichkeit sein. Daraufhin müssen diese Kriterien gewichtet werden, um die relative Bedeutung in der Gesamtanalyse zu reflektieren.
Im Anschluss daran können die entsprechenden Punkte für die verschiedenen Optionen (Wiederverwendung, Standardsoftware und Eigenentwicklung) vergeben werden.
Sobald alle Punkte für die Kriterien vergeben sind, kann anhand des Scores die Variante gewählt werden, die den höchsten Nutzenwert aufweist. In der von uns erstellen Abbildung ist es die Wiederverwendung, die mit 4,3 den höchsten Nutzenwert erreicht.
Nun konnten wir etwas Licht in die Entscheidung zwischen der Einführung einer am Markt bestehenden Standardsoftware und einer eigenständig entwickelten Individualsoftware bringen. Wir haben uns für eine Option entschieden. Wie geht es weiter? Wie wird die Software in die verschiedenen Länder und Abteilungen ausgerollt und wie kann sichergestellt werden, dass dies auch gelingt?
Ein Rollout bezieht sich auf die schrittweise Einführung neuer Systeme, Prozesse oder Technologien in einer Organisation. Verschiedene Rollout-Ansätze, darunter iterative (bspw. phasenweise, regional, abteilungsweise) und Big Bang, bieten unterschiedliche Herangehensweisen, um Veränderungen zu implementieren. Während der iterative Ansatz sukzessive Verbesserungen einführt, setzt der Big Bang-Ansatz auf eine umfassende Implementierung. Dieser Vergleich ermöglicht eine fundierte Entscheidung über den am besten geeigneten Rollout-Ansatz für spezifische Projekte oder organisatorische Anforderungen.
Ein entscheidender Einflussfaktor ist, ob es sich um einen Greenfield Approach oder der Ablösung von Legacy-Systemen handelt (Altsysteme). Dies kann meist nicht frei gewählt werden. Während der Greenfield Approach die Einführung einer Software-Lösung ohne bestehende Altsysteme meint, geht es bei der Ablösung von Legacy-Systemen um die Ersetzung einer bestehenden Software-Lösung.
Die Unterschiede liegen auf der Hand. Ein Greenfield-Ansatz bietet oft mehr Flexibilität und ermöglicht eine freie Gestaltung. Bei der Ablösung von Altsystemen hingegen, nehmen der bestehende Integrationsaufwand und die Umstellung von alter auf neue Software eine zentrale Rolle ein.
Im Folgenden wägen wir Chancen und Risiken vom iterativen Ansatz und dem Big Bang Ansatz ab und stellen Entscheidungsfaktoren dar.
Iterative Rollouts sind eine Implementierungsmethode, die sich durch schrittweise Verbesserungen oder schrittweise Einführung auszeichnet. Statt eine Software vollumfänglich und überall parallel einzuführen, erfolgt die Einführung in kleineren vordefinierten aufbauenden Iterationen. Dabei kann "schrittweise" sowohl den Funktionsumfang als auch eine Aufteilung der Einführung nach Regionen oder Abteilungen meinen. Diese Art des Rollouts bietet verschiedene Vor- und Nachteile. Besonders bei großen und komplexen Softwareeinführung kann ein iterativer Rollout auch die leichter umzusetzende Art sein, um die Software-Einführung zu managen.
Der iterative Rollout-Ansatz kann verschiedene Facetten aufweisen. Letztlich geht es darum, die Komplexität zu reduzieren und so beherrschbar zu machen. In der Praxis spricht man oft davon, „den Elefanten in Scheiben zu schneiden“. Dies kann regional, phasenweise, abteilungsweise oder auch durch ausgewählte Piloten realisiert werden. Jeder dieser Ansätze bietet Vor- und Nachteile und ist für verschiedene Szenarien mehr oder weniger passfähig. Es ist stets abhängig davon, wie genau die Wertschöpfungskette im Unternehmen aussieht und wie die neue Software-Lösung die tägliche (Zusammen-)Arbeit beeinflusst. Diese Wertschöpfung sollte durch den Rollout nicht negativ beeinflusst werden.
Mithilfe eines Big Bang Rollouts wird eine Software und all ihre Bestandteile für sämtliche Benutzer*innen zu einem bestimmten Termin in Betrieb genommen. Hierbei werden bestehende Systeme gänzlich abgelöst. In vielen Fällen ist auch kein „Rollback“ mehr möglich. Vor diesem Hintergrund ist es umso wichtiger, dass der Go-Live reibungslos funktioniert. Das beinhaltet die vollständige Datenmigration, final getestete Schnittstellen und Prozesse sowie die Durchführung von Trainings. Um die Akzeptanz der zukünftigen Nutzer*innen zu stärken, ist es wichtig, bereits vor dem Projekt eine umfassende Analyse und Architekturbewertung der zugrundeliegenden IT-Systemlandschaft sowie der Beschaffenheit der auszurollenden Software-Lösung durchzuführen. Im weiteren Verlauf des Projektes ist insbesondere das Change Management gefragt. Die Benutzer*innen müssen auf die Ablösung des Altsystems vorbereitet werden und in der Nutzung der neuen Software-Lösung begleitet und befähigt werden.
Der Big Bang Rollout-Ansatz ist mit signifikanten Risiken verbunden. Bei erfolgreicher Einführung bietet dieser Ansatz jedoch die Möglichkeit, ohne Parallelbetriebe eine neue Software-Lösung einzuführen. In vielen Szenarien (beispielsweise bei einer vertraglich vereinbarten Inbetriebnahme zu einem bestimmten Termin) ist ein Big Bang Rollout die einzige Option.
Um die Entscheidung zwischen den Rollout-Ansatz (Big Bang oder Iterativ) treffen zu können, sollten verschiedene Entscheidungskriterien berücksichtigt werden. Man kann zwischen produktbezogenen oder technischen Aspekten wie Systemkomplexität und Integration, zwischen gegebenen Unternehmensfaktoren wie Veränderungsbereitschaft und Risikobereitschaft unterscheiden. Je nachdem in welche Richtung die Kriterien für das Rollout Projekt tendieren kann eher ein iterativer Rollout Approach oder ein Big Bang Rollout gewählt werden.
Bei der Entscheidungsfindung für verschiedene Rollout-Ansätze sind verschiedene Kriterien zu betrachten. Diese können entweder das Produkt selbst oder Umwelt betreffen. In folgender Abbildung haben wir exemplarisch dargestellt, welche Kriterien für welche Art von Rollout-Ansatz sprechen:
Neben den oben genannten Kriterien können noch weitere Punkte eine Rolle spielen. Diese haben wir in drei Kategorien eingeteilt: Produktfaktoren sowie gegebene und beeinflussbare Unternehmensfaktoren. Diese Faktoren und deren Ausprägung sind jeweils zu betrachten und zu bewerten. Darauf basierend kann abgeleitet werden, welcher Rollout-Ansatz sich am besten eignet.
Produktfaktoren
Unternehmensfaktoren (gegebene)
Unternehmensfaktoren (beeinflussbare)
Das Rollout Management erfordert eine detaillierte Analyse, um die optimale Strategie zu entwickeln. Die IT Architektur bildet dabei die Grundlage für eine erfolgreiche Implementierung. Chancen und Risiken müssen sorgfältig abgewogen werden, und die Wahl des Rollout-Ansatzes sollte auf vielfältigen Entscheidungskriterien basieren. Wir bei Cassini sind darauf spezialisiert, maßgeschneiderte Lösungen zu entwickeln. Lassen Sie uns gemeinsam die Herausforderungen meistern und eine Rollout-Strategie gestalten, die Ihr Unternehmen zum Erfolg führt.
Im nächsten Beitrag werden wir ein umfassendes Framework für Software-Rollouts präsentieren. Mit unserer langjährigen Erfahrung haben wir bewährte Praktiken entwickelt und diese festgehalten, um Ihnen die nötige Orientierung zu bieten. Tauchen Sie mit uns ein in ein praxiserprobtes Framework, das den Weg für erfolgreiche Softwareimplementierungen ebnet. Wir freuen uns darauf, Ihnen einen fundierten Leitfaden für Ihre Rollout-Strategien zu präsentieren.
