SAP IDM End of Life: Die IGA-Migration souverän meistern

Herzlich Willkommen zu unserem heutigen Webinar SAP IDM End of Life, die IGA Migration Souverän meistern. Mein Name ist Dr. Philipp Messerschmidt und mit mir heute im Webinar sind Klaus Hild und Christian Hoppe. Hallo Klaus, hallo Christian. Hallo Philipp, schön, dass wir teilnehmen dürfen. Mein Name ist Klaus Hild. Ich bin als Principal Identity Strategist bei Sailpoint unterwegs. Dem kann ich mich noch anschließen. Hallo zusammen, Christian Hoppe von IBM. Ich verantworte hier in Deutschland, Österreich und der Schweiz das Identity Nexus Management Geschäft.

Super, dann legen wir los, schauen auf die Agenda. Wir haben heute auf der Agenda vier Punkte und zwar werde ich gleich anfangen mit dem Housekeeping, dann anschließend inhaltlich darüber sprechen, was die Strategic Consideration für die Replacing von SAP IDM sind. Anschließend werden Klaus und Christian ihren Vortrag halten über IBM, Sailpond und SAP. Und abschließend werden wir noch eine Q&A Session haben. Auf geht's zum Housekeeping.

Erstens, Audio Controls. Wir haben alle Teilnehmer zentral gemutet und wir kontrollieren das Feature auch. Das heißt, es gibt keinen Grund, sich selbst zu muten oder zu unmuten. Dann haben wir noch die Umfragen. Wir haben einige Umfragen im Webinar. Das heißt, wir schalten diese Umfragen und werden uns die Ergebnisse nachher in der Q&A Session anhören. Dann die Q&A Session. Wir haben zum Ende des Webinars eine Q&A Session. Sie können also jederzeit Ihre Fragen im Webinar-Tool hinterlegen. Und dann das letzte Recording der Slides.

Wir werden das Webinar recorden und das Recording dann im Endeffekt in den kommenden Tagen auf unserer Website hochladen. Gut, dann steigen wir auch ein in den ersten inhaltlichen Punkt, den Vortrag von mir zum Thema Strategic Considerations for Replacing SAP IDM. Wir starten hier mit einer Umfrage. Ich würde nämlich zu Beginn ganz gerne wissen, ob Sie SAP IDM aktuell benutzen und wenn ja, ob Sie es als primäre Lösung benutzen oder als sekundäre Lösung. Oder ob Sie dann dritte Option hier SAP IDM gar nicht benutzen. Im Hintergrund wird die Umfrage live geschaltet.

In der Zwischenzeit setze ich meine Folien dann auch schon mal fort. Zunächst schauen wir uns einmal die Fakten an. Was wissen wir aktuell? SAP IDM End of Life beziehungsweise Ende der Wartung angekündigt für 2027. Der Extended Support läuft bis 2030. Soweit wir wissen, gibt es aktuell keinen Successor für das Produkt SAP IDM und die Bordmittel, die die SAP Module haben im Bereich IAM, IGA, können das SAP IDM in der Form nicht ersetzen.

Außerdem wissen wir, dass die SAP sich selber ein Stück weit von dem Tool distanziert, also strategisch gesehen auch davon abrät, es weiterhin zu implementieren. Und das stellt im Endeffekt, wenn man zwischen den Zeilen liest, die meisten Unternehmen, die heute SAP IDM nutzen, vor eine relativ simple Herausforderung, nämlich sich zu überlegen, möchte ich bei SAP IDM bleiben, trotz der Tatsache, dass wir hier die Fakten, die hier abgebildet sind, kennen, das heißt End of Life, oder aber möchte ich auf ein neues Tool migrieren und nicht bei SAP IDM bleiben.

Um das bewerten zu können, sollte uns aber klar sein, was sind denn die Treiber? Was passiert denn, wenn SAP IDM abgelöst wird, was hat das für Konsequenzen für mich? Und da schauen wir uns drei Dinge an, nämlich einmal Effizienz, Risiko und regulatorische Anforderungen. Wenn SAP IDM abgelöst wird, dann heißt das für uns im Bereich Effizienz relativ einfach, wir werden keine neuen Prozesse mehr sehen, wir werden keine fachlichen Funktionen mehr bekommen, wir werden keine technischen Schnittstellen mehr haben, beziehungsweise neu dazubekommen, haben werden wir sie natürlich noch.

Dasselbe gilt für Automation, also Automatisierung, Optimierung, wir sind im Endeffekt in einem Zustand, der eingefroren ist, der Status quo wird sich nicht ändern und auch dasselbe gilt für die User Experience und die Nutzeroberfläche.

Das Einzige, was sich höchstwahrscheinlich ändern wird, davon ist auszugehen, sind die Wartungs- und Betriebskosten, die höchstwahrscheinlich steigen werden, weil die wenigen Experten, die zu diesem Thema noch existieren, hart umkämpft sein werden und außerdem, wenn wir neue Funktionen brauchen, werden wir mit Customizing arbeiten müssen, was auch sich entsprechend auf die Wartung und den Betrieb auswirken wird.

Wenn wir uns das Thema Risiko angucken, dann können wir auch da davon ausgehen, dass es keine Patches geben wird, es wird keine Updates geben, keine Verbesserungen in dem Sinne, dass wir sagen können, die Angreifer werden besser, also werden wir auch besser, es werden keine Lücken gestopft an der Stelle, keine neuen Security Features.

Sprich, wenn wir mit diesem Wissen auf die regulatorischen Anforderungen gucken, wird es für uns natürlich auch auf der einen Seite eine größere Herausforderung werden, die bisherigen regulatorischen Anforderungen zu erfüllen, aber auch zukünftige regulatorische Anforderungen, die dann Stück für Stück auftauchen, werden schwerer zu erfüllen sein. Das heißt, mit Blick auf Governance und Compliance wird es sehr viel schwerer werden, konform zu sein.

Das heißt, die Konsequenzen für uns, wenn wir mit SAP IDM weiter arbeiten, ist absolut gesehen, dass wir auf dem aktuellen Status quo stehen bleiben und keinen Fortschritt mehr machen. Relativ gesehen heißt das aber, wenn wir uns nicht bewegen und der Rest der Welt schon, werden wir langfristig, relativ gesehen, immer schlechter im Verhältnis gesehen zu den Best Practices und den Angreifern, die sich sehr wohl weiterentwickeln werden. Hier also noch mal eine weitere Umfrage im Hintergrund. Ich würde ganz gerne wissen, was sind denn für Sie die prominentesten Treiber im IDM-Umfeld?

Ist es die Effizienz, ist es das Risiko oder sind es die regulatorischen Anforderungen? Auch hier im Hintergrund die Umfrage gestaltet. Würde mich freuen, wenn Sie die beantworten würden. Dann können wir in der Q&A-Session darauf eingehen. Mit den Konsequenzen, die wir uns gerade angeguckt haben und den Fakten, die wir auf der Folie gesehen haben, müssen wir eigentlich davon ausgehen, dass SAP sich strategisch selbst von der Lösung distanziert, dass wir keinen Investitionsschutz haben. Mit End of Life ist SAP IDM in der Form nicht länger zukunftssicher.

Das heißt, langfristig gesehen ist die einzige Strategie, die wir wählen können, ein Replacement dieser Lösung, eine Migration auf eine neue Option. Das heißt, auf dem Papier gesehen bleiben uns theoretisch drei Optionen, nämlich Option 1. Wir können natürlich weiterhin bei SAP IDM bleiben. Daran hindert uns ja im Endeffekt erstmal niemand. Uns muss jedoch klar sein, was die Konsequenzen für uns bedeuten. Das heißt, ich habe es eben erwähnt, relativ gesehen werden wir konstant kontinuierlich schlechter und wir werden höchstwahrscheinlich höhere Betriebs- und Wartungskosten haben.

Wenn wir migrieren wollen, dann haben wir im Endeffekt zwei Optionen, nämlich einmal die Tool Selection und einmal die IGA Migration, wenn ich bereits weiß, auf welches Tool ich wechseln möchte. Die Tool Selection, die Tool Auswahl soll uns dabei helfen, das richtige Tool für uns zu finden. Das heißt, hier habe ich die Möglichkeit im Rahmen eines Auswahlprozesses das richtige Tool für mich zu finden, das meinen Anforderungen in diesem Sinne gerecht wird. Bei der Tool Auswahl gibt es natürlich auch gewisse Nachteile, nämlich in dem Sinne, dass es immer ein Investment ist.

Also ich investiere Zeit, ich investiere Geld, um Informationen, nämlich das Tool, was zu mir passt, zu bekommen und in der Hoffnung natürlich dann auch das richtige Tool. Denn auch da wähle ich den falschen Approach, dann kann es durchaus passieren, dass ich das für mich falsche Tool finde, beziehungsweise eine schlechte Entscheidung treffe und nicht das richtige Tool erwische. Diese Risiken bestehen natürlich immer. Was wichtig ist zu betrachten, ist außerdem die Timeline. Bei der Tool Auswahl würde ich ansetzen mindestens sechs Monate. Das kann bis zu zwölf Monate dauern.

Also fangen Sie früh genug an. Eine Tools Choice ist nicht in zwei Wochen erledigt. Dasselbe bei der IGA Migration.

Auch hier, wenn ich mein Tool gefunden habe, kann ich den Tool Wechsel vollziehen und dann die Vorteile nutzen, die dadurch für mich entstehen. Das heißt, ich kann zum Beispiel alle Sachen einfach nochmal anfassen, nochmal überdenken, alles kritisch hinterfragen. Dazu gehört Automatisierung, Optimierung von Organisationsaspekten, von Prozessen, von technischen Fragestellungen. Ich kann aber auch die fachlichen und regulatorischen Anforderungen anschauen und kann gucken, wie ich es schaffe, die besser oder möglicherweise schneller umzusetzen. Und ich kann mich um Altlasten kümmern.

Das heißt, ich kann Datenbanken aufräumen, ich kann historische Schiefstände korrigieren, Wildwuchs, wie man ihn so schön nennt, oder auch technical debts, technische Schulden aufräumen, die ich in der Vergangenheit angesammelt habe. Das wiederum ist aber insgesamt durchaus ein zweischneidiges Schwert. Denn wenn ich das nicht tue, wenn ich diese alten Schulden, diesen Wildwuchs nicht reinige, kann es durchaus passieren, dass ich mir genau das in das neue Tool lade und dann nichts anderes mache als vorher nur auf einer neuen Basis, auf einem neuen Tool. Das gilt es natürlich zu verhindern.

Neben diesem Risiko besteht außerdem das Risiko der Project Delivery oder aber auch des Investment Risk, also die klassischen Projektrisiken, dass das Projekt nicht das Ergebnis liefert, was ich mir durch diese Investition erhofft habe. Timeline auch hier für eine IGA Migration mindestens zwölf Monate, besser jedoch 24 Monate. Zwölf Monate würde ich nur ansetzen, wenn es ein relativ limitierter Scope ist oder bzw. und schon ein gewisser Reifegrad in diesem Umfeld besteht und nicht alles hinterfragt werden muss. Ansonsten erfahrungsgemäß mindestens 24 Monate Ansätze.

Schauen wir nochmal ganz kurz auf die Tools Choice. Das heißt, was müssen wir dort tun? Was blüht uns dort? Bei Kupinger Coal gehen wir in der Tools Choice immer in fünf Phasen vor. Das heißt, in der ersten Phase Assessment Information Collection Phase geht es darum, Informationen einzusammeln. Abzufragen, was sind die Schmerzen? Was sind die Erwartungen? Was ist das Requirement, das erfüllt werden muss? Um dann in der zweiten Phase in der Enterprise und Market Analysis genau diese Fragestellungen im Endeffekt weiterzugeben. Das heißt, sich zu überlegen, was sind meine Requirements?

Was muss ich den Hersteller fragen? Und auf der Market Analysis Seite, welche Hersteller muss ich überhaupt fragen? Was sind die Hersteller mit den Tools, die für mich überhaupt in Frage kommen? Nur wenn ich das beides zusammenbringe, dann kann ich in die Phase drei übergehen, nämlich die Vendor Communication und die Vendor Presentation. Das heißt, den Hersteller direkt anzusprechen und einzuladen, um das Tool einfach zu präsentieren, eine gewisse Agenda zu durchlaufen und zu zeigen, was sind die Fähigkeiten, die uns das Tool liefert.

Die Vendor Presentations werden dann üblicherweise genutzt, um potenzielle POC-Kandidaten zu identifizieren und diese dann einzuladen, um eben eine Demo im System aufzubauen, mit der ich dann den einen oder anderen Use Case auch mal wirklich ausprobieren kann auf meiner eigenen Umgebung, beziehungsweise abfragen kann. Last but not least haben wir die Management Decision. Das heißt, als Ergebnis aus dem POC muss ich natürlich eine Entscheidung für einen der POC-Kandidaten treffen. Üblicherweise im POC mindestens ein Kandidat, maximal drei Kandidaten. Einer von denen wird es üblicherweise.

Werfen wir mit der nächsten Folie nochmal einen Blick auf die ersten beiden Phasen. Denn das Setup hier ist besonders wichtig, um gute Ergebnisse zu erzielen. Was wir aus Kuppinger Coal Sicht immer tun, ist in diesen drei Säulen vorzugehen. Das heißt, wir starten üblicherweise ganz links mit dem Strategic IAM Scoping und den beiden Frameworks, die wir von Haus aus mitbringen, um eine strukturierte Analyse zu garantieren.

Das heißt, wir nutzen die Kuppinger Coal Identity Fabric und die Kuppinger Coal IAM Reference Architecture, um strukturiert diese Requirements zu erheben und Probleme beziehungsweise Beobachtungen zu diskutieren. Das heißt, daran hangeln wir uns fachlich entlang. In der mittleren Säule sehen wir die Enterprise-Seite. Das ist der Five-Step-Approach, wie wir im Endeffekt von diesen Beobachtungen, von diesen Schmerzen, die man gegebenenfalls hat, über die Erwartungshaltung an die Requirements kommt, um daraus dann nachher die Fragen für die Hersteller abzuleiten.

Damit sind wir im Endeffekt aus Enterprise-Sicht soweit fertig, dass wir wissen, was sind die Schmerzen, was sind die Requirements, was wissen wir die Hersteller fragen. Und dann gehen wir über zur Market-Seite. Das heißt, an dieser Stelle überlegen wir uns, welche Hersteller, welche Produkte kommen überhaupt in Frage, um diese Fragen zu stellen und dann diese Fragen auch zu übergeben. Und nur wenn wir beides zusammenbringen, können wir für uns das beste Tool identifizieren.

Wenn ich dann hoffentlich an dem Punkt angekommen bin, dass ich für mich das Tool gefunden habe und eine Entscheidung getroffen habe, dann wechsle ich irgendwann in die IGA-Migration. Das heißt, in ein Projekt, wo ich mich von SAP IDM lösen möchte und hin zur neuen IGA-Solution migrieren will. Was wir hier sehen, ist jetzt erstmal nur ein beispielhafter Plan. Der kann für Sie individuell ganz anders aussehen, weil da jedes Unternehmen ein bisschen anders tickt, einen unterschiedlichen Reifegrad hat, vielleicht verschiedene Herausforderungen hat.

Was wir aber oder was ich aus meiner Erfahrung heraus sagen kann, dass die meisten IGA-Migrations im Endeffekt sich um zwei Hauptaktivitäten drehen. Einerseits die IGA-Solution aufzubauen. Das ist das, was wir hier in der oberen Hälfte sehen. Und auf der anderen Seite Applikationen zu integrieren, sodass die Funktionen genutzt werden können, die wir vorher in der IGA-Solution aufgebaut haben. Zum Aufbau beschäftigen wir uns mit ganz verschiedenen Aspekten. Das heißt mit den Commercials, wo es um Licensing oder um das Aufsetzen des Projektes geht.

Wir beschäftigen uns mit dem Technical Setup, damit das Tool an sich ans Laufen kommt. Wir beschäftigen uns mit Prozessthemen. Wir beschäftigen uns mit dem funktionalen Design, mit den Policies, mit den Guidelines, um da im Endeffekt ein gutes Tool mit möglichst vielen guten fachlichen Funktionalitäten aufzubauen. Um diese Funktionalitäten nutzbar zu machen, müssen wir aber Stück für Stück Applikationen anbinden und das Rollout in die Breite sicherstellen. Und die Kernaussagen habe ich hier ein bisschen in die roten Boxen gepackt. Ich fange mal links unten an, weil es gerade passt.

Wenn wir diese IGA-Solution aufgebaut haben und einen gewissen Reifegrad erlangt haben, können wir mehr und mehr Applikationen anbinden und dafür Mehrwert generieren. Andersrum gilt aber, wenn wir zu früh anfangen und noch nicht eine entsprechende Menge an Funktionalitäten aufgebaut haben, dann ist es sehr, sehr schwierig, diesen Mehrwert auch zu generieren. Das heißt, ruhig an der Stelle mit dem Application Onboarding, mit einem kleinen Delay beginnen und ein Stück später anfangen, als die eigentliche IGA-Solution eingeführt wird.

Zweite Box rechts in der Mitte, auch da wieder der Hinweis auf die Timeline. Eine IGA-Migration wird wahrscheinlich mindestens 24 Monate in Anspruch nehmen. Wenn man es in 12 bis 24 Monaten plant, dann achten Sie bitte darauf, was der Scope ist und wie reif man im Bereich IGA heute schon ist. Denn dann ist die Nachfrage beziehungsweise das kritische Hinterfragen dieser Prozesse, die wir oben sehen oder der funktionalen Designs ein Stück weit limitiert. Und die dritte Box hier oben rechts, auch da nochmal der Hinweis, der Fokus sollte zunächst auf dem Aufbau der IGA-Solution liegen.

Und später, wenn wir einen gewissen Reifengrad erreicht haben, mit dem wir zufrieden sind, können wir dazu übergehen, die Ressourcen, die zu diesem Aufbau genutzt werden, runtershiften Richtung Application Onboarding und dann dort mehr in den Rollout investieren und weniger in den Aufbau der Lösung. Gut, um meinen Vortrag abzurunden, nochmal eine Summary-Slide mit den wichtigsten Takeaways. SAP IDM Ende der Wartung 2027, Extended Support Ende 2030. Wichtig dafür ist aber zu verstehen, was treibt mich eigentlich im IGA-Umfeld, damit ich die richtigen Schlüsse daraus ziehen kann.

Ist es Effizienz? Ist es Risiko? Sind es die regulatorischen Anforderungen? Was treibt mich an der Stelle? Dann der Punkt 3, Long Term Strategy. Wir wissen, dass SAP IDM abgelöst wird. Wir wissen um die Konsequenzen, die das mit sich bringt. Also müssen wir uns überlegen, was tun wir und da kann für mich die einzig sinnvolle Lösung nur die Migration sein. Dann Punkt 4, Strategic Planning Timelines.

Wenn Sie in die Migration gehen wollen und sagen wollen, ich möchte mich an der Stelle weiterentwickeln, ich möchte eine Tools Choice durchführen, ich möchte eine Migration durchführen, planen Sie genug Zeit ein. Tools Choice mindestens sechs Monate, Migration mindestens zwölf Monate, besser wahrscheinlich 24 Monate einplanen. Das immer mit Blick auf 2027, Wartungsende von SAP IDM. Also mein Call for Action hier, fangen Sie frühzeitig an, bevor es zu spät ist. Und dann runde ich meinen Vortrag auch ab mit der letzten Umfrage, die ich mir überlegt habe.

Und zwar würde ich ganz gerne wissen, wer sich heute eigentlich schon auf dem Weg befindet. Das heißt, haben Sie Interesse, sich von SAP IDM wegzubewegen? Ja oder nein? Und wenn ja, haben Sie schon eine Migration geplant? Befinden Sie sich vielleicht auch schon im Migrationsprojekt oder haben Sie Ihre Migration vielleicht schon abgeschlossen? Ich würde mich freuen, wenn wir dann zu dieser Umfrage auch nachher in der Q&A-Section einige Antworten hätten. Gut und damit übergebe ich an Klaus und Christian. Vielen Dank.

Ja, du hast viele Fragen gestellt, Philipp. Wir bringen jetzt einige Antworten auf diese Fragen mit und möchten natürlich im Prinzip dieses Thema insofern erstmal angehen, dass wir uns nochmal so ein bisschen Gedanken machen über die IGA-Migration, die du angesprochen hast. Ich glaube, das Thema SAP IDM ist insofern sicherlich im IGA-Kontext speziell, weil auf der einen Seite fast alle Kunden, die SAP IDM nutzen, auch SAP-Kunden sind und das ECC oder auch das frühere R3 oder heutzutage auch das SAP S4HANA nutzen.

Insofern ist da auch immer eine gewisse Korrelation zu dem Kernsystem, zum ERP-System zu sehen. Und auf der anderen Seite war es natürlich auch so, dass für bestimmte Systeme wie eben SAP-Systeme oder auch Active Directory man das SAP IDM auch kostenfrei nutzen konnte. Und insofern liegt es relativ nah, natürlich, wenn man SAP einführt, man möchte nicht die zentrale Benutzerverwaltung nutzen, weil die eben nicht ins AD provisionieren kann, aber dass man sich dann eben das IDM anschaut. Und genau jetzt eigentlich in dieser Situation auch ist, wie gehen wir jetzt damit um?

Ich glaube, du hast es angesprochen, 2027 ist es erstmal primär abgekündigt, dass der Support ausläuft, was Updates, Upgrades etc. angeht. Und insofern haben Klaus und ich uns mal Gedanken gemacht, was sind eigentlich so Kernüberlegungen und warum ist SailPoint überhaupt eigentlich jetzt die richtige Lösung? Und ich glaube, wir sehen auf der nächsten Folie, da kommen wir auf das Thema RISC zu sprechen, du hast es eben auch als eine deiner Kernsäulen gehabt. Und da möchte ich jetzt nochmal so diesen Brückenschlag zu dem Thema SAP nochmal bringen.

Und wir sehen hier auf der Folie zwei Zahlen, wer mich kennt, weiß, dass ich Zahlen immer sehr gerne mag. Und in diesem Fall ist es so, dass in dieser besagten Umfrage hier die Forbes 500 CIOs und CISOs befragt worden sind. Wie schätzt ihr das denn eigentlich ein? Wie kritisch ist das, wenn ein SAP-System gehackt wird, ein Data Breach gibt? Und 92% sagen, ist es ernst, sehr ernst oder katastrophal. Je nachdem halt, wie man seine SAP-Landschaft nutzt. Und ich meine, wenn man jetzt nicht so Gedanken macht, wie ist der Angriffspfad, dann kommen wir häufig über eine gekapelte Identity.

Und wenn wir nicht supportetes IGA-System haben, haben wir dann natürlich schon vielleicht auch einen guten Eingriffsvektor, Angriffsvektor-Einfallwinkel, wie wir dann auch uns Zugang zum SAP-System, in dem die Zahlläufe, der ganze Bankenverkehr abgewickelt wird, wie wir da einen Zugang zu bekommen können. Insofern ist das, glaube ich, aus einer Risikosicht schon, kann man hier sagen, sehr ernst bis katastrophal durch uns.

Und die verschiedenen Technologien, die auch mit SAP im Kontext stehen, sei es jetzt eine SAP HANA Cloud, sei es eine BTP, aber auch viele andere Cloud-Service von der SAP, eine HANA-Datenbank, Fioriats Frontend, IoT-Devices in den Produktionsstraßen, all das auf der einen Seite macht es natürlich nochmal deutlich komplexer und auf der anderen Seite erhöht es auch wieder die Wahrscheinlichkeit eines Angriffes auf diese Infrastruktur und Applikationslandschaft. Und das sehen 59 Prozent dieser CIOs und CISOs eben genauso.

Insofern aus meiner Sicht schon Handlungsbedarf, wenn ich SAP IDM nutze und alleine schon aus der Aussage heraus, um natürlich auch meine Kern-Applikation und meine Kern-Assets zu schützen. Auf der nächsten Folie haben wir uns Gedanken gemacht, was denn so klassische Success-Faktoren sind. Und ich sage mal, der erste Punkt an der Stelle ist relativ einfach. Im SAP-Jargon sagt man immer, ist es Greenfield, ist es Brownfield, ist es Bluefield oder ist es ein Lift-and-Shift-Approach an der Stelle?

Ja, das wäre quasi das Brownfield an der Stelle, was ich meinen Kunden nicht empfehlen würde. Natürlich hat man sich Gedanken gemacht, wie man ein IGA-System aufbaut, welche Prozesse man braucht. Auf der anderen Seite, wenn man vor zehn Jahren SAP IDM eingeführt hat oder jede andere IGA-Lösung auch, hat sie natürlich viel getan. Regularien, sei es jetzt das IT-Sicherheitsgesetz 2.0, NIST 2, Financial Market Regulations und so weiter, die haben sich natürlich durchaus verändert.

Insofern vielleicht auch noch mal ein guter Zeitpunkt, eben doch nicht Lift-und-Shift zu machen, sondern sich doch noch mal zu überlegen, ob man irgendwo eine Greenfield- oder eine Bluefield-Migration machen möchte. Und ich glaube, da bietet eben auch genau jetzt dieser Zeitpunkt und auch dieses End-of-Life-Statement von der SAP durchaus eine ganz charmante Chance, sich genau darüber noch mal Gedanken zu machen. Das sehen wir auch auf der nächsten Folie noch mal.

Aus meiner Sicht der zweite Punkt, den wir da sehen, wenn ich mich entscheide, mich jetzt von SAP IDM zu lösen und eine neue Lösung zu suchen, dann sollte man eine Lösung suchen wie eben SailPoint mit den verschiedenen IGA-Produkten, die einen hohen Grad an Out-of-the-Box-Capabilities mitbringen. Also Connectoren, darüber wirst du gleich noch ein bisschen sprechen, Klaus. Auch das Thema Risiko gerade im SAP-Umfeld, Funktionstrennungskonflikte. Ich glaube, jeder, der mit SAP zu tun hat und mit Berechtigung, der erkennt auch das Thema Funktionstrennung, kritische Berechtigung in SAP.

Konnte man mit der SAP IDM-Lösung jetzt auch nicht so ganz effizient monitoren. Aber bei SailPoint gibt es da eben auch eine Lösung, die genau das exakt auch abdeckt. Also insofern, ich will mich ja nicht verschlechtern, sondern wenn es schlecht läuft, will ich mein Level halten. Wenn es gut läuft, will ich mich verbessern. Und das am besten mit einem Partner natürlich auch, der mich, wie Philipps eben schon aufgeführt hat, durch diese verschiedenen Phasen auch begleiten kann.

Der den Markt kennt, die Lösung kennt, der SAP vor allem auch kennt, weil, wie ich schon gesagt hatte, die Kunden, die SAP IDM im Einsatz haben, nutzen auch SAP. Insofern gerade da dieser Brückenschlag ist aus meiner Sicht sehr, sehr wichtig, weil in der EM-Community sprechen wir über Entitlements, in der SAP-Community sprechen wir über Rollen und Berechtigungsobjekte.

Insofern da einen Berater zu haben, einen Partner zu haben, der eben auch diese beiden Sprachen spricht, ist aus meiner Sicht sehr wichtig und kann eben auch helfen, diese Timeline, die Philipp vorgestellt hat, durchaus auch etwas aggressiver zu setzen und auch wirklich eine Migration mit Enhancements entsprechend umzusetzen. Auf der nächsten Folie, du hast sie eben schon kurz ausgeblendet, Klaus, sehen wir nochmal ein paar weitere Considerations hier. Der Punkt im Prinzip hier ist, was ist denn für mich jetzt der richtige Ansatz?

Ich hatte es eben schon mal gesprochen, es ist Lift und Shift, also das, was wir vorher gemacht haben, machen wir in der neuen Lösung auch so, wo ich mich immer schon frage, warum wir fünf Approvals bei einem ganz einfachen Access-Request brauchen. Oder nutzen wir die Chance und überlegen, was haben wir, was läuft gut, was können wir besser machen und was ist state of the art?

Da sind wir natürlich auch wieder bei Themen wie Automatisierung und AI, aber im Wesentlichen, aus meiner Sicht ganz wichtig, eine Migration sollte kein Downgrade sein, sondern es ist wirklich eine Chance, Sachen nochmal zu überdenken, Sachen besser zu machen. Und was sind so klassische Themen, wo wir sehen, dass durchaus Potenzial für eine Optimierung vorhanden ist im IAM-Modell? Auf der einen Seite Standardisierung von Prozessen. Brauchen wir fünf verschiedene Access-Request-Prozesse oder können wir es vielleicht doch auf ein oder zwei reduzieren?

Welche Möglichkeiten habe ich, meinen Automationsgrad zu erhöhen? Habe ich vielleicht einige Applikationen, die noch nicht angebunden sind, die dann manuell provisioniert werden? Da kommen wir gleich nochmal auf die ganzen Konnektoren, die ihr habt für SAP auch zu sprechen. Wie kann ich auch mein Datenmodell harmonisieren? Aus meiner Sicht auch ein ganz wichtiges Thema, auch gerade im Kontext, wenn wir mal so IGA oder Identity and Access Management End-to-End denken. Wo kommen meine Daten her? Wie viele Identitätsquellen habe ich?

Welche Daten synchronisiere ich mit meinen Applikationen und so weiter? Aus meiner Sicht nochmal auch eine tolle Chance. Das Thema User Experience ist auch ganz wichtig. Sprechen wir ja heute fast überall. User Experience ist ein wesentlicher Punkt, auch für die Adaption, fürs Change Management. Auch das wäre wieder mal ein guter Punkt, das zu überdenken. Und last but not least natürlich das Thema Application Connectivity. Also wirklich, das ist auch in den zwei Phasen schön dargestellt, Philipp.

Die eine Phase ist die Migration oder die Implementierung, je nachdem ob Lift and Shift oder Green oder Bluefield. Und das andere Thema, die Applikations-Connectivity. Auch da eine Chance, Out-of-the-Box-Konnektoren zu nutzen. Und schlussendlich, ganz wichtig, da kommen wir wieder zum Thema Risiko zurück. Das Ganze muss natürlich so geplant sein, dass es eben kein Risiko für den Geschäftsbetrieb darstellt, aber natürlich auch nicht aus einer Compliance-Sicht.

Sprich, im SAP-Kontext möchten wir natürlich nicht, dass aus Versehen jetzt alle Benutzer auf einmal SAP All provisioniert bekommen, was sicherlich zu langwierigen Diskussionen mit den Prüfern intern wie extern führen würde. Sondern natürlich muss auch das adressiert sein, dass unabhängig davon, welchen Ansatz man wählt, die regulatorischen Anforderungen immer beibehalten werden und natürlich auch jetzt durch eine Migration eben nicht den Geschäftsbetrieb unterbrochen wird. Das waren so ein paar Gedanken, die wir mit Ihnen und euch nochmal teilen wollten hier.

Wir wollen jetzt aber auch nochmal einen großen Fokus darauf legen und ich hatte ja schon ein bisschen großmundig angekündigt, wir wollen es nicht verschlechtern, sondern idealerweise verbessern und Klaus, das ist, glaube ich, dein Stichwort, um nochmal verschiedene Punkte aus der Sicht von SailPoint einzugehen. Ja, danke für den Elfmeter, Christian.

Ja, das ist genau das, was wir versuchen. Ich meine, ich bin jetzt als Hersteller hier in diesem Call drin. Sie haben jetzt zwei wirklich unabhängige Meinungen dazugehört, wie man am besten damit umgeht. Mir obliegt es jetzt, Ihnen einfach mal ein paar Werkzeuge vorzustellen, mit denen ich das tatsächlich auch dann machen kann. Also nicht nur darüber reden, was man denn tun kann, sondern wie wir uns das vorstellen.

Ich meine, wir bei SailPoint sehen sowieso, dass IT immer nur miteinander funktioniert, nicht ausschließlich für irgendwas anderes. Also wir versuchen uns immer in irgendeiner Form zu integrieren und nicht zu sagen, das musst du aber alles mit uns machen. Also Integration ist bei uns immer ganz wichtig und so haben wir das eben auch auf der SAP Seite geplant.

Das heißt, es gibt im Prinzip Connectivity zu allen Punkten, aber es geht uns wirklich darum, einfach über diese Integration einmal zu sagen, ihr habt die Option, alles anzubinden, was ihr dort habt, aber natürlich auch Governance, Risk und Compliance so aufzubauen, dass es tatsächlich den Vorstellungen der Kunden entspricht. Wir machen das am liebsten mit Partnern, wie einer IBM beispielsweise, aber wir nutzen auch das SAP Partner Ecosystem. Das heißt, wenn der Kunde bereits eigene Partner hat, mit denen er gerne arbeiten wird, dann kann er das natürlich auch gerne machen.

Unsere Tools sind üblicherweise bekannt in der Community. Und nur um zu erzählen oder zu zeigen, dass wir da nicht nur jetzt ins Blaue reingesprochen haben, so nach dem Motto, wir können alles verbinden. Ich habe mir einfach so ein paar Dinge, die heute immer wieder hochkommen, genannt. Sie sehen von den direkten Cloud-Verbindungen hier unten links und rechts haben wir direkte Konnektoren hin, mit denen wir arbeiten können, die natürlich einen ganz anderen Anspruch haben, wie hier oben links die Konnektoren, die eben viel noch On-Prem dabei sind, wo man über diese Dinge reden muss.

Wir können uns zu all diesen Sachen konnektieren. Sie werden vielleicht fragen, warum sind das so viele?

Na ja, SAP hat halt eben auch viele Schnittstellen, auch viele Applikationen teilweise zugekauft, die eben angeschlossen werden sollen. Von daher ist das ein gewisser Umfang, der einfach da ist. Der wichtigste Punkt ist aber sicherlich, dass wir verstehen, also wir sehen die Welt halt nicht aus der SAP-Sicht auf den Rest der Welt, sondern wir sagen SAP, so komplex auch es immer sein mag, ist natürlich nur oft ein Baustein von vielen, die im Unternehmen sind. Also Sie finden heute in großen Unternehmen leicht mehrere hundert Anwendungen und das sind nicht nur SAP-Anwendungen.

Unsere größten Kunden haben über tausend Anwendungen an einem System angeschlossen. Also das sind dann diese rechte Seite hier, wo wir sagen, wir haben natürlich auch alle anderen Systeme, Konnektoren zu. Also Connectivity ist nach wie vor ein wichtiger Punkt, wobei das nicht nur die einfache Verbindung ist. Also wie komme ich denn dahin? Verbinden kann man heute im Prinzip alles, was in irgendeiner Form einen Stecker hat. Aber wie einfach ist das? Das heißt, wenn wir über direkte Konnektoren reden, heißt das, wir kennen die Ziel-API, wir kennen das Schema der Ziel-API.

Also das ist ein Punkt, der sicherlich entscheidend ist. Was machen wir daran? Ich hatte schon gesagt, alles egal, ob das jQuery ist, SCIM, REST-API, ob es Reports sind in den iDocs, die es ja immer noch gibt, egal was dort getan wird, wir gehen immer nach dem gleichen Schema davor. Wir lesen und aggregieren Accounts und die Enttitlements, also die Berechtigungen dazu aus dem System, was immer das für ein System sein mag. Wir können dort alle Operationen mit den Konnektoren machen, die heute üblich sind. Also von dem Erzeugen, von dem Update von Accounts löschen oder disablen.

Also all diese Optionen sind nach wie vor drin und natürlich die Synchronisation von Attributen. Speziell jetzt denken Sie nur an HR, wo halt in aller Regel eine E-Mail-Adresse fehlt, in aller Regel eine Telefonnummer fehlt oder ein Global Identifier. Das können wir natürlich auch in die Applikation zurückschreiben. Also das ist so, wie die Integration grundsätzlich funktioniert dazu. Es gibt sicherlich eine spezielle Ausrichtung in SAP GSE. GSE ist halt weit mehr als nur eine vollständige eigene Applikation, die auch unterschiedlich weit ausgebaut ist bei Kunden.

Aber wir wissen natürlich, dass viele Leute viel, viel Geld in GSE investiert haben und wie kann man das Beste machen. Nun, wir nutzen GSE in der Form, dass wir halt abfragen, ob es denn eine SOD-Violation gibt. Und da gibt es halt eine bestimmte Reihenfolge, um das zu verstehen. Also wir sind kein Ersatz für SAP GSE, aber wir können sehr wohl mit dem SOD Risiken umgehen. Also in einem Fall, dass SAP GSE eingesetzt ist, dann fragen wir halt bei SAP GSE an, gibt es denn da irgendeinen Einwand dagegen?

Dann können die Workflows innerhalb von SAP GSE sein und je nachdem, wie das Ergebnis davon ist, wird dann eben in unserem System der Entscheidung getroffen, diese Berechtigung wird zugewiesen oder halt eben nicht. Das heißt, wir respektieren in vollem Umfang, was bereits an Geld in SAP GSE investiert worden ist, sondern wir partizipieren einfach aus dem Ergebnis davon. Also auch da ein Punkt, wo einfach Geld weiterhin mitgenutzt werden kann.

Und wir haben jetzt diese Connectivity, um es ein bisschen einfacher zu machen, dass man nicht sich überlegen muss, was muss ich denn eigentlich alles einkaufen dazu. Wir haben das einfach in Basispakete eingebaut. Es gibt einmal das SAP Essentials, wo sage ich mal alle heute gängigen, üblichen Konnektoren einfach vorhanden sind und drin sind, die man einfach nutzen kann. Da ist das, was heute so 90 Prozent genutzt wird beim Kunden, ist in diesen SAP Essentials einfach mit eingebaut.

Und wir haben natürlich auch noch die Option, unser Access Risk, wenn ich mich noch reinnehme, da habe ich gleich noch zwei Slides zu, die tatsächlich, wenn SAP GSE nicht besonders ausgeprägt im Einsatz ist oder möchte vielleicht von SAP GSE weg oder man braucht eigentlich nur die SOD-Variante davon, haben wir eine Option, die es tatsächlich etwas einfacher macht mit diesen Access Risks. Mit diesen SOD-Variations von SAP umzugehen und das wäre dann die Integration für SAP GSE und SailPoint ARM.

Da ist halt, also ARM steht für Access Risk Management, da sind die Essentials mit dabei und es wird halt eben noch das GSE-Modul, beziehungsweise die ARM-Riskkapazität mit reingenommen. Und dieses Risk Governance sieht nun vor. Wir haben halt gelernt, dass viele Kunden tatsächlich nur an den SOD-Variations, also an den Secretation of Duties interessiert sind. Wie gehe ich damit um? Was mache ich damit? Und wir haben in jedem SAP-System bereits diese SOD-Variations gefunden, in nicht unerheblichem Maß teilweise, teilweise auch völlig unbekannt bei dem Kunden gewesen. Was macht man damit?

Wie geht man damit um? Wir haben ein Produkt dafür, was sich speziell darauf ausrichtet, diese SOD-Variations aufzulösen und damit umzugehen. Das heißt also, wir können den Emergency Access damit managen, also den berühmten SAP Firefighter. Wir haben auch What-If-Simulationen dabei. Ich kann also gucken, wenn ich jemandem bestimmte Richtungen gebe, was hat es für Auswirkungen? Das sind all diese Dinge, die mit dabei sind. In allererster Linie kommt es dabei zu einem aus meiner Sicht völlig unterschätzten Verbesserung.

Dieses TTV ist oftmals, also diese Time-to-Value, das ist oftmals, also diese Total Cost of Ownership kennt eigentlich jeder, aber diese Time-to-Value, das heißt also, wenn ich denn etwas gekauft habe, wie schnell habe ich denn daraus einen Wertgewinn? Das ist halt in diesem ARM-Produkt sehr, sehr einfach, weil es innerhalb von wenigen Stunden installiert ist, die installierten Systeme ausliest und unmittelbar im Prinzip schon sagen kann, wo gibt es Probleme?

Weil wir einfach selber ein Playbook mitbringen, mit dem man arbeiten kann, aber Sie natürlich auch Ihr eigenes Playbook mit einsetzen wollen, wenn Sie mögen. Einfach nochmal einen Blick da rein, wie sieht das aus? Also ich habe jetzt einfach nochmal einen Screenshot, falls Sie daran interessiert sind, können wir natürlich da gerne tiefer einsteigen. Aber Sie sehen sofort, wo gibt es denn, also Sie sehen einmal die Violation grundsätzlich, also was habe ich denn für Verletzungen von irgendwelchen Vorgaben, die eigentlich nicht zusammen an einem Menschen hängen sollten?

Sie können aber auch genau sehen, wie wurde welche Seite einer Violation benutzt? Wir finden das relativ häufig, dass es Violations beim Kunden gibt, also er hat zwei Berechtigungen, die ja nicht gemeinsam an einem Mitarbeiter kombiniert sein sollten. Aber er nutzt sowieso nur eine Seite der Berechtigung, weil er vielleicht möglicherweise gar nichts davon weiß, dass er eine zweite hat, aber er macht halt eben seinen Job so, wie er ihn machen sollte und er nutzt die zweite Violation gar nicht, was natürlich leicht aufzulösen ist, besonders wenn es recht leicht wegzunehmen ist.

Aber es gibt natürlich auch welche, die beiden Seiten sehr heftig nutzen und da muss man dann schon mal hinterfragen, wenn das denn eigentlich verboten sein sollte, warum macht das derjenige? Dann passiert da vielleicht irgendwas, was ich mir da nicht so gewünscht habe. Also das gibt sehr schnell einen Einblick da rein, wie Berechtigungen aus den SAP-Systemen tatsächlich genutzt werden.

Also einfach nur zu zeigen, wir verstehen sapanesisch, wir wissen, was dort passiert an der Ecke, wir haben die Konnektoren, diese Sachen aufzulösen, die Sachen in einem, ich sag mal, global erarbeiteten IAM-System unterzubringen, als es vielleicht SAP IDM Ihnen bisher gezeigt hat oder dargestellt hat und das ist eigentlich das, wo ich Ihnen empfehlen würde, mit uns einfach mal darüber zu reden. Besten Dank soweit von meinen Slides. Wir kämen dann zu den Fragen und Antworten.

Gut, Klaus. Vielen Dank für den Vortrag, auch an dich Christian. Dann würde ich vorschlagen, wechseln wir in die Q&A-Session und dafür schauen wir uns zunächst einmal die Umfrageergebnisse an. Wir haben eine rege Teilnehmerzahl gehabt bei den Umfragen. Damit würde ich ganz gerne starten. Wir hatten ja drei Umfragen an der Zahl.

So, wir hatten als erste Frage gestellt, spannenderweise für unser Webinar, wer benutzt denn eigentlich aktuell SAP IDM noch? Interessanterweise ist die meistgewählte Antwort meine Organisation nicht, was natürlich spannend ist für unser Webinar, aber interessant, dass sie trotzdem hier sind und schön, dass sie trotzdem hier sind. Wir haben aber auch 50 Prozent der Teilnehmer, die gesagt haben, wir benutzen SAP IDM und was ich sehr spannend finde, wir haben 39 Prozent, die es vor allen Dingen als primäre Lösung benutzen.

Klaus, was denkst du? Ist das eine hohe Zahl? Hatten wir das erwartet? Was heißt das für uns?

Ja, ich habe sowas in der Art tatsächlich erwartet. Jetzt bin sicherlich kein Hellseher, aber das ist das, was auch ungefähr mein Ergebnis oder meine Erwartung ist, was ich von Kunden oft zurückgespiegelt bekomme, weil halt natürlich SAP eine extrem wichtige Unternehmensapplikation ist und man sieht halt eben viel von da aus. Man kann dort eine AD mit noch synchronisieren, kann da Sachen machen. Microsoft und SAP arbeiten an der Ecke wunderbar miteinander.

Und solange ich nur in diesem eigenen Beritt bleiben möchte und es ist leider oftmals eine gewisse Kurzsichtigkeit, dass man eben nur SAP sieht und nicht den Rest der Anwendung mit dabei, die natürlich jetzt auch sehr wohl verantwortlich sind für Compliance Einhaltung und für Risikomanagement, dann ist das genau das Ergebnis davon. Also überrascht mich nicht wirklich. Aus der SAP Brille eigentlich ein völlig normales Vorgehen, würde ich sagen. Danke.

Und was ich hier raus mitnehme aus diesen 50 Prozent und insbesondere aus den 40 Prozent, die das Ganze als primäre IGA-Lösung nutzen, nehmen Sie sich frühzeitig die Zeit, Ihren Übergang zu planen. Denn als primäre IGA-Lösung SAP IDM mit einem Ablaufdatum birgt natürlich gewisse Herausforderungen. Schauen wir uns mal dann die zweite Umfrage an, die wir geschaltet haben. Nämlich hier sehen wir nochmal, was der prominenteste Treiber ist.

Und interessanterweise, entgegen meiner Erwartung, haben wir hier mit 50 Prozent die operationelle Effizienz ganz vorne stehen, Risiken nur mit 17 Prozent und die Regulatorik als Treiber mit 31 Prozent. Was ich persönlich ein sehr spannendes Ergebnis finde, denn aus meiner Erfahrung heraus, als ich operativ unterwegs war, waren häufiger die regulatorischen Anforderungen die Treiber.

Christian, was denkst du, was siehst du aus deinem Tagesgeschäft? Entspricht das deiner Erfahrung? Ich finde es durchaus spannend. Ich fand auch schon das eben sehr spannend. Spannend fand ich übrigens auch die 12 Prozent, die es als zweite Lösung nutzen, weil es ja auch nochmal durchaus die Diskussion mit der Migration nochmal sehr interessant darstellen lässt.

Ich meine, es gibt sicherlich nicht viele Unternehmen jetzt abseits von dieser SAP-Thematik, die mehrere Lösungen da im Einsatz haben. Insofern fand ich das schon mal einen ganz spannenden Punkt. Hier sehe ich es halt durchaus auch so. Das ist mich durchaus überrascht, dass B und C zusammen noch nicht mal auf 50 Prozent kommen, weil Risiko und Regulatorien hängen ja durchaus miteinander zusammen.

Wir sehen allerdings natürlich auch, dass in den Regularien jetzt gerade auch, wenn wir jetzt über kritische Infrastruktur denken, der Schwerpunkt häufig auf anderen Themenfeldern liegt, wie beispielsweise dem Thema Threat Management. Aber ich glaube, Operational Efficiency ist auch aus meiner Sicht ein wunderbares Thema, weil es schlägt wieder diesen Brückenschlag zu aus meiner Sicht Out-of-the-Box-Themen, Automatisierung und auch gerade, wie kann ich AI nutzen und anwenden.

Da vielleicht auch sogar ein Brückenschlag zum Risiko, dass ich mehr risikobasiert arbeite und insofern dort effizienter sein kann, wo ich keine Risiken habe und einen stärkeren Fokus dafür dann eben auf die risikobehafteten Themenfelder lege. Aber wie du schon sagst, ich glaube, es zeigt einfach, diese großen Trendthemen wie AI, die sind eben auch in der IGA-Welt angekommen und stellen eben für die Unternehmen einen wesentlichen Fokus, offensichtlich, wie es so schön heißt, ein prominenter Driver für die Auswahl einer IGA-Lösung dar.

Was ich auch sehr spannend daran finde und auch sehr schön finde, wir haben es geschafft, mit dem Thema IGA wegzukommen von dem, ich muss es machen, weil die regulatorischen Anforderungen das von mir fordern und langsam hinkommen zu, ich möchte das machen, weil es mich effizienztechnisch voranbringt. Also schon ein sehr, sehr spannendes Ergebnis hier.

Gut, wechseln wir zur dritten Umfrage. Auch hier haben wir meines Erachtens sehr spannende Ergebnisse bekommen und zwar haben wir 15 Prozent, die sagen, wir möchten trotzdem mit SAP IDM weitermachen. Wir haben 62 Prozent, die gesagt haben, ja, wir haben verstanden, wir müssen uns bewegen, aber so richtig wissen wir noch nicht, wohin und wann und wie, wir haben noch nicht angefangen.

Einige haben gesagt, alles klar, wir befinden uns schon in der Tool-Auswahl und ich sage mal, die Minderheit hat es bis in das Migrationsprojekt oder sogar bis dorthin geschafft, dass die Migration schon durch ist. Auch da wieder überrascht uns das Ergebnis. Diesmal fange ich wieder mit Klaus an. Also was mich überrascht, sind die 15 Prozent, die weiterhin SAP festhalten.

Also entweder das ist wirklich ein tolles Vertrauen in SAP, nach dem Motto, die werden mir schon einen Weg zeigen, wie ich aus der Nummer rauskomme, oder sie sagen, naja, ist ja noch weit hin, 2030, dauert noch eine Weile, fließt noch viel Wasser in den Rhein runter. Ansonsten würde ich sagen, ich finde es auch super, diese vier Prozent, die sagen, wir sind im Plan dabei oder wir haben es bereits erledigt, finde ich super, Glückwunsch dafür.

Hier wäre vielleicht angebracht, einfach nochmal ein Maturity Assessment zu machen, um zu gucken, wie weit ist man denn jetzt wirklich in einem Reifegrad gestiegen oder besser geworden dabei. Aber ansonsten überrascht mich die Höhe von denen, die sagen, wir haben es noch nicht geplant, wir denken darüber nach, da was zu tun. Das finde ich schon eine relativ hohe Zahl. Aber schön, ich meine, dafür sind wir da, dafür machen wir so ein Webinar. Genau.

Christian, hast du noch etwas hinzuzufügen? Ja, mit dem nur anschließend, was Klaus schon gesagt hat. Es ist ein komplexes Projekt, unabhängig davon, in welcher Art und Weise die Migration stattfindet. Du hast es auch in deinen Timelines mehrmals angesprochen, Philipp, bis 2027 ist jetzt auch nicht mehr allzu lange.

Insofern haben Sie hier drei kompetente Ansprechpartner in dem Webinar, die Ihnen dabei helfen können, nämlich genau einen Plan zu erarbeiten, einen Zeitplan zu erarbeiten und den richtigen Ansatz und natürlich das richtige Tool, wo Klaus und ich ja klare Meinungen haben, entsprechend auch auszuwählen. Gut, vielen Dank. Dann würde ich vorschlagen, wir wechseln zu den Fragen und wir steigen im Endeffekt direkt ein mit der ersten Frage. Wird ein Big Bang oder ein gewisser Parallelbetrieb empfohlen?

Und Christian, das würde ich an dich weitergeben, weil du primär über die Migration und die Integration dort gesprochen hast. Genau. Und ich hatte auf einer meiner Folien ja stehen gehabt, dass letztendlich es zu vermeiden geht, auf der einen Seite natürlich irgendwo in einen Grad von regulatorischer Incompliance zu geraten, auf der anderen Seite den Geschäftsbetrieb auch zuzustören. Und insofern ist sicherlich hier auch wieder der richtige Ansatz wirklich essentiell, um genau diese beiden Punkte auch zu adressieren.

Ein Big Bang birgt natürlich immer ein großes Risiko, besonders für den Fall, dass es eben nicht funktioniert, denn es ist ein sehr großer Bang, der leider nicht viel hilft. Auf der anderen Seite eine stufenweise Migration ist eben auch nicht so ganz einfach. Und da muss man eben schauen, wie man vorgeht. Das lässt sich natürlich applikationsweise machen und ist sicherlich ein sicherer Ansatz an der Stelle, weil er eben das Risiko verteilt.

Man fängt an, genau wie bei einer IGA-Implementierung mit überschaubaren Applikationen, schaut, dass die Konfigurationen alle vernünftig übertragen worden sind, die Anbindung funktionieren. Insofern natürlich alleine aus einer Risikosicht ist meine Empfehlung der letzteres, sprich nicht der Big Bang-Ansatz, auch wenn man sicherlich einen klaren Cutover haben muss, wann welche IGA-Applikation für welche Zielanwendung entsprechend verantwortlich ist.

Super, vielen Dank. Klaus, auch deine Meinung würde ich dazu ganz gerne hören, denn ich finde gerade das eine sehr spannende Frage.

Ja, also aus meiner Sicht ist das Thema Big Bang vom Tisch. Das ist unrealistisch, aus meiner Sicht das zu machen, weil dafür hat man einfach zu viel investiert in Prozesse, in Abläufe, die jetzt in dem existierenden Tool umgesetzt sind. Und man muss alle Menschen abholen. Ein IRM-Programm rüttelt im Prinzip an allen Grundfesten im Unternehmen. Jeder Prozess sollte hinterfragt werden. Und ich muss alle Leute, wie man so schön sagt, abholen und mitnehmen, damit jeder auch versteht, was das jetzt eben bringen soll. Und das geht eigentlich nur mit einem sanften Übergang.

Das hat natürlich nichts damit zu tun, dass ich durchaus sagen kann, das was Christian, glaube ich, angesprochen hat, ich mache ab einem gewissen Punkt eine Frozen Zone, ich nenne das mal so. Also ich sage, ich lasse das alte Tool unberührt. Jetzt bitte nichts mehr Neues machen. Alles Neue kommt über das neue Tool. Aber ich kann aus dem alten Tool entweder noch Workflows mitnutzen oder Daten abziehen oder wie immer auch.

Das ist dann eine Frage, wie tatsächlich sich das Unternehmen darstellt, was da getan worden ist, dass ich diese Sachen machen kann und habe dann immer mehr, was ich mit dem neuen Tool mache. Und wenn diese Frozen Zone einmal eingerichtet habe, dann kann ich dann sehen, wie sich die neuen Dinge entwickeln und kann dann auch irgendwann mal, sage ich mal, nach zwei, drei Wochen einen Zeitpunkt ableiten, wo ich sage, jetzt ist vorauszusehen, in einem Dreivierteljahr oder in einem halben Jahr sind wir durch und können die alte Lösung endgültig abschalten.

Also ich denke, das ist die absolut angenehmste Situation, nimmt vor allen Dingen Druck aus dem Kessel, zu einer bestimmten Zeit fertig sein zu müssen. Und Druck hat im IAM-System noch nie zu guten Ergebnissen geführt, noch nie.

Ja, finde ich, sehe ich absolut genauso. Ich kann euch beiden nur zustimmen. Auch aus meiner Erfahrung heraus, meiner Implementierungserfahrung kann ich sagen, ich habe mehr Big Bang Projekte scheitern sehen als Parallelbetriebsprojekte, auch mit teilweise horrenden Zahlen, die da an Schaden entstanden sind. Also da kann ich mich absolut nur anschließen und freue mich, dass wir da auf derselben Meinung stehen. Ich denke also, die Frage haben wir einheitlich beantworten können. Ja. Nächste Frage.

Wie geht man in Migrationsprojekten üblicherweise mit historischen Daten um, also sprich mit Nachweisen? Christian, möchtest du diesmal wieder anfangen?

Ja, da erinnere ich mich wieder an meine Big Four-Zeiten zurück. Ein durchaus valides Thema. Es ist ein Thema, mit dem sich alle Kunden auseinandersetzen, weil natürlich die historischen Daten alleine schon aus einer regulatorischen Sicht, aus einer finanzregulatorischen Sicht sehr relevant sind.

Sprich, der Jahresabschlussprüfer schaut sich natürlich an, welche neuen Identitäten sind angelegt worden, welche Berechtigungen sind provisioniert worden. Unter dem Kontext der IT-General-Controls gibt es dafür Freigaben, gibt es dafür Anträge etc. Insofern sind die Daten super relevant. Das ist gar keine Frage. Ob ich mir jetzt den Aufwand mache, das alles zu migrieren, das ist auf der anderen Seite dann doch eine Frage. Und du hattest es vorhin so schön angesprochen, Klaus, mit der Frozen Zone.

Das ist letztendlich auch so ein bisschen die Hinleitung zu meinem Vorschlag für dieses Thema. Sicherlich will man nicht, dass das System nach wie vor weiterhin noch für zehn Jahre am Leben erhalten, frozen oder unfrozen. Aber es ist schon wichtig, sich genau darüber Gedanken zu machen. Aus meiner Sicht ist die Migration der historischen Daten dann nicht der richtige Weg, weil es einfach ein wahnsinniger Aufwand ist. Aber das Vorhalten der Daten ist natürlich umso essentieller. Und auch da kommen wieder so ein bisschen diese prüferischen Regeln.

Wenn ich sie vorhalte, wenn ich sie auch im System nicht vorhalte, muss ich mir natürlich Gedanken machen, wie ich sicherstelle, dass die Daten natürlich adäquat sind, vollständig sind, korrekt sind. Und das sind natürlich so wichtige Attribute, die den Prüfer nachher sehr interessieren. Und da muss ich natürlich auch eine entsprechende Dokumentation wieder vorhalten, dass beispielsweise der Export, den ich auch im System gemacht habe, auch zu dem passt, was vorher im System war.

Und insofern die kurze Antwort aus meiner Sicht, die Migration löst jetzt das nicht, sondern bereitet eigentlich mehr Arbeit als Nutzen. Okay, vielen Dank.

Klaus, möchtest du dann noch irgendwas hinzufügen? Ja, es gibt eine technische Ansicht dazu. Also es ist vollkommen richtig, was Christian gesagt hat. Migration von Audit-Daten macht normalerweise keinen Sinn, weil wir ja von unterschiedlichen Softwareprodukten reden, manchmal von völlig anderen Architekturen reden. Gerade wenn ich jetzt On-Prem zu Cloud vergleiche, da macht eine Migration gar keinen Sinn. Ich muss halt sicherstellen, dass mein Audit-Trail verfügbar ist, wenn der Auditor sehen will, auch für zehn Jahre verfügbar ist.

Ich muss sicherstellen, dass die Audit-Dateien ohne dieses Tool lesbar sind. Also es muss ein Report existieren oder sonst irgendetwas. Und wenn ich das Tool brauchen sollte dafür, muss ich sicher sein, dass ich das Tool auch noch zehn Jahre lang benutzen kann. Also in irgendeiner Form als virtuelle Appliance aufheben, dass ich dann sagen kann, hier kann ich meine Daten noch lesen. Das sind Dinge, die man auf jeden Fall vorher bedenken sollte.

Nicht, dass man irgendwann in die Situation kommt, wie beim Backup, das jeder hat, aber den Restore hat keiner getestet. Das sollte auf jeden Fall beachtet werden. Aber ansonsten würde ich auch von so einer Migration abraten. Das macht keinen Sinn. Vielen Dank. Nächste Frage. Ich springe mal ein bisschen in der Liste. Wie viele Migrationsprojekte mit SAP IDM haben Sie durchgeführt?

Christian, das gebe ich wahrscheinlich auch besser mal in deine Richtung. Ja, ich glaube, da haben wir sicherlich unterschiedliche Zahlen, die Klaus und ich liefern können. Wir haben einen relativ großen Kundenstamm im Bereich der Unternehmen, die SAP einsetzen.

IBM, einer der größten SAP-Integratoren der Welt eben auch. Insofern haben wir dementsprechend natürlich auch viele Kunden, die SAP IDM im Einsatz haben und die wir da auf der Reise auch begleiten. Sowohl hier im Deutschland, Österreich und Schweizerischen Markt als auch weltweit. Können wir gerne auch nochmal, wenn Interesse besteht, gerne auch nochmal anbieten für die Interessierten, die sich gerne vielleicht auch mit anderen Unternehmen zu diesem Thema nochmal austauschen würden. Dass auch da natürlich Möglichkeiten bestehen, wenn das gewünscht ist.

Klaus, ihr habt da sicherlich nochmal eine andere Sicht darauf. Ja, es ist halt sehr unterschiedlich. Bei uns kommt das oft über die GSE-Schiene, dass Kunden auf uns zukommen und sagen, uns ist SAP GSE zu teuer geworden, habt ihr nicht was anderes dafür? Oder wir haben gehört, ihr habt was anderes dafür. Und dann über unseren Armansatz, über diese Risikowertung kommen wir dann oftmals dazu, dass wir sagen, naja, aber das, was ihr da an IAM macht, das könnt ihr nur damit integrieren, wenn ihr mögt und könnt das ablösen, wenn das Sinn macht für euch.

Es gibt viele Anfragen dazu, aber ich denke mal, das Ergebnis der Umfrage zeigt ja, dass viele Leute dann auch noch durchaus daran kleben und sagen, ich würde gerne nochmal, das kenne ich halt. Es ist eher eine Frage, habe ich gerade einen Umbruch in der Firma, auch bei den Menschen, die mit SAP umgehen müssen oder die sich um die Maturity, einfach die IAM-Reifheit kümmern, dann haben wir eher die Bereitschaft, da was zu ändern. Ansonsten ist es eher ein Beharren aus dem, was man eben kennt. Es kommt halt niemand so gerne aus seiner Komfortzone raus.

Und das ist schon ein gewaltiger Schritt aus der Komfortzone raus, wenn ich mir ein anderes Tool angucke und auf einmal außer sapernesisch auch noch andere Sprachen sprechen können muss, wie zum Beispiel, ach, die haben auch Identitäten, die haben Accounts, die haben Entitlements, das kenne ich so gar nicht. Ja, wie gehen die denn damit um?

Also, Wording ist halt, ich sage mal, ein Drittel von jedem IAM-System, dass man da immer die richtigen Dinge auch meint und versteht. Also, das ist unsere Sache dazu. Gemacht haben wir da schon viel dazu, also nicht nur im SAP-Umfeld, sondern wir haben schon viele dieser pro-parentären Systeme abgelöst. Am Ende des Tages bauen wir dann auch auf die Partner-Erfahrung von der IBM, die uns dann nicht nur den rein technischen Ansatz, sondern auch den organisatorischen Ansatz liefert oder den prozessualen Ansatz, was dann natürlich gemeinsam einfach wirklich viel Benefit für den Kunden bringt.

Vielen Dank. Dann habe ich gleich noch eine Frage für dich, Klaus. Wie gemacht für dich, könnte man glatt sagen. Was macht SailPoint besser als die Konkurrenz? Da habe ich zwei Minuten für. Wie soll ich das machen?

Also, ich sage mal, ob wir wirklich die Sachen von den reinen Funktionen, ja, ich meine, die Funktionen, die wir hier haben, das hat natürlich alles eine gewisse Halbwertszeit. Was SailPoint sicherlich apart setzt von allen anderen Ventoren, ist das Team.

Ich meine, wir sind über 2.000 IAM-Enthusiasten, die nichts anderes im Kopf haben, als den Kunden erfolgreich zu machen. Also, dieses Team ist eigentlich das, was tatsächlich den Unterschied macht. Wir sind von unserer Denke immer vielleicht ein Stückchen weiter, weil wir treiben mit unseren Ideen, was wir denn wollen.

Also, wenn es um Innovation geht, haben wir meistens den Schritt ein bisschen vorne. AI, also richtige künstliche Intelligenz, keine fancy SQL-Statements, sondern wirklich künstliche Intelligenz. Es sei nur ein Maßstab davor, wobei wir eher immer von Machine Learning reden. Das nutzen wir schon recht häufig mit. Und das ist vielleicht der Unterschied. Aber ich würde halt im Prinzip sagen, wir sind immer ein Stück weit weiter, weil wir mit unseren Ideen, was wir denn machen könnten, oder wie man Dinge umsetzen sollte, den Markt immer ein bisschen vor uns her.

Im Grunde genommen immer wieder das Team hervorheben, weil das Team ist wirklich dafür gemacht, einfach IAM umzusetzen. Wir machen halt nichts anderes. Und das machen wir sehr erfolgreich.

Super, vielen Dank. Da hast du es doch in zwei Minuten erfolgreich geschafft, uns das näher zu bringen. Und damit machen wir im Endeffekt die Stunde auch schon voll. Wir haben zwar noch einige Fragen, leider nicht genügend Zeit, die jetzt alle zu beantworten. Ich habe mich bemüht, die spannendsten rauszusuchen. Vielen Dank, dass Sie zugeschaut haben heute. Vielen Dank, Christian. Vielen Dank, Klaus. Und dann wünsche ich noch einen schönen Abend. Dankeschön. Vielen Dank.