Software-as-a-Service ist seit rund sieben Jahren ein Trend, der sich auch mehr und mehr im Business Software Bereich etabliert. Vor allem im Human Ressources Umfeld sind jährlich enorme Wachstumsraten zu verzeichnen und immer mehr Firmen wechseln von herkömmlichen, im Unternehmen installierten Software Produkten in die „Cloud“. Darüber hinaus hat sich der Anbietermarkt in den letzten zwei Jahren stark konsolidiert und auch die großen, ursprünglichen on-premise Hersteller wie z.B. Oracle und SAP sind nun zu den größten Software-as-a-Service Anbietern geworden. Dadurch ist es für Unternehmen einfacher ein Cloud-Produkt auszuwählen und damit den ersten Schritt in Software-as-a-Service zu wagen. Dennoch betreten Unternehmen dadurch Neuland, da sich die Implementierung von Cloud-Software grundsätzlich von ursprünglichen Software-Implementierungsprojekten unterscheidet und somit auch vor andere Herausforderungen stellt.
Herausforderung #1: Time-to-Value
Die größte Herausforderung in Cloud-Projekten ist meiner Meinung nach das Thema „Time-to-Value“, d.h. der Zeitraum vom Mietbeginn der Software bis zum eigentlichen Go-Live bzw. des Echteinsatzes der Software im Unternehmen. Das Problem hierbei liegt in der Tatsache, dass die Implementierungsdauer die Mietdauer und damit die tatsächliche Verwendung der Software reduziert. Insofern muss in Cloud-Projekten der Implementierungszeitraum so kurz wie möglich gehalten werden. Das erfordert ein grundlegendes Umdenken auf Kundenseite, weg von monatelangen Geschäftsprozessdefinitionen und Konfigurationsworkshops und hin zu sogenannten „rapid deployments“ auf Basis von „Best-Practices“ Konfigurationen. Diese müssen vom externen Implementierungspartner nach Prüfung der Kundenanforderungen und durch eine Vielzahl von Projekten beigesteuert werden können.
Mein Tipp: Arbeiten Sie mit erfahrenen Implementierungspartnern zusammen, die viel Cloud-Erfahrung haben und referenzierbare Best-Practices Konfigurationen vorweisen können. Passen Sie derartige Konfigurationen an – das ist definitiv schneller und effizienter als eine Konfiguration von Grund auf zu beginnen.
Herausforderung #2: Konfiguration statt Customization
Software-as-a-Service basiert auf einer einheitlichen „Code-Basis“, d.h. alle Kunden, die eine Cloud-Software desselben Herstellers verwenden greifen auf dasselbe Produkt zu (also immer die aktuellste Version). Insofern ist (zumindest derzeit), eine Customization (=„Umprogrammierung“) nur sehr eingeschränkt möglich. Auch das stellt einen enormen Unterschied zu on-premise Software dar, wo Kunden in der Lage sind, das Produkt relativ einfach anzupassen bzw. zu erweitern. Allerdings kann Cloud-Software hochgradig konfiguriert und dadurch auf Kundenanforderungen angepasst werden. In der Konsequenz bedeutet das, dass Unternehmen sich frühzeitig mit den Konfigurationsoptionen und –limits auseinandersetzen müssen. Darüber hinaus muss bei der Entscheidung für eine Cloud-Software klar sein, dass das Ziel der Implementierung nicht notwendigerweise nur eine Abbildung der bestehenden Prozesse im System darstellt. Es muss auch um ein kritisches Hinterfragen und eine sinnvolle Anpassung der bestehenden Prozesse an das System gehen.
Mein Tipp: Sehen Sie die Implementierung einer Cloud-Software in mehrfacher Hinsicht als Chance: hinterfragen Sie „alte“ Prozesse, nutzen sie die Möglichkeit „best practice“ oder mehrfach erfolgreich implementierte Konfigurationen zu übernehmen und stellen Sie Nachhaltigkeit sicher, indem ihre Cloud-Software zu jedem Zeitpunkt vollständig aktualisierbar bleibt.
Herausforderung #3: Folge der Roadmap
Unternehmen erhalten bei Software-as-a-Service mehr als ein fertiges Produkt, das Sie erst in einigen Jahren updaten werden – sie „kaufen“ auch zu einem gewissen Grad die „Produkt-Roadmap“ des Herstellers. Oder, meiner Meinung nach, sollten Sie das zumindest bei der Kaufentscheidung berücksichtigen. Gewisse Hersteller, wie z.B. SAP erstellen Ihre Roadmaps nicht nur auf Basis von Inputs der internen Produktmanager, sondern lassen vielfach auch Kundenrückmeldungen in die Produktweiterentwicklung miteinfließen. Je größer der Kundenkreis, desto mehr „Feedback aus der Praxis“ gibt es und je wahrscheinlicher bringen die regelmäßigen Upgrades wertvolle, neue Funktionen für Kunden. Und das “laufend”, im Fall von SAP viermal pro Jahr (ohne Releasewechsel-Projekt).
Mein T ipp:
Priorisieren Sie Ihre Anforderungen und vergleichen Sie diese mit den aktuell verfügbaren Produktfunktionalitäten und Konfigurationsmöglichkeiten. Verzögern Sie Ihren Go-Live Termin nicht bis alle Anforderungen abgedeckt sind, sondern „überprüfen“ Sie die Roadmap bzw. lassen Sie sich von ihrem Implementierungspartner regelmäßig über neue Funktionalitäten informieren und setzen diese bei Bedarf ein (opt-in).
Warum dieser Ansatz empfehlenswert ist
Diese Vorgehensweise bietet folgende Vorteile gegenüber herkömmlichen Implementierungsansätzen:
- Kurze Time-to-Value (siehe auch Herausforderung #1)
- Möglichkeit, System-Feedback von Endanwendern zu bekommen und deren Wünsche zu berücksichtigen
- Verteilung des Implementierungsbudgets auf die gesamte Mietdauer
- Sicherstellung „regelmäßiger“ Betreuung durch den Implementierungspartner