Die Einführung von SAP SuccessFactors, der SAP-Cloudlösung für HR, unterscheidet sich erheblich von klassischen SAP ERP HCM Projekten: Ist man aus der „alten Welt“ gewohnt, Prozesse und Funktionen anpassen und der Software „unter die Motorhaube" schauen zu können, muss in der Datenwolke eine stärkere Orientierung an Best-Practices erfolgen. Dies erfordert ein Umdenken - sowohl auf Seiten des Implementierungspartners als auch beim eigentlichen SAP Anwenderunternehmen bzw. Kunden.
Das Interview zum Nachlesen
Lessons Learned SAP SucessFactors Einführungsprojekte
Michael Scheffler:
Mit SAP SuccessFactors setzt der führende Softwarehersteller aus Walldorf im Bereich Human Capital Management, kurz HCM, seit der Übernahme im Jahr 2011 auf eine umfassende Lösung aus der Cloud. Für Unternehmen die bereits Investitionen in das on-premise bassierte SAP ERP HCM getätigt haben, stellt sich damit die Frage ob, und wie genau Sie den Weg in die Datenwolke bestmöglich gestalten. projekt0708 implementiert seit mehr als 6 Jahren SAP SuccessFactors bei Bestands- und Neukunden. Über die Herausforderung und Lessons Learned bei solchen Projekten möchte ich heute mit meinem Kollegen Jörg Ehrlich, Director HR Solutions sprechen. Jörg beschäftigt sich seit Anfang an intensiv mit dem Thema SAP SuccessFactors und leitet den Bereich HR Solutions, welche sich primär mit den Einführungen und Weiterentwicklungen von personalwirtschaftlichen Lösungen beschäftigt. Damit herzlich Willkommen zu einer neuen Folge von HR IT Talk mein Name ist Michael Scheffler ich bin Geschäftsführer der projekt0708 GmbH und seit über 20 Jahren im SAP Umfeld tätig.
Jörg wir kennen uns seit fast zehn Jahren auch schon vor deiner Zeit hier bei projekt0708 damals warst du noch im HR-Bereich in einer europäischen Großbank beschäftigt kannst du unseren Hörern bitte erläutern,wie du zu uns und dem Thema SAP SuccessFactors gekommen bist und was dich in deiner Rolle als Director HR Consulting hierbei projekt0708 beschäftigt.
Jörg Ehrlich:
Klar sehr gerne, freue mich heute dabei zu sein. Zu meinem Hintergrund, wenn wir ein bisschen in die Vergangenheit gehen, habe ich nach dem Abi und dem Zivildienst angefangen zu studieren und zwar international Business. Das war einer der ersten Studiengänge auf Bachelor in Dresden, da ich dachte Sprachen kann ich ganz gut und Wirtschaft, das passt ganz gut zusammen, habe mich dort irgendwie reingemogelt weil das ein Studiengang mit Voraussetzung französisch war und nicht zu dem Zeitpunkt kein Französisch konnte. Hab mir das Wissen reingepfiffen, den Test dann auch bestanden. Was ich allerdings nicht auf dem Schirm hatte war, dass die Probleme dann erst losgingen, weil ich ja dann Vorlesung auf Französisch hatte und dann nicht richtig mitgekommen bin. Letztendlich habe ich mich irgendwie durchgemogelt und es war tatsächlich ein guter Studiengang mit Auslandsaufenthalt.
Zum einen in Edinburgh in Schottland, wo ich ein Semester studiert habe und dann wollte ich eigentlich dort auch mein Praktikum machen, das hat nicht ganz so funktioniert, deswegen bin ich von Edinburgh nach Mailand geflogen um ein Praktikum zu machen, bei der schon von dir angesprochenen europäischen Großbank, und das war so das erste Mal wo ich Kontakt hatte mit dem Thema SAP. Das war eine, Fusion zweier Banken es ging darum, zu schauen wie man den HR-Bereich neu organisieren kann, es ging ebenso darum ein neues HR Delivery Modell einzuführen, die sich ein bisschen damit auseinandersetzen kennen sicherlich das Dave Ulrich Modell, Einführung von Shared Service Center, Business Partner Modell, Center of Expertise und eben auch Digitalisierung. Um einen ersten Anlaufpunkt für Mitarbeiter zu bieten, wo kann ich mich über HR Fragen informieren, Self-Services etc. In diesem Workstream habe ich mitgearbeitet, erst im Rahmen des Praktikums hier in München und dann im Rahmen eines Traineeprogramms, was ich angefangen habe wo es im Wesentlichen um Prozesse und Projektmanagement ging. Ich komme also ursprünglich aus dem Fachbereich aber hatte immer eine gewisse IT Affinität, deswegen bin ich dann auch übergelaufen vom Fachbereich zur IT in dieser Bank und habe dort verschiedene Rollen begleitet.
Das Ganze war noch im klassischen On-Premise Geschäft sprich, Server steht im im Keller und wir führen Standard Lösungen ein oder manchmal auch mit eigenen Entwicklungen und das Ganze im globalen Kontext. Habe mich dann als inhouse Berater mit dem Thema beschäftigt, als Solution Architect, als Projektleiter. Und aus dieser Seite kennen wir uns auch, du warst damals freiberuflich dort tätig. So kam eins zum anderen und mittlerweile bin ich seit sechs Jahre schon bei projekt0708, eine lange Zeit, knapp sechs Jahre und beschäftige mich seit Anfang an mit dem Thema SuccessFactors. Natürlich auch bekleidet mit vielen On-Premise Implementierungen, die ich begleitet habe aber in den letzten zwei Jahren fast ausschließlich mit dem Thema SuccessFactors.
Unterschiede zwischen On-Premise und Cloud-Umgebung in SAP HCM und SuccessFactors
Michael Scheffler:
Somit konntest du also in deiner beruflichen Laufbahn Erfahrungen in beiden Systemwelten sammeln und aufbauen, hast dich ursprünglich sehr viel im On-Premise Umfeld, sprich in der klassischen SAP HCM Umgebung bewegt, damals als Inhouse Consultant, erst Personalwesen dann IT, und mittlerweile beschäftigt du dich sehr stark mit der Cloud und SAP SuccessFactors. Was ist für dich als Berater der größte Unterschied zwischen diesen beiden Welten, das würde mich nur interessieren.
Jörg Ehrlich:
Gute Frage, also es gibt auf jeden Fall große Unterschiede. Bei klassischen Einführungsprojekt z.B. einer SAP Learning Solution, das ist im On-Premise die Lösung, um Aus- und Weiterbildung zu organisieren, Trainingsmanagement etc. Bei einem On-Premise Projekt also einem klassischen Projekt geht es immer darum, dass wir ersteinmal ein FachKonzept schreiben, wir investieren Zeit zusammen mit dem Kunden. Auf der grünen Wiese schauen wir was braucht bzw. möchte denn der Kunde, wie laufen die Prozesse und dokumentieren das, auch wie die systemisch unterstützt werden sollen und lassen uns primär von den Kundenanforderungen leiten. Im Anschluss stellt man das der Standardlösung gegenüber und entweder gibt es Punkte, die passen eins zu eins oder es gibt eben Lücken, auch Fit Gap Analyse genannt, und schaut dann wie man die Lücken schließen kann. Entweder mittels Customizing, mittels Programmierung, es gibt ja unterschiedliche Möglichkeiten, oder über eine Eigenentwicklung, Daraufhin schreibt man dann z.B. ein technisches Konzept dadurch sind dann bereits ein paar Monate ins Land gegangen und dann fängt man erst einmal mit der Realisierung an. Des Weiteren sieht man dann, im Rahmen einer Testphase, als Kunde und Fachbereich, die ersten Umsetzungen und kann die Lösung dann mal anfassen bzw. erfahren und das Ganze spüren. Das ist auch der größte Unterschied zu Cloud Projekten, weil der Kunde viel schneller etwas am System sehen kann und das ist positiv.
Der Ansatz sich von den Kundenanforderung leiten zu lassen funktioniert allerdings nicht so, weil die Lösung, das ist dann eine Cloudlösung, die in gewissem Maß angepasst werden kann aber eben nur einem gewissen Maß. Das heißt, die Lösung gibt einen gewissen Rahmen vor und wenn man innerhalb dieser Rahmen per Konfiguration die Kundenanforderungen, nicht abdecken kann, funktioniert das erstmal nicht, das heißt man kann sich zwar am Anfang über die Kundenanforderungen Gedanken machen, dies hat sich aber nicht als sehr sinnvoll erwiesen. Daher ist es eigentlich besser, wenn man die Lösung als erstes betrachtet und dann schaut, wie man den Kundenprozess damit abbilden kann. Vielleicht muss man ein Stück weit von dem Prozess abweichen, man lässt sich also viel stärker von der Lösung leiten, also Process follow System und nicht andersrum.
Das ist einer der größten Unterschiede, was auch manchmal in der Diskussion dazu führt, dass man sagen muss, dass die Anforderung so nicht möglich ist, weil man es so nicht abbilden kann. Das hatte man zwar im On-Premise auch aber dann ist man ganz schnell in der Diskussion, dass das mit dem Standort nicht abbildbar ist aber wir hier eine Eigenentwicklung machen können, wir können eine Erweiterung schaffen, Modifizieren, auch wenn nicht gern gesehen, hat man immer die technischen Möglichkeiten gehabt irgendetwas zu tun. Bei der Einführung von Standard-Software wie SAP SuccessFactors muss man eben sagen, dass es so nicht abbildbar und dann kommt erst einmal ein Punkt und kein aber, weil die Anforderung zunächst eins-zu-eins nicht geht. Hier fängt man dann an in die Diskussion einzusteigen, Warum ist denn das überhaupt eine Anforderung? Ist es eine gesetzliche Anforderung? Kann man nicht den Prozess irgendwie anpassen oder kann man nicht irgendwie ein Workaround finden? Das ist das Spannende daran, man beschäftigt sich eigentlich viel mehr, mit mit der Lösung, weil man eben die Möglichkeit nicht hat zu sagen aber wir können irgendetwas entwickeln, was ja nicht immer sinnvoll ist und einem auch in On-Premise Projekten auf die Füße fallen kann.
Man entwickelt etwas dazu, modifiziert etwas, im Endeffekt ist es weit weg vom Standard und man macht in zwei oder drei Jahren ein Projekt für ein Redesign um das wieder in den Standard zurückzubringen. Man muss sich ein bisschen auf die Lösung einlassen, auf die Best Practices, die die Software mitbringt und das ist eigentlich der größte Unterschied.
Michael Scheffler:
Okay wir können also schon mal festhalten SF Projekte laufen anders.
Jörg Ehrlich:
Auf jeden Fall.
Projektvorgehensweisen
Michael Scheffler:
Gibt es hier spezielle Vorgehensmodelle? Wie genau gehen wir denn bei projekt0708 Projekte an?
Jörg Ehrlich:
Die Projektvorgehensweise unterscheidet sich, wir als projekt0708. Orientieren uns natürlich, als Partner der SAP, an der Methodik die die SAP empfiehlt - das ist die sogenannte activate Projektmethodik. Das ist eine agile Vorgehensweise also kein klassisches Wasserfallmodell mit den Phasen die ich ja bereits skizziert habe sondern wesentlich agiler. Soweit kein Hexenwerk oder eine komplett neue Auffindung sondern ein Stück was es am Markt an Projektmethodik gibt, einfach ein bisschen, zugeschnitten auf SAP SuccessFactors.
Im Wesentlichen gibt es dort vier Phasen in der activate Methode. Das ist die prepare Phase, also alles was mit dem Thema Projektvorbereitung zu tun hat, die Explore Phase, Design und Konzeption, die Realize Phase, wenn es dann direkt an die Umsetzung geht und die Deploy Phase, wenn man das Ganze dann auch live setzt. Auf die vier Phasen würde ich ganz kurz mal eingehen, in der Prepare Phase, wie in anderen Projektvorgehensweisen auch macht man einen Kick off, klärt strategische Fragen, Projektziele, operative fragen, also wie wollen wir zusammenarbeiten, aber wir beschäftigen uns auch ganz früh, das unterscheidet sich gleich ein bisschen, mit den Systemen. Idealerweise stehen die Systeme, wenn wir ein Implementierungsprojekt machen bereits zur Verfügung, das heißt wie kommen wir auf die Systeme, wie betten sich die Systeme in die Infrastruktur ein.
Die meisten, führen nicht die komplette Suite ein sondern erst einmal ein Modul, haben vielleicht schon gewisse Module im SAP On-Premise Bereich, das heißt er stellen sich Fragen der Integration. Das Alles beleuchten wir ganz grob mal im ersten Schritt und schulen das Kernprojektteam sehr früh, weil wir uns sehr stark mit der Lösung beschäftigen und auch mit der Standort Lösung, daher empfiehlt sich ganz am Anfang eine Schulung für das Kernprojektteam. Dann starten wir quasi in die Design Konzeptionsphase, also den Explore und machen zunächst einen Konzeptionsworkshop. In der Regel 3 bis 5 Workshops, wenn wir jetzt mal von einem Modul ausgehen z.B. SuccessFactors Recruiting also das Bewerbermanagement. In den Workshops gehen wir tatsächlich dann sehr tief in die Materie, erklären Zusammenhänge, Prozesse, gleichen die Lösungen mit den Anforderungen ab also Definition, Felder, Feldinhalt, um dort Systementscheidungen zu diskutieren oder zu erwirken und die dann zu dokumentieren.
Das Ganze setzen wir dann in der Realize Phase um, die Phasen können durchaus überlappen. In dieser Umsetzungs- und Realisierungsphase arbeiten wir iterativ, das ist auch die Phase wo wir am iterativsten arbeiten, das heißt wir schnüren Arbeitspakete und setzen die sehr frühzeitig nachdem der Workshop erfolgt ist am System um. Dieses frühzeitige Umsetzen hilft auch, falls nicht so viel Zeit zwischen der Konzeption und der Realisierung vergeht, dass man sich auch noch daran erinnert was man genau besprochen hat. Meistens ist es in Diskussionen so, dass man zunächst einen Weg geht, den verwirft man wieder, schlägt einen anderen Weg ein, dokumentiert dies zwar aber wenn man dann in der Lösung das nicht frühzeitig sieht dann, braucht man erst einmal wieder um reinzukommen. Deswegen schnüren wir Arbeitspakete, die in sich abgeschlossen sind, die man auch testen kann, und zeigen die dem Kunden. Der Kunde kann es mal anfassen, hat selbst schon im System Zugriff und so gehen wir für die einzelnen Arbeitspakete vor.
In der Regel arbeiten wir mit 2-3 Iterationen, das heißt mit den Iterationsschleifen wird die Lösung erarbeitet. Am Anfang hat das Ganze ein Fertigstellungsgrad oder ein, Deckungsgrad von 70-80% und über die zwei bis drei Iterationen schleifen wir das rund bis zu den, ich sag jetzt bewusst nicht 100%, 95 bis 99% weil, siehe auch Lessons Learned darauf komme ich später noch einmal zurück, denn den 100-prozentigen Fit bei der Standardlösung und da kann man sich jede Lösung anschauen, es einfach nicht geben wird. Das ist die Realisierungsphase, dann kommem wir zur deployment Phase, alles was mit dem Thema technische Produktivsetzung zu tun hat, mit der Schulung der End User und dann den tatsächlichen in GoLive. Wir als Firma bieten ebenso einen Support an, also ein Post GoLive und auch gerne regelmäßigen Support im Rahmen unseres HR Support Modells. Das nennt sich dann Deploy Phase. Keine wesentlichen Neuerungen aber wesentlich agiler als vor 3-5 Jahren im Rahmen von klassischen On-Premise Projekten.
Überblick über SAP SuccessFactors: Prozesse, Stärken und Integrationsoptionen
Michael Scheffler:
Ich kann mir gut vorstellen, dass dies in der Praxis gut ankommt, denn die Zeiten wo man sich ein halbes Jahr im stillen Kämmerchen eingesperrt hat und vor sich hin programmiert hat, sind definitiv vorbei. Also absolut nachvollziehbar für mich - vielen Dank. Jetzt haben wir ja schon sehr viel über SAP SuccessFactors gesprochen, ich kann mir vorstellen dass einige unserer Hörer noch nicht so ein tiefen Einblick haben, kannst du uns daher mal ein bisschen was zu der Software selber sagen. Welche Prozesse werden abgedeckt? Wo liegen die Stärken der Software?
Jörg Ehrlich:
Einfach mal ein big picture, kannst du uns das bitte geben. Gerne, also grob zusammegefasst ist es, eine Lösung, die die SAP damals zugekauft hat, SuccessFactors und weiter investiert hat und integriert hat. Zudem ist es eine Lösung, eine HR Suite, zur Abbildung aller personalwirtschaftlichen Prozesse. Wobei man dazu sagen muss, dass SuccessFactors ursprünglich aus dem Talentmanagementbereich kam, was bedeutet, zu dem Zeitpunkt der Übernahme gab es ja noch keine HR Core Prozesse soweit ich weiß, wie Abrechnungen etc. Genau die SAP hat dort in den letzten,10 Jahren massiv investiert und das was gefehlt hat nachgezogen. Das merkt man natürlich auch über die Jahre wie die Lösung immer weiter reift. Wenn wir die Prozesse und Module mal durchgehen, angefangen mit Recruiting und Onboarding, wo wir sehr viele Projekte machen.
Wenn ich jetzt einen Mitarbeiter gefunden habe, der Bewerber entscheidet sich für uns, der ganze Onboarding Prozess, diesen zu digitalisieren, über die Stammdatenverwaltung, das Pendant zu Personaladministration, zum Organisationsmanagement, zur Abrechnung und zurzeit Zeitwirtschaft, nennt sich gebündelt in einem Modul Employee Central. Das inkludiert das ganze Thema Selfservices, z.B. Mitarbeiter Self Services, Führungskräfte Self Services, Manager Self Services in einem Modul, sprich Employee Central. Das ganze Thema Abbildung von Instrumenten der Personalentwicklung, sozusagen Abbildung von Mitarbeitergesprächen, Entwicklungspläne also das was vor der Übernahme im Bereich Talent Management schon da war. Das sind die Module Performance, Goals, Succession und Development, über das ganze Thema, mit dem ich mich auch sehr intensiv beschäftige, Aus- und Weiterbildung also SuccessFactors Learning, sowohl klassische Trainingsformen als auch neuere Trainingsformen, wie E-Learning, Online Tests, hybride Trainingsformen, bis hin zum Offboarding, also wenn der Mitarbeiter dann das Unternehmen wieder verlässt, um dort im Wesentlichen administrative Prozesse abzubilden.
Das ganze wird noch flankiert von Modulen wie Kollaboration, hier gibt es ein Modul das nennt sich SAP Jam, wo es um den um die Kollaboration untereinander geht. Dies ist stark in die Module integriert, und natürlichen Reportinglösungen wo ich auch alle diese Module auswerten kann. Du hast nach nach Stärken oder Schwächen gefragt, das ist natürlich schwierig jetzt hier eine individuelle Betrachtung vorzunehmen, das alles zu beleuchten würde einfach zu zu weit führen. Was im Allgemeinen aus meiner Sicht eine sehr große Stärke ist, ist die Innovationsgeschwindigkeit. Die SAP bietet ja im Rahmen des Vertrages viermal im Jahr Releases an, die sogenannten quarterly Releases, mit neuen Funktionalitäten, Erweiterungen etc. Das ist schon sehr stark und man muss immer am Ball bleiben, um sich mit den neuen Funktionalitäten zu beschäftigen - also große Stärke Innovationsgeschwindigkeit.
Eine weitere große Stärke sind die offenen Schnittstellen, was gerade für uns als Partner die Möglichkeit bietet, kundeneigene Integrationen zu realisieren, oder Erweiterungen, indem wir diese Schnittstellen ansprechen können, nicht nur um Daten aus SucceddFactors herauszuziehen sondern auch Daten hineinzubringen mit einer eigenen Anwendung wie z.B. viele Partner Apps und Entwicklungen aus Projektlösungen. Aus einer Sicht eine große Stärke, weil es neben der Standardlösung Individualisierungen ermöglicht.
Herausforderungen bei der Einführung von SAP SuccessFactors: Loslassen, Changemanagement und Experimentierfreude
Michael Scheffler:
Wir haben ja bereits darüber gesprochen, das Einführungsprojekte von SAP SuccessFactors anders ablaufen. Wo unterscheiden sich die Projekten noch? Wo siehst du denn die größten Herausforderungen für unsere Kunden?
Jörg Ehrlich:
Eine der größten Herausforderung ist, das hatte ich vorhin schon kurz angesprochen, das nicht alle Anforderungen in SuccessFactors abgebildet werden können. Das klingt erst einmal für den Kunden im Workshop ein bisschen abschreckend aber hier muss man sich eben ein Stück weit von der Lösung leiten lassen bzw. auf die Lösung einlassen und nicht einfach auf bestehende Prozesse beharren um diese eins zu eins zu digitalisieren. Ich bringe nun nicht diesen Spruch mit dem Prozess und der Digitalisierung an, um nicht die Copyrecht zu verletzen aber jeder kennt dieses Zitat, das macht einfach keinen Sinn. Ein System auf biegen und brechen auf den bestehenden Prozess anzupassen fällt einem irgendwann auf die Füße. Das heißt, manchmal muss man einfach loslassen können, also Changemanagement ist immer ein, Schlüsselfaktor aber hier ganz besonders, ein sozusagener SuccessFactor und man muss einfach auch mal etwas ausprobieren.
Herausforderungen bei SAP SuccessFactors-Projekten: Systemanpassungen, Dokumentationsabhängigkeit und Innovationsgeschwindigkeit
Michael Scheffler:
Also alte Zöpfe abschneiden ist ganz wichtig in dieser Art von Projekten?
Jörg Ehrlich:
Absolut. Nun weitere Herausforderungen aus meiner Sicht oder auch welche. Lessons haben wir gelernt. Systemeinstellungen können recht schnell angepasst werden, was dann auch dazu führt, dass wir so agil arbeiten können und dass der Kunde schnell etwas erfahren kann. Man tendiert jedoch schnell mal den Knopf nach rechts zudrehen oder nach links zu drehen dann wieder nach rechts aber diese Schalter haben große Auswirkungen. Es können damit Folgeprozesse betroffen sein, gerade wenn ich das ganze in einem globalen Kontext das implementiere oder mehrere Module gleichzeitig. Es gibt hier Abhängigkeiten, wenn man das nicht sauber dokumentiert und einfach ein darauf los arbeitet, geht das meist schief. Es braucht hier trotzdem ein gewisses Vorgehen auch wenn es jetzt nicht aufwändig ist, meist ist die Dokumentation der Systemeinstellung aufwändiger als diese dann tatsächlich durchzuführen aber dennoch entscheidend damit man nicht den Überblick verliert.
Michael Scheffler:
Sozusagen ein wichtiges Erfolgskriterium?
Jörg Ehrlich:
Absolut. Eine Herausforderung ist, dass das Coding leider nicht öffentlich ist und wir nicht einsehen können, was da sozusagen unter der Haube passiert. In klassischen On-Premise Projekten auch wenn man Standardlösungen einführt, hat man einen Prozess, welcher nicht das erhoffte Ergebnis geliefert hat, durchgespielt, und hat dann geschaut warum das so ist. Man konnte hier immer schön debuggen und das Coding einsehen und somit festellen, hier haben wir etwas falsch gemacht oder hier ist ein Fehler im Coding. Das führte meist auch dazu, dass wenn man eine Meldung bei der SAP aufgemacht hat, meist schon einen Screenshot vom Coding mitgeliefert hat, weil man wusste dann bearbeitet die SAP das ein Stück schneller und dann auch gleich entsprechende Infos zur Anpassung geliefert wurden. Es gab hundertprozentige Transparenz, man konnte die Systemlogik einsehen, das ist in SuccessFactors leider nicht so.
Wir sehen nur was an der Oberfläche passiert, das heißt wir müssen uns auf die Dokumentationen verlassen, die sehr gut und sehr umfangreich sind aber Dokumentationen können veralten, sie können nicht korrekt sein, sie können nicht ausführlich genug sein. Wir müssen uns also auf unsere Testergebnisse verlassen, das heißt man muss trotzdem sehr viel testen um das System zu verstehen, Konstellationen nachstellen und man muss natürlich auch sehr eng mit dem SAP Support zusammenarbeiten. Früher beim klassischen Projekt hat man nur im Notfall ein Ticket aufgemacht, hier ist die Zusammenarbeit Teil des Modells. Das heißt, die Zusammenarbeit mit der SAP erfolgt darüber, dass ich ein Ticket bei der SAP mit unterschiedlicher Priorität, aufmache. Wenn man z.B. ein großes Projekt live gesetzt hat, kann das im SAP Support Portal schon einmal dazu führen dass man, für ein sehr großes Projekt an die 70 bis 80 Meldungen über zwei Jahre aufmacht. Das bedeutet nicht, dass die Lösung schlecht ist und dass das alles Bugs sind sondern dass man bei gewissen Sachen einfach auf den SAP Support angewiesen, entweder bei einer Frage oder und weil man auch nicht alles selber machen kann.
Die enge Zusammenarbeit mit der mit der SAP ist auch eine. Herausforderung und unterscheidet sich zu den klassischen Projekten, die wir sonst im On-Premise Umfeld machen,darüberhinaus ist die Innovationsgeschwindigkeit eine weiterere Herausforderung. Zum einen eine Stärke aber natürlich auch eine Herausforderung, weil ich immer am Ball bleiben muss. Wenn ich ein Projekt habe, für einen größeren Kunden über z.B. eine Laufzeit von einem Jahr, passieren alleine in diesem Zeitraum 4 neue Releases.
Es kann also sein, dass ich am Anfang etwas bespreche wo es noch keine Lösung dazu gab und am Ende des Projektes gibt es die aber und man muss diese aber erst einmal bewerten. Sprich, trifft der ausgelieferte Release unsere Anforderungen? Können wir damit schon arbeiten? Man muss die Entscheidung treffen, ob man mit der Implementierung noch wartet oder das in einem Folgeschritt macht, oder ob wir so live gehen. Somit ist die Innovationsgeschwindigkeit auch eine Herausforderung, sich damit zu beschäftigen und zu evaluieren was das für das Projekt bedeutet.
Aufwand in SuccessFactors-Projekten: Fachberatung, iterative Entwicklung und Integration
Michael Scheffler:
Kommen wir mal zum Aufwand solcher Projekte, da gibt es ja manch einen der spottet in Cloudlösungen muss man nur ein paar Knöpfe drücken, da man ja nichts entwickeln kann, und schon läuft das Ganze. Dementsprechend müsste SuccessFactors ja innerhalb von ein paar Tagen implementiert sein oder wie ist denn das?
Jörg Ehrlich:
Ja den Spruch mit den paar Knöpfen kenne ich auch, tatsächlich ist die Spanne der Implementierungsaufwände recht groß. Man kann ein Modul zum Beispiel SuccessFactors Recruiting in 25 Tagen einführen, wir reden jetzt von externen Aufwänden, dem gegenüber stehen natürlich auch interne Aufwände beim Kunden sog. Mitwirkungsleistungen. Man kann aber so ein Projekt, also ein einzelnes Modul z.B. SuccesFactors Recruiting in 500 externen Mann Tagen implementieren. Das hängt natürlich wie bei allen Projekten damit zusammen wie groß der Kunde ist, was im Skope ist, wieviele Länder im Scope sind, wie groß ich das Aufziehen möchte, möchte ich schon am Anfang ganz viele Leute involvieren um schon über die Prozesse zu sprechen etc. Das ist immer ein von bis aber tatsächlich war ich am Anfang auch überrascht dass Cloud Projekte nicht, zwingend kleiner oder oder preiswerter sind, sondern sich nur die Aufwände verschieben.
Michael Scheffler:
Zugegeben meine Frage war ein bisschen provokant aber wenn SuccessFactors Projekte vom Umfang nicht wesentlich kleiner sind, wo unterscheidet sich dann der Aufwand?
Jörg Ehrlich:
Grundsätzlich kann man sagen er geht von der Entwicklung eher in die Fachberatung, zum Einen durch den, iterativen Ansatz den man fährt, das ist ein Vorteil, weil man sehr früh etwas sieht aber durch die 2 bis 3 Iteration fasst man natürlich auch alles mehrfach an. Demnach drehe ich einen Knopf nach rechts, der Kunde schaut sich das an, testet das und merkt aber dass er eher nach links drehen muss. Genauso wieder durch jemand anderen der im Projekt involviert ist, der doch lieber nach rechts drehen möchte. Durch diesen iterativen Ansatz fasst man zwar alles mehrfach an aber man sieht sehr viel und konfiguriert nicht an der wirklichen Welt vorbei. Das führt natürlich zu einem Mehraufwand und ist somit ein Aufwandstreiber, zumindest meiner Erfahrung in den letzten Projekten nach.
Zudem ist man mit Successfactors Projekten oftmals Pionier in Sachen Cloud, es gilt den Datenschutz abzuholen, die IT Security abzuholen, was vielleicht tatsächlich garnichts mit der Implementierung der Lösung zu tun hat aber man ist Vorreiter. SuccessFactors liefert zum Beispiel eine App aus, um die App zum Laufen zu bringen, das kann man in ein zwei Stunden machen, aber mit dem zu erfahrendem im Unternehmen, ob es z.B. schon eine mobil Strategie gibt, kann man das auf privaten Endgeräten laufen lassen oder müssen wir irgendetwas dazwischen schalten?
Diese ganzen Themen mit unterschiedlichen Ansprechpartnern führen natürlich auch zu einem Aufwand, man könnte es schnell implementieren aber dadurch, dass mein hier Vorreiter ist, muss man dort mehr in Beratung und Abstimmung investieren. Die Lösung hat sich natürlich in den letzten Jahre extrem entwickelt, Funktionen sind dazu gekommen, was somit auch zwangsläufig bedeutet, dass Systemkonfiguration komplexer werden. Daher ist es ein Irrglaube zu meinen, dass wir hier eine Software haben, die alles und immer mehr kann, und das zum gleichen Komplexitätsgrad. Das geht natürlich nicht, denn mit steigender Funktionalität und mit steigenden. Funktionen, wird das ganze komplexer und das wirkt sich auch auf die Aufwände und auf die Systemkonfiguration aus. Zudem ist es meist so, dass Kunden ja nicht die komplette Suite einführen und alles aus einer Hand haben, sondern wir setzen ja meist darauf auf, dass Stammdaten z.B. noch im On-Premise System in der Personaladministration verwaltet werden, ein sogenanntes hybrides Bereitstellungsmodell und dafür braucht es eine Integration.
Hier gibt es Standard Integration seitens der SAP, die man nutzen kann, die sind auch gut aber das macht es natürlich nicht leichter, da wir eine gewisse Integration haben , die man implementieren, und mir dem Kunden besprechen muss und schließlich, ist die Aussage man kann nicht entwickeln nicht ganz richtig, da man entwickeln kann nur das Coding selber nicht verändern. Man kann Apps bauen, die, mehr oder weniger daneben stehen, ich kann sie aus SuccessFactors heraus aufrufen, ich kann damit Lücken schließen, was wir auch erfolgreich machen. Wie das bei Eigenentwicklungen immer ist, ist das Ganze sehr aufwendig, da man es konzipieren, muss es umsetzen, muss es testen genau wie im On-Premise Bereich und natürlich dann auch bewerten hinsichtlich Kosten Nutzen d.h. möchte ich das investieren oder nicht.
Michael Scheffler:
In Anbetracht der Zeit würde ich dich bitten, anlässlich der Titel Episode, deine Lessons Learned in SuccessFactors noch einmal auf den Punkt zu bringen, und mit 23 Stichpunkten zusammenzufassen. Was möchtest du unseren Hörern mitgeben?
Jörg Ehrlich:
Gerne, also für mich die wichtigsten 4 Lessons Learned sind zum Einen, man lernt nie aus. Es kommen immer neue Lessons Learned dazu, nicht nur weil jedes Projekt und jeder Kunde anders ist, die Anforderungen ja doch immer ein bisschen abweichen, sondern weil immer neue Funktionalitäten aufgrund der Innovationsgeschwindigkeit hinzukommen. Gerade das Thema Erweiterung Integration ist extrem spannend und deswegen gibt es da immer wieder neue Konstellationen, und man lernt nie aus, was auch dementsprechend Spaß macht, weil es natürlich nicht langweilig wird.
2. Lessons Learned, das habe ich schon paar mal angesprochen, ist dass man sich von der Lösung leiten lassen muss. Einfach schauen muss, was die Lösung kann und ob das entsprechend passt und dann kann man immer noch in die Diskussion einsteigen aber man muss sich von der Lösung leiten lassen, also Process follows System statt andersherum. Ebenso ist iteratives Vorgehen ein Vorteil aber man darf hierbei die Dokumentation nicht vergessen, sprich Dokumentation ist ein Mast.
Ebenso eine Lessons Learned, was wir zum Teil schmerzlich lernen mussten, dass nicht jeder workaround sinnvoll ist. Man kann workarounds finden, kann bestehende Funktionaliät anders verwenden als sie eigentlich gedacht ist, muss es aber schon sauber durchdenken und von vorne bis hinten durchspielen, dass das System wenn man es verbiegt, genau wie im On-Premise Bereich auch, einem nicht über kurz oder lang. auf die Füße fällt. Am besten immer schön am Standard orientieren und keine Tracking Lösungen.
Michael Scheffler:
Super vielen vielen Dank für diese sehr spannenden Einblicke, man merkt du bist extrem tief in der Lösung drinnen und hast dich auch viel damit auseinandergesetzt. Ich hoffe die heutige Folge bringt unseren Hörern etwas.
Hat ihnen dieser Podcast gefallen, dann freuen wir uns sehr über fünf Sterne bei iTunes. Feedback zu dieser Folge oder Themenvorschläge für künftige Episoden gerne per Mail an podcast@projekt0708.com.
