Hybride SAP-Systemlandschaften stellen viele Unternehmen vor Herausforderungen. Zwischen On-Premise-Lösungen wie SAP ERP HCM oder H4S4 und Cloud-Komponenten wie SAP SuccessFactors braucht es klare Architekturprinzipien, abgestimmte Integrationsstrategien und eine verlässliche Governance.
Enterprise Architecture liefert genau hierfür das methodische Fundament, als Brücke zwischen Business und IT, als Steuerungsinstrument und Katalysator für technologische Weiterentwicklung.
In dieser Folge sprechen p78 Managing Director Michael Scheffler und Dr. Michael Blaschke, Global IT Architect bei SAP, darüber, wie Unternehmen ihre SAP HCM Systemlandschaften zukunftssicher gestalten können.
Ergänzende Informationen zu dieser Episode:
Kontaktmöglichkeiten Dr. Michael Blaschke:
• LinkedIn Profile: https://www.linkedin.com/in/dr-michael-r-blaschke/
• SAP Profile: https://profile.sap.com/u/Michael_Blaschke
Podcasts von und mit Dr. Michael Blaschke:
• Podcast: Bitcoin, Fiat & Rock'n'Roll (BFRR)
• Podcast Episode: Why SAP Goes all in on Enterprise Architecture
Artikel & Webcasts
• Webcast Series: SAP's Four-Part Journey Through Architecting Modern SAP Landscapes
• Article: Clean Core as Foundation for Your Cloud Journey
• Article: Enterprise Architecture as a Leadership Factor
Das Interview zum Nachlesen
Michael Schaeffler
Hybride SAP Systemlandschaften stellen viele Unternehmen vor Herausforderungen.
Zwischen on-premise-Lösungen wie SAP ERP HCM oder H4S4 und Cloud-Komponenten wie SAP SuccessFactors braucht es klare Architekturprinzipien, abgestimmte Integration-Strategien und eine verlässliche Governance.
Enterprise Architecture liefert genau hierfür das methodische Fundament, als Brücke zwischen Business und IT, als Steuerungsinstrument und als Katalysator für technologische Weiterentwicklung.
In dieser Folge spreche ich mit Dr. Michael Blaschke Global IT-Architekt bei der SAP, darüber, wie Unternehmen ihre SAP-Hart-System-Landschaften mittels Enterprise-Architecture zukunftssicher gestalten können.
Damit herzlich willkommen zu dieser Folge von HIT Talk. Mein Name ist Michael Schaeffler.
Michael, schön, dass du heute zu Gast bei mir bist. Stell dich doch bitte unseren Hörern und Hörern kurz vor, was ist dein fachlicher Hintergrund und wie bist du zu dem Thema Enterprise-Architecture bei dem Software-Hersteller SAP gekommen?
Dr. Michael Blaschke:
Herzlichen Dank, Michael, für die Einladung zu meiner fachlichen Hintergrund studierter Informatiker, promovierter Wirtschaftsinformatiker auch im Thema IT-Architektur im speziellen Mittelware oder Integrationsarchitektur studiert. Sogar damals zum Thema SAP Cloud Plattform, das Vorgängerprodukt zur heutigen Business Technology-Plattform. Ja, also ich habe das Glück, exakt in dem Bereich arbeiten zu dürfen, indem ich auch promoviert wurde. Das passiert ja gar nicht mal so oft, dass man dann tatsächlich zu seinem Forschungsthemen auch arbeitet. Das empfinde ich als großes Glück. Aktuell habe ich die Rolle Enterprise Architect bei der SAP in einem globalen Team namens Enterprise Architecture and Advisory. Darüber sprechen wir wahrscheinlich später dann noch ein bisschen genauer. Ich bin jetzt wieder bei der SAP dabei, seit ca.
elf Monaten inzwischen. Ich war während meiner Promotion eben schon bei der SAP seinerzeit am Standort St. Gallen, weil die SAP seinerzeit mit der Universität St.
Gallen eine enge Kooperation hatte. Den Standort gibt es jetzt so nicht mehr.
Ich bin inzwischen im Zürcher Büro, aber eben, ich bin jetzt wieder zurück seit zehn Monaten und war dazwischen fünf Jahre in der Beratung bei Accenture & Carney.
ehemals AT-Carney unterwegs, wo ich auch immer mit Fokus auf IT-Strategie und in der Architektur unterwegs war.
Michael Scheffler:
Ja, wow, da hast du natürlich jetzt auch schon sehr viel Erfahrung auf dem Gebiet sammeln können und du hast es gerade angesprochen. Du bist in einer globalen Organisation bei der SAP angesiedelt. Das würde mich nochmal ein bisschen genauer interessieren. Was ist denn da euer Auftrag?
Dr. Michael Blaschke:
Dieses globale Team heißt „Enterprise Architecture and Advisory“. Es ist ein relativ junges Team mit zwei Aufträgen. Der erste ist kundenorientiert, also wirklich Customer Facing, Kunden bei ihren SAP-Modernisierungen zu helfen, natürlich aus Architekturperspektive.
Und ich kann dir sagen, wir sind echt gut ausgebucht. Die Kunden weltweit transformieren ihre SAP-Landschaften. Die SAP haben ja auch zu recht erkannt, dass Architektur an der Stelle zumindest ein Hebel ist, um diese Transformation voranzubringen, um die Komplexität einzufangen, um zu orchestrieren, um zu simplifizieren, um die Geschäftsorientierung, quasi den Kontakt zum Business zu halten und nicht nur quasi in der IT des jeweiligen Kunden unterwegs zu sein, denn SAP-Projekte sind keine IT-Projekte, es sind Unternehmensprojekte, wenn man so möchte.
Und das ist unser erster Auftrag und zwar im Speziellen für Premium Engagement Kunden. In meinem Fall sind es zwei Schweizer Kunden, bei denen ich gerade unterwegs bin und die mich quasi voll auslasten.
Kleiner Exkurs an der Stelle es ist generell hilfreich bei all den SAP Architekten immer zu fragen für welche Kunden der SAP sind sie unterwegs? Also wenn man so will ist der Kunde die führende Dimension bei der Frage, wo welche Architekten unterwegs sind.
ja in meinem Fall oder in unserem Fall sind es die Premium Engagement Kunden, also die in den Kunden mit Max Attention oder Active Attention Budgets, um zeitnah an SAP Experten zu kommen. Es gibt dann aber auch RISE-Kunden daraus, die quasi RISE with SAP als Format gewählt haben, um die Modernisierung zu S4HANA oder in die Cloud zu bewerkstelligen. Dann gibt es neue Kunden, die vielleicht noch von Pre-Sales Architekten begleitet werden mussten, überhaupt zu prüfen, ob und wie SAP-Lösungen in die Landschaft passen. Das sind dann die sogenannten Architecture Advisors. Als kleiner Exkurs immer die führende Dimension ist der Kunde, welcher Art von Architekt der SAP, wann beim Kunden aufliegt.
Der zweite Auftrag unseres Teams ist dann wirklich das Thema Enterprise Architecture intern und auch für die Partner groß zu machen, aufzubauen. Da sind die Stichwörter Ford Leadership und ein Beispiel ist jetzt letzte Woche unser Event in Berlin, wo dann teilweise unser Team, teilweise Kunden, teilweise Partner einfach ihre Forschungsergebnisse, ihre Dienstleistungen, ihre Meinungen auch präsentiert und diskutiert haben. Also extern Kunden und intern das Thema inhaltlich aufzubauen und zu treiben.
Michael Scheffler:
In dem Zusammenhang nehme ich persönlich dich gerade auch auf sämtlichen Kanälen wahr. Also insofern freue ich mich umso mehr, dass du heute bei mir zu Gast bist und dann können wir vielleicht auch gleich ins inhaltliche einsteigen, Michael. Und zwar, welche Rolle spielt deiner Meinung nach das Thema Enterprise Architecture gerade im HCM-Umfeld? Das ist ja unsere Domäne.
Da wollen wir heute etwas tiefer reingehen. Wie du weißt, befinden sich viele SAP-Anwenderunternehmen in einem umfassenden Transformationsprozess weg von den klassischen on-premise-basierten Lösungen wie etwa dem guten alten SAP ERP HCM hin zu der Go-Forward-Solution SAP SuccessFactors und somit so Cloud. Was kannst du dazu sagen?
Dr. Michael Blaschke:
Ja, auch da, wie in jeder Modernisierung oder generell in IT-Projekten, IT-Programmen,
ist Enterprise Architecture der strategische Kompass. Also auch für komplexe HCM-Modernisierungen.
Wenn viele Unternehmen meiner Erfahrung nach den Wechsel zu Success Factors als rein technisches Projekt betrachten, erlebe ich in der Praxis, dass ohne durchdachte Architekturprinzipien, dann kostspielige Architekturfragmente entstehen. Für mich ist die Kern-Herausforderung, in der orchestrierten Modernisierung.
Man kann quasi unorchestriert modernisieren. Man kann sich vorstellen, dass dann ein ganzes Orchester spielt ohne Dirigent und im Gegensatz dazu kann man orchestriert modernisieren. Ein Beispiel wäre ein Automobilzulieferer implementiert, SuccessFactors parallel zu seinen bestehenden HCM-System ohne aber zu klären, welches System die sogenannte single-source-of-truth, also die einzige und geltende Wahrheit für Personaldaten dann wird. Und das Resultat, bei dem spezifischen Fall, waren dann Datendiskrepanzen, die dann die operativen Prozesse in der HR-Steuerung bis Heute belasten. Enterprise Architecture fungiert hier dann wirklich als der strategische Orchestrierer oder Kompass oder Moderator sucht dir die Analogie heraus, die dir am besten gefällt zwischen Business Anforderungen und all den technischen Möglichkeiten, die es gibt. Architektur definiert das Target Operating Model, die sowohl da, einerseits die Mitarbeiter Experience, antizipiert verbessert, aber auch die technische Flexibilität für die zukünftige Innovation sicherstellt und technische Schuld reduziert. Das ist immer beides.
Michael Scheffler:
Das sehe ich absolut genauso. Ich bewege mich auch gerade in einem großen Kundenprojekt in der HealthCare-Branche und auch da ist die Aufgabenbestellung weg von dem klassischen ERP HCM-System hin zu den zukünftigen Lösungen der SAP. Und in dem Kontext redet man auch sehr viel über Enterprise-Architecture, da natürlich auch parallel die BTP auf diesem Weg benötigt wird, um zum Beispiel eine hybride Systemlandschaft hinzubekommen. Und ja, fachliche Anforderungen, Stichwort KI und co. aus dem Personalwesen müssen dann auch in eine entsprechende technische Umsetzung und die erforderlichen Komponenten und Artefakte münden. Also das Thema trifft uns natürlich auch in den ganzen HCM-Projekten und insofern kann ich dir dann nur zustimmen.
Allerdings... Michael, ist es so, dass das Thema Enterprise Architecture in vielen Bereichen, so meine Wahrnehmung, noch immer als IT-Thema wahrgenommen wird? Warum ist das Thema aus deiner Sicht gerade auch für HR-Verantwortliche und ja, HR/IT-Organisationen von strategischer Bedeutung?
Dr. Michael Blaschke:
Also der größte Irrtum ist eigentlich wirklich, EA als reinen IT-Disziplin zu verstehen. Auf eine Art kann ich es auch nachvollziehen, denn wenn man sich mal so TOGAF, also eins der Architektur Frameworks da draußen, in seinen ersten Versionen anschaut, dann wird man schnell merken, dass es einfach aus dem Infrastrukturmanagement kommt.
Also es waren die IT-Infrastruktur-Kollegen, die das quasi getrieben haben. Respektive, die ersten Versionen von Enterprise Architecture Arbeit waren halt sehr stark getrieben von: „Wir müssen den Server im Keller unseres Unternehmens besser managen.“
Daher kommt es. Aber es ist eben ein großer Irrtum, EA da nur als solch reine IT-Disziplin zu verstehen.
HR-Verantwortliche sind dann nämlich die eigentlichen Architekten der Mitarbeitererfahrungen, nicht nur der IT. Also im Zentrum muss dann schon stehen, wie der Mitarbeiter in der HR-Abteilung in letzter Instanz mit dieser IT seine Anforderungen abarbeitet oder wenn man möchte, welche Experience er als HR Mitarbeiter hat im Alltag. Das muss die Leitplanke oder das zentrale Ziel sein. Und genau hier liegt dann auch wirklich der Mehrwert von Enterprise Architecture.
EA, ermöglich es Ende zu Ende, Employee-Journeys oder Mitarbeiter-Journeys systematisch zu durchdenken. Denk da an ein Maschinenbauunternehmen, das wollte sein Performance Management im HR modernisieren, und ohne E.A. hätte man halt isoliert, Success Factors, Performance implementiert. Stattdessen hat sich der Maschinenbauer aber entschlossen, eine ganzheitlichere Sicht anzunehmen, und zwar von der Bewerbung über das Onboarding bis zur Nachfolgeplanung, die in jedem Schritt nicht nur sicherstellen, dass quasi das Feature in der Lösung läuft, sondern dass wirklich nachvollzogen wird, wie dieser Prozess Ende zu Ende idealerweise aussieht.
Und das Ergebnis war dann, dass HR hat erkannt, dass nicht nur die Technologie, sondern auch die Prozesse und die Organisationsstruktur neu gedacht werden mussten. Also es ging nicht nur darum, die IT muss laufen, das Tool ist implementiert und kann irgendwie verwendet werden, sondern es wurde auch der Prozess und die Organisationsstruktur neu gedacht. EA hat an der Stelle dann die Business Capability Maps geliefert, die HR-Prozesse mit Systemlandschaften verknüpft und so werden HR-Teams von Systemanwendern wirklich zu Gestaltern digitaler Arbeitsplätze und nicht nur zu Abnehmern von beliebigen HR-Anwendungen.
Michael Scheffler:
Mhm. In dem Zusammenhang stelle ich fest, dass ein sehr häufig unterschätztes Risiko in der Weiterentwicklung von HR/IT-Landschaften die, ich sage jetzt mal, technologische Schuld ist – ein Begriff, den du auch gerade verwendet hast, also veraltete Systeme, unzureichend dokumentierte Prozesse oder kurzfristige Architekturentscheidungen, die sich langfristig auswirken und zu erheblichen Einschränkungen bei Transformationsprojekten führen. Wie kann EA dabei helfen, solche technischen Schulden systematisch zu identifizieren, zu minimieren oder idealerweise gar nicht erst entstehen zu lassen?
Dr. Michael Blaschke:
Ja, also technische Schuld ist definitiv ein Kernarbeitsfeld von Enterprise Architecture. Also es ist auch ein Feld, mit dem es sich sehr leicht rechtfertigen lässt, warum man überhaupt Architekturarbeit machen soll. Weil technische Schuld verursacht einfach viele Kosten, das ist jedem Businessentscheider sehr eingängig, und deswegen bin ich auch froh um deine Frage, weil man hier jetzt quasi sofort ein Feld haben, mit dem wir den Wert unmittelbar unterstreichen können.
Und technische Schuld im HR-System ist besonders tückisch, weil sie dann oft erst bei Compliance Audits oder bei M&A Aktivitäten sichtbar wird. Also wenn im Rahmen von einer Akquisition eines Unternehmens dann auffällt, die HR-Prozesse der beiden Unternehmen laufen unterschiedlich und mindestens eines der beiden Unternehmen hat sich da eine ganz schöne technische Schuld aufgehäuft.
Ja, Enterprise Architecture bietet hier dann einen, wenn man so möchte, systematischen Diagnoseansatz, um diese technische Schuld zu identifizieren und dann auch abzubauen. Und ein bewährtes Vorgehen dafür umfasst Application-Portfolio-Assessments mit definierten Bewertungskriterien.
Ich mache wieder ein Beispiel. Ein Finanzdienstleister, den ich begleiten durfte, hatte über zweihundert Custom Reports im SAP HCM entwickelt, von denen 60 Prozent seit Jahren nicht mehr genutzt wurden. Parallel wurden noch Excel Workarounds für Funktionen verwendet, die das System eigentlich hätte standardmäßig abbilden können. Und EA etabliert hier jetzt eine kontinuierliche Architektur-Governance. Also jede System-Änderung wird gegen definierte Prinzipien geprüft. Architecture Decision Records dokumentieren Entscheidungslogiken dabei und die Entscheidung an sich. Also es wird dann festgehalten, das ist die Entscheidung und warum, und sie gilt für alle.
Und so entsteht dann keine neue technische Schuld mehr, während bestehende – wie in dem Beispiel, das ich gerade erläutert habe – dann auch sukzessive abgebaut werden.
Michael Scheffler:
Ja, sehr gutes Beispiel. Lass uns mal zum Thema hybride Systemlandschaften kommen. Und zwar ist das im HCM-Kontext quasi mehr oder weniger bei jedem Kunden zu finden.
Viele Unternehmen befinden sich eben auf diesem Weg in die Cloud, haben hybride Szenarien mit einer Kombination aus dem bekannten SAP HCM On-Premise oder vielleicht auch H4S4, also der Nachfolgelösung, in Verbindung mit SAP SuccessFactors in der Cloud – also Core-Hybrid-Modell beispielsweise im Betrieb.
So, wie lässt sich eine solche Systemlandschaft aus EA-Sicht optimal gestalten?
Du hast es ja jetzt hier schon an deinem Kundenbeispiel schön dargestellt, aber jetzt vielleicht noch mal ein bisschen mehr auf die HR-Welt übertragen. Welche Rolle spielt vor allem in diesem Zusammenhang die SAP Business Technology Plattform? Kannst du uns dazu was sagen, bitte?
Dr. Michael Blaschke:
Ja, so hybride HCM-Landschaften oder spezifische SAP-HCM-Landschaften fordern wirklich eine durchdachte Multi-Cloud-Architektur. Ein oft bewährtes Architektur-Pattern basiert auf, was wir funktionale Segmentierung nennen. Das bedeutet, dass Kern-HR-Prozesse, wie Payroll zum Beispiel, dann in H4S4 bleiben, während Employee-Experience oder Talent-Management dann auch gerne in SuccessFactors abgebildet werden können. Das ist kein Gesetz, das ist nur ein Architektur-Pattern. Das muss dann natürlich jedes Mal wieder aufs Neue geprüft werden. Aber das wäre jetzt, wenn man auf der grünen Wiese startet, ein Architektur-Pattern, das man sofort als Diskussionsgrundlage verwenden könnte.
Und die SAP Business Technology Plattform oder BTP funktioniert dabei dann als die Drehscheibe oder Orchestrierungsebene. Wieder um ein Kundenbeispiel zu nennen: Ein Energieunternehmen, das ich begleiten durfte, betreibt H4S4 für deutsche Standorte, SuccessFactors international, und über BTP haben wir dann die Integration, und zwar Event-Driven, implementiert. Das bedeutet, dass Stammdaten automatisch Updates in beiden Systemen triggern. Im Speziellen, die BTP Integration Suite bietet dafür dann das API-Management für externe Systeme, Prozessintegration für komplexere Workflows und Event-Mesh für nahezu Real-Time-Synchronisation. Und so entsteht dann so eine föderierte HR-Architektur, wenn man möchte, die das Beste beider Welten kombiniert, ohne aber wieder monolithische Abhängigkeiten zu schaffen – wie zum Beispiel in einem Automotor, bei dem, wenn man einen Teil rausnimmt, gar nichts mehr funktioniert.
Michael Scheffler:
Guter Vergleich. Ja, und genau auf die Integration Suite wollte ich hinaus. Welche typischen Herausforderungen siehst du denn da? Also klar, Integration Suite ist ein mächtiges Tool, aber auch hier gibt es Fallstricke – insbesondere mit SuccessFactors und On-Premise-Architekturen verknüpft. Welche Praxisbeispiele kennst du denn da so?
Dr. Michael Blaschke:
Die größten Stolpersteine an der Stelle liegen tatsächlich weniger in der Technologie.
Wir denken immer alle, die Technologie ist der Stolperstein, über den wir stolpern, oder die technologischen Puzzleteile sind die, die schwer zusammenzubringen sind.
Es sind immer noch veraltete Denkmuster und veraltete Governance-Modelle, die die IT-Projekte oder IT-Programme steuern.
Ein Beispiel ist, dass ein Teil der Kunden, die ich beobachtet habe, SuccessFactors wie ein weiteres On-Premise-System behandelt und so erstmal einführen möchte, was ja in meiner Sicht aber ein fundamentaler Fehler ist. Drei kritische Herausforderungen sind es dann aber, die dominieren. Also erstens die Identitäts- und Berechtigungsarchitektur: Ein Pharmaunternehmen hat monatelang mit Single Sign-On gekämpft, weil die bestehende Active-Directory-Struktur noch nicht bereit für die Cloud war.
Die Lösung war dann SAP Cloud Identity Services als Identity Provider. Ein Zweiter Stolperstein ist so Datenresidenz, also wo Daten, quasi dann residiert werden oder wo Daten dann gespeichert werden, und Compliance-Anforderungen, die cloud-native Ansätze limitieren. Und drittens die Release Governance. Also Cloud Updates kommen kontinuierlich oder fordern kontinuierliche Test- und Change-Prozesse und der Schlüssel zu all diesen Stolpersteinen liegt wirklich in der Entwicklung dieses viel zitierten Cloud-first Mindsets mit hybriden Backup-Strategien. Also ist es nach wie vor nicht so, dass alle Cloud-first denken und den veralteten Denkmustern und in den veralteten Governance-Modellen verweilen.
Michael Scheffler:
Jetzt haben wir viel über On-Premise-Architekturen gesprochen. Es ist ja so, dass H4S4, also SAP HCM S4HANA, existiert ja auch in einer Private Cloud Edition, kurz PCE. Das bietet SAP an und somit eine Möglichkeit, On-Premise-Lösungen in eine Managed-Cloud-Variante zu überführen. Das klingt zunächst nach einer technischen Hosting Entscheidung, aber hat natürlich auch weitreichende Auswirkungen auf die Gesamtarchitektur.
Wie schätzt du denn das PCE-Angebot aus Sicht der EA ein? Also welche strategischen Chancen und auch potenziellen Einschränkungen, die mag es wohl auch geben,
sind denn daraus abzuleiten und ergeben sich für die Anwender-Unternehmen.
Also das Ganze hat natürlich eine langfristige Komponente. Was sagst du dazu?
Dr. Michael Blaschke:
Ja, also aus der Perspektive eines Architekten ist die HCM Private Cloud Edition strategisch wirklich praktisch, wenn nicht sogar faszinierend, weil sie bietet Modernisierung ohne Disruption. Bürgt aber auch architektonische Fallen. Wir müssen beides jetzt beleuchten. Aber zuerst quasi zur Modernisierung und der Disruption: Aus meiner EA-Sicht betrachte ich die PCE als Brückentechnologie mit spezifischen Anwendungs-Szenarien. Die strategische Chance, von der ich jetzt gesprochen habe, illustriere ich nochmal mit einem Kunden-Beispiel: Ein Versicherungskonzern nutzt PCE für die schrittweise Cloud Transformation. Also komplexe Payroll-Logik bleibt unverändert erstmal, während neue Mitarbeiter-Dienste bereits in SuccessFactors entstehen. Und die Private Cloud Edition ermöglicht dann schon mal Cloud-native Integrationspatterns ohne jetzt Kernanpassungen wie diese komplexe Payroll-Logik gleich zu disruptieren und zu übersteuern mit dem Public Cloud Standard.
Kritische Einschränkungen bleiben aber, die Private Cloud Edition bleibt erst mal fundamental eine On-Premise-Architektur in Cloud-Infrastruktur. Also innovative Features, wie jetzt moderne Analytics oder User Experience Verbesserung bleiben damit schon begrenzt. Meine Architektenempfehlung ist dann, die Private Cloud Edition als Brückentechnologie einzusetzen, um den ersten Schritt in die Cloud zu machen, aber dabei nicht aufzuhören, sondern das ist nur die Brückentechnologie, um dann den Schritt in die Public Cloud sukzessive in den Jahren oder Monaten danach, je nach Ambitionslevel zu gehen.
Michael Scheffler:
Ja, vielen Dank. Dann lass uns mal ein bisschen über Governance und Organisation von EA in dem Unternehmen sprechen. Enterprise Architecture ist kein reines technisches Konzept, das hast du jetzt auch schon hervorgehoben. Sie muss auch organisatorisch verankert und gelebt werden, damit sie ihre volle Wirkung entfalten kann. Gerade im Zusammenspiel zwischen IT, HR und anderen Fachabteilungen stellt sich die Frage, wie ein EA-Team optimal aufgestellt sein sollte. Welche organisatorischen Modelle für den Aufbau und die Einbindung von EA-Teams haben sich aus deiner Sicht bewährt?
Dr. Michael Blaschke:
Es gibt ein Modell namens federated enterprise architecture, das sich für HR-Modernisierungen aus meiner Sicht als optimaler erwiesen hat, nämlich eine zentrale EA-Governance, zentrale und unternehmensweit, aber mit dezentralen Domänen-Experten. Und konkret empfiehlt sich dabei eine drei-ebenen Struktur, wenn man so möchte und jetzt wirklich spezifisch im HR-Modernisierungs-Kontext. Also da wäre erstens ein übergeordnetes EA-Board mit CIO, CHRO und Geschäftsführung durch strategische Richtungsentscheidungen. Ja, das ist dann auch die viel zitierte Design-Authority oder Governance-Board oder Architecture-Authority. Ja, da gibt es unterschiedliche Begrifflichkeiten, aber es ist wirklich so dieses übergeordnete EA-Board, in dem dann auch die oder der Personalverantwortliche, also der CHRO, wenn man so möchte, sitzt.
Dann gibt es eine HR Technology-Architecture-Group mit Business Partnern aus dem HR, Domänen-Architekten für HR und Prozessexperten für operative Entscheidungen. Und letztlich gibt es dann Embedded-Architects im Projektteam für die taktische Umsetzung. Die stehen dann quasi, diese Embedded-Architects sind dann wirklich im Projektalltag mit dabei und stellen halt sicher, dass die Ebenen darüber, also die Ebenen des übergeordneten EA-Boards, aber auch der HR-Technology-Architecture-Group, abgefangen werden. So eine Drei-Ebenen-Struktur würde ich jetzt quasi für HR Modernisierungen empfehlen.
Und interessanterweise habe ich bei einem Kunden mal beobachtet, dass er eine HR-Architektur-Community aufgebaut hat. Das ist dann weniger formal oder disziplinarisch, sondern einfach eine Community. Also freiwillig sind monatliche Sessions zwischen den HR-Experten und Enterprise-Architekten. Und das Ergebnis davon ist dann, dass die HR-Teams technische Einschränkungen verstehen, die IT-Teams durchdringen dann aber besser die Business-Logik. Das ist so ein niedrigschwelliger Ansatz, um diese HR/IT-Brücke zu überbrücken.
Dadurch entsteht dann so, was der Kunde den Business-IT-Bridge-Effekt genannt hat, tatsächlich auch manchmal durch gemeinsame Artefakte, also Business-Capability-Maps und Technologie Roadmaps, die sowohl HR-Gesichtspunkte als auch die benötigte IT-Roadmap oder IT-Evolution im Unternehmen berücksichtigt.
Michael Scheffler:
Wie groß war der Kunde ungefähr? So von der Mitarbeiteranzahl?
Dr. Michael Blaschke:
Das waren ca. dreitausend Mitarbeiter.
Michael Scheffler:
Okay, das ist nämlich auch immer sicherlich aus der Praxis heraus eine wichtige Fragestellung, welcher Aufwand mitschwingt, und das zeigt, dass auch, sage ich mal, also keine Großunternehmen, solche Dinge etablieren können. Gutes Beispiel.
Dr. Michael Blaschke:
Ja, übrigens an der Stelle ein kurzer Exkurs. Wir haben genau diese Beobachtung bei der deutschsprachigen Anwendergruppe, der DSAG, gemacht, die halt schon Mittelstands geprägt ist. Also es ist jetzt nicht so, dass da keine DAX-Repräsentanten und Kunden unterwegs sind. Aber im Wesentlichen ist es mittelstands-dominiert. Und das Feedback, das wir dort bekommen, ist, dass halt klassische Architekturansätze zu aufwendig, zu schwergewichtig und auch zu teuer sind. Ein Mittelständler kann sich vielleicht gar kein Chief Enterprise Architekt leisten, der mit einem Team dann TOGAF ausrollt und erst mal sechs Monate analysiert.
Und an der Stelle können auch leichtgewichtigere Ansätze im Sinne einer Minimum Viable Architecture gelebt werden. Und da starten wir gerade in dem Arbeitskreis bei der DSAG. Insofern für alle da draußen KMUs, die auch bei sich Architektur leichtgewichtiger ausrollen möchten, sei hier gerne die Hand ausgestreckt, sich dieser Arbeitsgruppe anzuschließen.
Michael Scheffler:
Michael, wie wichtig ist denn das Thema Governance? Auch das haben wir jetzt schon mehrfach gestriffen. Also zum Beispiel klare Verantwortlichkeiten und Entscheidungsprozesse zu etablieren, wenn es darum geht, unsere SAP-HCM-Systemlandschaften zu managen und zu steuern.
Dr. Michael Blaschke:
Also erst mal im Grundsatz: Governance ist das zentrale Nervensystem komplexer Landschaften allgemein und komplexer HCM-Landschaften im Speziellen. Wichtig ist dabei, dass diese Governance nicht mehr so gelebt wird, wie es bisher häufig der Fall wird, nämlich entweder als theoretischer Akademiker, der aus dem Elfenbeinturm heraus den HR-Kollegen erklärt, wie es läuft. Aber auch nicht als der Polizist, der quasi mit der Uniform durchs Unternehmen läuft und die Kollegen abmahnt.
Das sind alte Architektur-Arbeitsweisen, die einfach überholt sind. Wir müssen die coolen IT-Guys sein, mit denen die HR-Kollegen auch Lust haben, zusammenzuarbeiten.
Einfach als ein geschätzter Kollege am Tisch, als ein geschätzter Berater am Tisch, als Freund und Helfer, der einfach klar macht, dass wenn man heute ein bisschen schärfer, ein bisschen genauer überlegt, man sich hinten raus viel Kosten, technische Schuld und auch Nerven mit dem System spart.
Also, dass man so als grundsätzliche Worte zur Governance, ohne durchdachte Verantwortlichkeiten und Entscheidungsprozesse entstehen dann einfach teure, entsteht teures Architekturchaos und teilweise auch Entscheidungsparalyse, weil man es nicht mehr versteht. Da gibt es... bewährte RACI-Frameworks als niedrigschwelliger Ansatz, um ein bisschen Governance einzuführen. Also Responsible, Accountable, Consulted, Informed. Ja, es ist aus der SAP-Welt, glaube ich, relativ bekannt. Die SAP verwendet es noch gerne in RACI-Frameworks, ja, die da genutzt werden, als ersten Schritt, um Governance einzuführen.
Michael Scheffler:
Jetzt hattest du vorhin schon TOGAF als konkretes Framework kurz angerissen.
Was setzt du denn in deiner Praxis ein, um EA im SAP-Kontext methodisch zu verankern?
Dr. Michael Blaschke:
Ja genau, jetzt ist es ja erstmal so, dass ich aus einer Beratungszeit komme und momentan auch im Premium Engagement unterwegs bin, wo schon sehr individuell flexibel und... customised gearbeitet wird. Also ich gehe jetzt erstmal nicht zu einem Kunden und sage, hey, ich arbeite mit Lean-IX und wir machen jetzt alles mit Lean-IX. Also im Fokus steht die Kundenanfrage. Wenn die ist, wir müssen das Applikationsportfolio reduzieren, dann überlegen wir uns, mit welchen Tools kann man am besten das Applikationsportfolio reduzieren. Das heißt, das Tool, der Toolstack folgt dem Analysebedarf.
Ja, so viel mal vorne weg als Disclaimer. Mein Tool Stack jetzt kombiniert Enterprise Architecture Tools mit SAP spezifischen Analysen, Werkzeugen. Ja, da gibt es Lean-IX, aber ich hatte natürlich auch mit anderen schon hier gearbeitet.
Michael Scheffler:
Kannst du das vielleicht nochmal ganz kurz erläutern für die, die es nicht kennen?
Dr. Michael Blaschke:
Ja, bitte gerne. Also Lean-IX ist das Instrument der Wahl der SAP für Enterprise Architecture Management. Es ist ein Tool das sukzessive wächst. Natürlich das Kernfeature, mit dem es gestartet hat, war Business Capability Mapping. Aber es ist das zentrale Instrument für Architekturmodellierung. Interessant ist das Wort Lean in Lean-IX, denn Lean-IX hat sich bereits zur Ambition gemacht, Architekturarbeit schlanker zu machen als TOGAF, also dass man ein bisschen schlanker, also leichtgewichtigere Architekturartefakte generiert und eben nicht im Sinne von TOGAF oder den alten Modellen übermodelliert, dass es halt nutzlos wird und der Grenznutzen nach hinten abnimmt. Und Lean-IX ist einfach nur eine Komponente einer ganzen Toolchain bei der SAP, die weiter über Architektur hinaus die Modernisierungsprogramme möglich macht. Wir haben innerhalb unserer Business Transformation, Management, Unterstützung, eine Integrated Toolchain, in der noch mehr steckt: die Prozessanalyse mit Signavio oder Training mit SAP WalkMe, denn neue HR-Systeme müssen ja auch dann beim Endnutzer ankommen, dafür gäbe es zum Beispiel WalkMe. Also der Punkt ist Lean-IX ist nur Teil einer ganzen Integrated Toolchain, die letztlich im „Business-Transformation-Management“, so der Begriff der SAP, unterstützt.
Michael Scheffler:
Vielen Dank. Ich glaube, das hat geholfen. Zu WalkMe haben wir übrigens jetzt auch schon eine Folge hier in diesem Format gemacht. Da kann man mal reinhören, falls einem das Thema interessiert. Dann würde mich jetzt noch interessieren, Michael, um hier diesen Abschnitt langsam zu verlassen. Hast du ein konkretes Beispiel im Kopf, wo eine erfolgreiche Transformation anhand von EA auch wirklich geklappt hat und den entscheidenden Unterschied gemacht hat? Du hast schon einige Beispiele gebracht, aber ist da noch irgendwas im Hinterkopf geblieben?
Dr. Michael Blaschke:
Definitiv.
Da denke ich immer gerne an ein Logistikunternehmen, das sich in meiner Beraterzeit begleiten durfte, das vor der Herausforderung stand, fünfzehn verschiedene HR-Systeme nach einer Acquisitions Serie zu konsolidieren. M&A ist ein typisches Architektenumfeld.
Ich meine, du führst mindestens zwei Unternehmen zusammen oder X-Unternehmen und da muss aufgeräumt werden. Und ohne EA wäre dieses Projekt im absoluten System-Integrationschaos versunken. Und unser EA-Einsatz damals war, zunächst entwickeln wir den berühmten Nordstern, also die Target-Business-Architektur mit standardisierten HR-Fähigkeiten, über alle Unternehmen, die zusammengekauft wurden, hinweg.
Und dann mappten wir bestehende Systeme gegen diese Zielarchitektur und haben dabei natürlich Redundanzen und Gaps zwischen Ist und Soll definiert. Und das Ergebnis dieser Übung war dann statt fünfzehn HR Systemen entstanden drei spezialisierte Lösungen, nämlich H4S4 für Kern-HR-Prozesse, SuccessFactors für Talentmanagement, und eine branchenspezifische Workforce-Management-Lösung, auf die das Käuferunternehmen, also das Logistikunternehmen, einfach nicht verzichten wollte und konnte. Der entscheidende Unterschied dabei war jetzt, dass EA suboptimale Punkt-zu-Punkt-Integrationen verhindert hat und stattdessen eine modulare, erweiterbare Architektur geschaffen hat, weil mit BTP eine Datendrehscheibe, wenn man so möchte, oder eine Integrationsdrehscheibe oder eine Middleware eben zwischengeschaltet ist. Und das Projekt Ergebnis war dann wirklich vierzig Prozent reduzierte Betriebskosten und eine deutlich verbesserte Erfahrung der Mitarbeiter, die das HR-System oder die drei HR-Systeme genutzt haben, was dann echt zufriedenstellend war.
Michael Scheffler:
Klingt nach einem wirklich sehr komplexen Projekt. Man kennt das Thema mit den Konsolidierungen im HCM-Umfeld. So ein bisschen mit Blick auf die Uhr hätte ich jetzt noch zwei abschließende Fragen an dich, Michael. Und zwar als erstes würde mich interessieren, was kannst du denn jetzt Unternehmen, empfehlen, die heute noch ein klassisches SAP ERP HCM betreiben und vor der Entscheidung stehen H4S4 vs. SuccessFactors.
Die Nachfolgelösung, vielleicht in der besprochenen PCE-Edition oder eben die Transformation in die Cloud in Form von SuccessFactors. Wenn das ansteht, was würdest du hier aus Sicht eines Architekten mitgeben wollen?
Dr. Michael Blaschke:
Die Entscheidung H4S4 vs. Success Factor sollte aus meiner Sicht niemals Technologie getrieben erfolgen, sondern basierend auf einer fundierten Analyse der Business-Architektur. Es gibt ja inzwischen auch diesen relativ neuen Begriff der Business-Architektur, der dann halt einfach auf die Geschäftsarchitektur fokussiert. Enterprise-Architekten schauen sich ja beides eben an, nicht nur die Geschäftsprozesse und die Strategie, sondern eben auch die Integration, die Daten, die Applikation, die IT-Infrastruktur. Aber der Startpunkt muss eben die Analyse der Geschäftsarchitektur sein und nicht Technologie getrieben erfolgen. Und so der Entscheidungsrahmen oder die Kriterien, die man dann anwenden sollte, sind die eigentliche Geschäftskomplexität, regulatorische Anforderungen, der Innovationsappetit des jeweiligen Unternehmens und einfach auch der Reifegrad der IT im Unternehmen. Da denke ich jetzt an den Energieversorger, ich weiß gar nicht, ob ich ihn jetzt schon erwähnt hatte, der hat eine relativ komplexe Tariflandschaft gehabt . Der Komplexitätsdriver bei den Energieversorgern ist ja immer die Abrechnung, also die Tarife für die Strompreise. Und das ist ja nicht ein Tarif für alle, das ist eine Tariflandschaft. Und dann strenge Betriebsratsvereinbarungen. Ja, und die haben sich dann für H4S4 mit Success-Factors- Erweiterungen entschlossen. Und ein Tech-Startup dagegen hat halt voll SuccessFactors für maximale Agilität gewählt. Also mein Punkt ist, es muss Geschäftsgetrieben sein und man muss schon die Dimensionen oder Bewertungskriterien definieren gegen, wie man entscheidet. Und ich habe jetzt vier beispielhafte genannt, an die ich immer als erstes denke. Und ja, entscheiden ist dann die Definition der, wenn man so möchte, Hybridstrategie, also mit klaren Migrationspfaden. Also selbst bei H4S4 Entscheidungen sollten SuccessFactors-Piloten für die Mitarbeitererfahrung schon mal gestartet werden, weil so entstehen dann Lernkurven und Optionen für spätere Vollmigration. Und so eine coole Faustregel, also ich finde die halt cool, dass müsst ihr jetzt selbst entscheiden ob ihr das cool findet, ist aber: „Think Big, Start Small, Move Fast.“ Noch mal: „Think Big, Start Small, Move Fast.“, aber mit architektonischer Klarheit und Begleitung von Beginnern.
Michael Scheffler:
Danke dafür. Die werde ich auf jeden Fall mitnehmen für meine künftigen Projekte.
Und jetzt zu guter Letzt. Welche drei Empfehlungen würdest du einem CIO mit auf den Weg geben? die EA strategisch im Unternehmen verankern möchten.
Dr. Michael Blaschke:
Oh wow, das ist eine super Frage. Das ist die Grundfrage jedes Architekten. Da muss ich mir jetzt kurz sortieren, drei Stück. Also, ich fange mit der allerwichtigsten an. EA wirklich als Business Enabler zu positionieren. Also nicht als ein IT-Governance-Instrument, so wie sich TOGAF anfühlt, sondern... wirklich als einen Flüsterer, als einen Begleiter, als einen Vertrauten, mindestens eines Vorstands, wenn nicht sogar des gesamte Vorstands ist.
Also ich denke daran, dabei das Business-Capability-Maps, ein typisches Artefakt von Architekten dann wirklich gemeinsam mit Fachbereichen erarbeitet wird und konkrete Wertbeiträge einfach aufgezeigt werden.
Das zweite ist dann in Ja, in so EA-Community-Building zu investieren. Also informalere Instrumente, um EA zu leben. Da denke ich jetzt wieder an ein Pharma-Unternehmen, das sogenannte Architekturgilden etabliert hat. Also ein cooler Begriff. Klingt schon mal faszinierender als Arbeitskreis. Ja, und das waren einfach regelmäßige Austauschformate zwischen Architekten, verschiedenen Domänen im Unternehmen. Und ja, Wissen wird dann geteilt, Standards entstehen eher organisch und ja, Architektur wird zur gemeinsamen Sprache. Also Architektur-Gilden als ein Beispiel für Community-Building im Unternehmen, wenn es um EA geht.
Und drittens sehe ich dann eine entscheidungsgetriebene Architektur aufzubauen. Also wirklich eine Konzentration auf architekturrelevante Entscheidungen mit langfristiger Wirkung. Dabei denke ich eben an einen Kulturwechsel in der Architektur, weit weg von der brave Muster-Schüler, der fleißig seine TOGAF-Hausaufgaben macht und Sticker vom Chief Architekt einsammelt, dafür, dass er brav seine Hausaufgaben gemacht hat, sondern wirklich ein smarter Fuchs sozusagen, der... der die Entscheidungsträger quasi wirkungsvoll mit modernen Techniken wie Storytelling und Analogien dahingehend beeinflusst, dass einfach architekturrelevante Entscheide auf den Tisch kommen und die langfristigen Wirkungen transparent werden. Nicht jede Systemänderung im Unternehmen benötigt einen EA-Review, aber strategische Technologieentscheidungen müssen architektonisch begleitet und mit entschieden werden. Und so wird dann EA auch vom theoretischen Konzept zu einem ganz pragmatischen, unternehmerischen Steuerungsinstrument für digitale Transformation. Also zusammenfassend: Erstens, der Business Enabler, der nah am Business ist. Zweitens, mehr Community Building und über das Unternehmen hinaus, wie jetzt zum Beispiel von uns auch letzten Woche in Berlin auf dem SAP Enterprise Architekt Summit 2025. Das war unsere Form des Community Buildings. Und drittens dann entscheidungsorientierte Architektur, die auf Entscheidungen drängt und nicht nur brav die Hausaufgaben machen.
Michael Scheffler:
Perfekt.
Vielen Dank, Michael, für diese drei abschließenden Super-Empfehlungen. Ich bedanke mich für den ganzen Input. Sehr, sehr viel dabei gewesen heute. Und ja, ich hoffe, wir treffen uns demnächst auch mal persönlich. Du hast das letzte Wort.
Dr. Michael Blaschke:
Ja,
danke schön, Michael. Cool, dass du dem Thema IT-Architektur vor allem im HR-Umfeld eine Bühne gibst. Und wie gesagt, wer Appetit hat auf das Thema schlanke Architektur, Minimum Viable Architecture, der darf sich gerne bei mir melden. Die Kontaktpunkte oder Koordinaten finden sich in den Show-Notes.
