Bereits im letzten Jahr hat die SAP eine S/4HANA Cloud Extended Edition, Single Tenant Edition angekündigt und nun zusammen mit den Cloudpartnern RISE veröffentlicht – ein Angebot, um einen neuen Schub in die S/4HANA Transformation bei den Kunden zu bringen. Mit der Private Cloud erweitert SAP ihre Angebote für S/4HANA um ein im Gegensatz zu SAP HEC standardisiertes Cloud Modell mit einem neuen Betriebs- und Lizenzmodell. Das hört sich nach einem vielversprechenden Angebot an.

Schauen wir einmal genauer auf die aktuelle Lösung S/4HANA 2020. Neu ist schon einmal die Nutzung der Jahreszahl statt yymm im Namen der jährlichen Releases.

Mit S/4HANA 1511 startet 2015 die Neuentwicklung der SAP Business Suite in eine neue Ära. Die SAP verfolgt damit 3 strategische Ziele:

1. Cloud SaaS
2. Grundlegende Modernisierung des ERP Software-Stacks (HANA DB, FIORI, etc.)
3. Und beides natürlich unter kontinuierlicher Bereitstellung neuer Innovationen in Richtung digitaler und optimierter Prozesse sowie neuer Technologien

Diese drei Ziele und deren Implementierung in Einklang zu bringen, erfordert viele Einzelschritte. Mit S/4HANA im neuesten Release 2020 sind diese aber noch lange nicht abgeschlossen.

Die Cloud First Strategie hat für die SAP in ihrer finalen Umsetzung einen ganz klaren wirtschaftlichen und komplexitätsreduzierenden Nutzen. Lizenzen pro User und Monat (als eines der möglichen Lizenzmodelle) bieten einen kalkulierbaren und kontinuierlichen Zahlungseingang und durch die zentrale Bereitstellung der Software in der Cloud entfällt die parallele Wartung vieler verschiedener Softwarestände, womit heute noch tausende Entwickler beschäftigt sind. Zugekaufte Produkte wie Successfactors, Ariba, Concur etc. lassen sich zusätzlich verkaufen und mittels vorgefertigter Integration Packages über die SAP Cloud Plattform integrieren. Das funktioniert für viele Standardprozesse und zur Datenintegration, z.B. Partnerstammdaten synchron zu halten, recht gut. Für individuelle Integration mit Nicht-SAP-Produkten ist hier jedoch einiges an Arbeit zu leisten. Ob die Cloud Strategie in welcher Tiefe für den Kunden von Nutzen ist, ist eine der strategischen Fragestellungen jeder S/4HANA Einführung. Eingebettet ist diese Fragestellung in die grundlegende Enterprise Architektur, die strategische Fragestellungen zur Zielarchitektur von SAP und den umgebenden Anwendungen beantwortet. S/4HANA ist der Anlass für grundlegende Richtungsentscheidungen.

Die Modernisierung der ERP Plattform ist neben der Cloud überlebenswichtig für einen Softwarehersteller und diesen Weg geht die SAP sehr konsequent. Den Netweaver Stack gibt es nun praktisch komplett als Komponenten der SAP Cloud Platform und beides zusammen vermarktet SAP nun als SAP Business Technology Platform (BPT).

Die Modernisierung des ERP-Softwarestacks erfolgt neben der allgemeinen Cloud Readiness mit Schwerpunkt auf die SAP HANA In Memory Datenbank und das User Interface.

• Während im ERP noch eine Vielzahl redundanter Tabellen eingesetzt werden mussten, um bestimmte Operationen zu beschleunigen, sind diese in einer In Memory DB nicht mehr notwendig. Diese redundanten Tabellen finden sich in S/4HANA nicht mehr, entschlacken so Datenbank und Code und sorgen für ein „leichteres“ ERP. Allerdings erst im Endszenario: In der Übergangszeit muss ein eigenes Datenlayer dem ERP das alte Datenmodell vorgaukeln, damit noch nicht nach HANA migrierter Code weiter im sogenannten „Compatibility Mode“ lauffähig ist. Nach und nach kommen Komponenten hinzu, wie jüngst ein integriertes SAP CRM als Customer Management Modul und Ersatz für CS/SD und im nächsten Release auch das SAP HCM auf SAP HANA.
• Das User Interface ist die zweite Baustelle. Mit SAP FIORI 3 und digitalen Assistenten stehen interessante neue Technologien bereit, deren Entwicklung bereits einige Zeit vor S/4HANA und auf Kundendruck hin startete. Eine Software, die sich im „Responsive Design“ auf jedes Endgerät unterschiedlicher Größe anpasst und im Browser oder als App läuft, ist heute Standard, Spracheingabe und weitere intelligente Szenarien im Bereich Virtual Reality ebenso. Dennoch bleibt die SAP auch mit S/4HANA 2020 und der Umsetzung im Bereich SAP FIORI 3 hinter den Erwartungen der Kunden zurück. Immer noch ist es schwierig, für alle Benutzerrollen ein User Interface anzubieten, das auf jedem Endgerät läuft. Eine SAP GUI for HTML oder Webdynpro Anwendungen erwartet i.d.R. eine bestimmte Displaygröße. Diese noch immer vorherrschende Technologie versteckt sich mit leichter optischer Anpassung in der FIORI Apps library. Zwar lassen sich alle dort aufgeführten Apps im SAP FIORI Launchpad aufrufen, zeigen aber nach wie vor die Heterogenität der Software im User Interface sowohl im Look wie im Feel. So sind auch im neuesten Release 2020 von den Apps der FIORI Apps Library nur ca. 20 % echte neue HTML5 Apps mit responsivem Design dabei. Daran erkennt man, dass der Gestaltung der UX Strategie und der gezielten Differenzierung, welche User mit welchen Endgeräten und User Interfaces auszustatten ist, immer noch eine wichtige Aufgabe in jedem S/4HANA Projekt zukommt. Ein eigener Stream UX-Architektur&Design ist vonnöten und inzwischen bei unseren Kunden auch eine Projektrolle, die allgemein akzeptiert wird.
• Im Bereich Analytics bietet SAP nicht nur das durch die HANA DB embedded analytics, sondern eine Vielzahl von neuen Cloudprodukten für Analytics und Data Warehouse. Für Kunden, die eine lange Historie mit BW haben, ist dies ein paralleles Projekt, für andere vielleicht nur ein eigener Stream im S/4HANA Migrationsprojekt.

Ganz wesentlich für jedes neue Release sind neue Funktionalitäten. Diese müssen bewertet werden und zusammen mit den Änderungen, die durch die Umstellung auf die HANA DB in der sogenannten Simplification-List dokumentiert sind, funktional bewertet und bei einer Greenfield oder Brownfield-Umsetzung implementiert werden. Die SAP entwickelt alle Software inzwischen agil und im Cloud-First Ansatz. Vierteljährlich erscheinen neue Cloud-Releases und diese werden dann im einmal jährlich gebündelten Any-premise Release – so wie jetzt im S/4HANA 2020 – auf den Markt gebracht. Aber nicht nur die eigene Entwicklungsreihenfolge muss bei der Priorisierung der Anforderungen berücksichtig werden, sondern auch der Wunsch der Anwender. So hat die SAP jüngst das End of Life für die Business Suite 7 und weitere Produkte um 2 Jahre auf Ende 2027 verlängert. Auch wegen Corona sind die Kunden noch nicht so weit, wie SAP es gerne hätte. All diese Maßnahmen ermöglichen damit Kunden, die für sich wenig Nutzen aus den neuen Funktionalitäten sehen, ihre alten Systeme noch etwas länger zu behalten oder auch reine Conversion Projekte durchzuführen. Die meisten Kunden hingegen entscheiden sich für Greenfield Implementierungen, harmonisieren dabei Ihre IT-Landschaften und suchen gezielt nach funktionalen Verbesserungen. Wesentliche funktionale Neuerungen von 2020 finden sich in allen Bereichen und sind sehr gut beschrieben im Blog der SAP SAP S/4HANA 2020 Release | SAP Blogs. Diese zu bewerten, ist im Vorfeld jeder Einführung notwendig durch einen Mix aus Key Usern des Kunden und Industry Experts.

Die oben dargestellten Bereiche zeigen nur einige Aspekte, die es bei einem Umstieg auf S/4HANA zu berücksichtigen gilt. Nutzenpotentiale lassen sich daraus aus unserer Erfahrung praktisch für jeden Kunden erzielen. Ohnehin ist der Umstieg für SAP-Kunden nicht mehr eine Frage des ob, sondern nur des wann und wie und hier gibt es viele Optionen zu bewerten und strategische Fragestellungen zu beantworten wie z.B. bei der Auswahl des Implementierungspartners sowie im Bereich Projektmanagement und Enterprise Architektur.

Der Beitrag S/4HANA 2020 erschien zuerst auf ACENT AG.

Umstellungen des ERP Systems stellen ein komplexes Projekt mit erheblichen Kosten und personellen Aufwendungen für die Organisation dar. Dafür ist die Abwägung eines genauen Kosten-Nutzenverhältnisses unabdingbar.

Meine Erfahrungen als CIO, aber auch als Berater zeigen, dass die Voraussetzungen für ein Einführungsprojekt in den Konsequenzen oft nur unzureichend durchdacht werden. In welchen Bereichen ergibt sich der wesentliche Handlungsbedarf?

Geschäftsmodell, Organisation

Unterstützt das bestehende Geschäfts- und Organisationsmodell den angestrebten Nutzen einer ERP Umstellung? Die Erfahrung zeigt, dass standardisierte Abläufe keine Unschärfen in den Verantwortlichkeiten tolerieren. Hieraus ergibt sich typischerweise eine Diskussion über regionale versus Produkt-Verantwortlichkeiten.

Standardisierte Geschäftsprozesse

Geschäftsprozesse sind in der Regel in den Unternehmen nicht standardisiert. Selbst wenn die in den ERP Systemen hinterlegten Abläufe vereinheitlicht sind, ist die Handhabung doch unterschiedlich.

Stammdaten

Standardisierte Geschäftsprozesse setzen standardisierte Stammdaten voraus, d.h. single point of truth für Artikel, Dienstleistungen, Debitoren, Kreditoren, Kontenrahmen, Bewertungen etc.

Die Bearbeitung aller oben aufgeführten Punkte stiftet ihren Nutzen unabhängig von einer ERP Einführung. Sie ist aber auch Voraussetzung für eine Einführung, die den maximalen Nutzen aus den Standards und den state of the art Geschäftsprozessen ziehen will.

In der Praxis werden diese Themen zwar gesehen, aber in Anbetracht des Zeit- und Kostendrucks sowie organisatorischer Widerstände nicht konsequent umgesetzt. Das Ergebnis dieser Projekte ist zwar eine Umstellung des ERP Systems, aber das mögliche Nutzen-Potential wird nur bedingt erreicht.

Meine Empfehlungen:

1. Schaffen Sie klare Verantwortlichkeiten für Geschäftsfelder (Produkte, Dienstleistungen, regional, zentral, etc.).
2. Schaffen Sie klare Verantwortlichkeiten für das Stammdatenmanagement.
3. Benennen Sie Geschäftsprozess-Owner mit Kompetenz.
4. Gliedern Sie Ihr Projekt in zwei Teile:
   • einen businessgetriebenen Teil, der die o.g. Themen incl. des notwendigen Changemanagements umsetzt und in
   • einen IT getriebenen Teil, der sich um die technische Umsetzung kümmert wie Architektur, Cloud, technische Implementierung, etc.

Der Koordination dieser beiden Projektäste sollte durch eine Gesamtprojektleitung sichergestellt werden.

Das oben genannte Vorgehen hat sich in verschiedenen Projekten bewährt. Es setzt aber die Bereitschaft des Managements zu grundlegenden Veränderungen voraus.

Der Beitrag S/4HANA? Dann aber richtig … erschien zuerst auf ACENT AG.

Mit der Erfahrung aus vielen Projekten wird schnell herausgearbeitet, dass der Vorschlag einige offene Fragen nicht adressiert:

• In dem Vorschlag fehlt jegliche Würdigung der Ausgangssituation, der bestehenden SAP ERP Landschaft und der daran angeschlossenen weiteren Softwarelösungen – nicht zwingend vom gleichen Hersteller.
• Für die Umsetzung fehlt die Prüfung, ob alle neu definierten Prozesse zukünftig dann auch in einer HANA Umgebung ohne erneute Anpassung lauffähig sein werden.
• Die Kapazitäten auf Kundenseite, sowohl in den betroffenen Fachbereichen (im vorliegenden Fall Finanzen und Controlling) als auch in der IT, sind nicht geprüft: Sind die Kapazitäten überhaupt verfügbar? Kann das notwendige Wissen zeitnah aufgebaut werden?
• Ein neues Konzern Steuerungsmodell bedingt auch betriebswirtschaftliche Anpassungen, z.B. in der Art, wie Abschreibungen gehandhabt werden, die im Management Reporting Auswirkungen haben. Diese werden aber überhaupt nicht im Konzept betrachtet.

Es gibt noch weitere Punkte, die man anführen müsste, aber bereits diese Sammlung überzeugt das Management, eine alternative Vorgehensweise zu wählen. Hier kommt wieder SAP S/4HANA ins Spiel.

Als bestehender SAP ERP Nutzer entscheidet der Kunde, auch für die neuen Herausforderungen auf SAP Lösungen zu setzen, neben der bestehenden ERP Basis weitere, neue Produkte in der Cloud zu ergänzen (SAP Analytics Cloud) sowie erste Erfahrungen mit der neuen HANA Datenbank zu machen (mit BW on HANA).

Zusätzlich werden folgende Punkte adressiert:

• Um für zukünftige Projekte auf dem Weg zu SAP S/4HANA besser gerüstet zu sein, wird ein kleines Team von Prozess Managern eingestellt. Deren Aufgabe ist es, beim Kunden für eine durchgängige ‚End-to-End‘ Prozess Sicht zu sorgen und auch bereichsübergreifende Themen zu lösen. Gegebenenfalls platzieren sie auch organisatorische Anpassungen bei der Geschäftsführung.
• In einem betriebswirtschaftlichen Feinkonzept werden die Kundenanforderungen konkretisiert und an die bestehenden Standard Prozesse in der SAP ERP Umgebung und den neuen Produkten angepasst.
• Sowohl das Feinkonzept als auch die anschließende Umsetzung bzw. Realisierung werden am Markt getrennt ausgeschrieben und an unterschiedliche Partner vergeben.

Im Ergebnis führt die Begleitung dieses Projektes durch einen erfahrenen Partner zu merklichen Verbesserungen beim Kunden:

• Alle involvierten Fachbereiche und die IT sind im Projekt verankert und sind am Ende in der Lage, die neue Lösung zu betreiben und zu nutzen.
• Durch den Aufbau eines Prozess Managements, unterstützt durch die Geschäftsführung, kann der Kunde langfristig eine Transformation seiner Aufbauorganisation hin zu einer Prozess Organisation durchführen.
• Alle neuen Lösungen passen ohne erneute Anpassung zu der zukünftigen SAP S/4HANA Architektur.
• Ein Teil der Gesamtorganisation kann bereits ‚üben‘, wie man ein zukünftiges SAP S/4HANA Projekt angeht und umsetzt.
• Die IT ist vorbereitet und hat bereits Wissen rund um HANA aufgebaut.
• Die ursprünglich geplanten Kosten, in denen noch viele Aspekte unbeleuchtet bleiben, werden halbiert.

Fazit

Nicht jedes Projekt muss gleich mit SAP S/4HANA starten! In den meisten Firmensituationen ist es hilfreich, sich organisatorisch und inhaltlich bei allen neuen Projekten/Aktivitäten auf SAP S/4HANA vorzubereiten. In vielen Fällen wird durch die rechtzeitige Integration eines erfahrenen Beraters und dessen Neutralität gegenüber einer erarbeiteten Lösung die zukünftige Ausprägung optimal für den Kunden umgesetzt. In der Begleitung des gesamten Transformations-Prozesses kann die Implementierung für den Kunden optimal angepasst werden.

Der Beitrag Nicht jedes Projekt muss gleich mit SAP S/4HANA starten! erschien zuerst auf ACENT AG.

Die Umsetzung (Do)

Nach der Analyse geht es an die Umsetzung der Planung. Neben den üblichen Fachanforderungen sollten Sie ein paar Datenschutz-Anforderungen im Augen behalten, um nicht nachher im Tagesgeschäft Schwierigkeiten zu bekommen.

An erster Stelle steht dabei das Berechtigungskonzept in SAP. Da S/4HANA kein schlichtes Upgrade ist, sondern eine neue Technologie, scheinen Berechtigungen im ersten Blick gleich zu bleiben. Im zweiten Blick wird allerdings deutlich, dass sie technisch völlig anders aufgebaut sind. Ein gängiger Fehler ist es, die alten Rollen zu übernehmen und nur ein wenig anzupassen. Das führt dazu, dass die Berechtigungen im Projekt nicht ausreichend beachtet werden.

Da die Berechtigungen nicht mehr transaktional, sondern Serviceberechtigungen sind, kann man sie nicht mehr über die GUI-Oberfläche aufrufen, sondern ruft einen Frontend-Server auf. Der Frontend-Server hat die Verbindung zum Fiori Launchpad. Dieses nimmt die Anforderungen entgegen und stellt die Verbindung zum Backend her. Das Backend ist dann die eigentliche S/4HANA.

Ein häufiger Fehler ist, dass Unternehmen ihre alten Rollen in die S/4HANA zufügen und mit Sternchen versehen, damit alles läuft, anstatt neue Rollen hinzuzufügen. Ein weiterer Fallstrick besteht darin, dass höchstwahrscheinlich das „alte“ Berechtigungskonzept aus der Zeit vor der DSGVO existiert – ein weiterer Grund, unter Datenschutzgesichtspunkten das Berechtigungskonzept neu zu entwickeln und dessen Wirksamkeit zu überprüfen. Das neue Berechtigungskonzept ist ein wichtiger Baustein in der SAP-Sicherheit und darf nicht unterschätzt werden.

Sperren und Löschen im SAP

Die DSGVO schreibt vor, dass pbD* gelöscht werden müssen, wenn der Zweck der Erhebung entfallen ist. Es sei denn, die Daten unterliegen einer Aufbewahrungsfrist oder ein Löschen ist aus technischen Gründen nicht möglich. In diesen Fällen sind die Daten zu sperren.

Für das vorschriftsmäßige Sperren und Löschen der Daten werden im SAP-System die Archivierungs-Funktionen und das SAP ILM (Information Lifecycle Management) genutzt.

Dabei ist zu beachten, dass das

• Sperren der Bewegungsdaten nur via Datenarchivierung möglich ist.
• Sperren der Stammdaten über SAP-ILM-Reports nur bei abgeschlossenen Bewegungsdaten durchführbar ist.
• Löschen archivierter Daten sowie nicht archivierte / gesperrte Stammdaten mittels SAP ILM löschbar sind.

Pseudonymisierung und Verschlüsselung

Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und des Risikos für die betroffenen Personen und dessen Eintrittswahrscheinlichkeit sind nach Art. 32 DSGVO geeignete technische und organisatorische Maßnahmen zu treffen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Einen Vorschlag zur Erreichung eines angemessenen Schutzniveaus hat die Verordnung aber auch zu bieten: die Pseudonymisierung. Artikel 25 der EU-DSGVO beschreibt, dass die Pseudonymisierung vor allem hilft, den Datenschutzgrundsatz „Datenminimierung“ wirksam umzusetzen und somit die Rechte der betroffenen Personen zu schützen. Die gute Nachricht: Pseudonymisierung eignet sich hervorragend, um Risiken wie Insider-Bedrohungen oder die Auswirkungen von Datenabflüssen sowie unerlaubten Zugriffen und Einsichtnahmen zu reduzieren – egal ob es sich um personenbezogene oder andere sensible Unternehmensdaten handelt. Hier sollte man frühzeitig im Planungs- und Entwicklungsprozess prüfen, an welchen Stellen eine Pseudonymisierung möglich ist.

Bei der Verschlüsselung sind im Projekt die unterschiedlichen Verschlüsselungsebenen und -möglichkeiten zu untersuchen. Von der Verschlüsselung auf Betriebssystem-Ebene, über die Verschlüsselung der Datenbank-Inhalte bis hin zu einer Verschlüsselung auf Applikationsebene oder einer benutzer- / rollenabhängigen Verschlüsselung.

Verfügbarkeit und Belastbarkeit

Dies betont die DSGVO ausdrücklich. Belastbarkeit (Resilienz) bedeutet in diesem Zusammenhang die Widerstandsfähigkeit der IT-Systeme im Fehlerfall, bei Störungen, bei hoher Beanspruchung.

Mangelnde Belastbarkeit der IT-Systeme wirkt sich indirekt auch auf die Verfügbarkeit der Daten aus.

Der Check (Prüfung)

Beim Check der IT-Security sind die umgesetzten Regeln, die vergebenen Berechtigungen und neuen DSGVO Prozesse regelmäßig zu prüfen und idealerweise in einem Datenschutzbericht zum Nachweis des Datenschutzmanagements zu dokumentieren.

Weitere Bereiche, die aus Datenschutzsicht einer regelmäßigen Prüfung und Awareness unterliegen sollten, sind:

• SAP-System Konfiguration
• Schnittstellensicherheit
• Patchmanagement
• Logging
• Faktor Mensch

Gerade letzterer Punkt sollte mit regelmäßigen Datenschutz- und Security-Schulungen unterstützt werden.

Aus Datenschutzsicht sind ebenfalls die Prozesse für Auskunfts-, Widerspruchs- und Korrekturrechte der Betroffenen frühzeitig zu prüfen. Denn hier gibt es für die Betroffenenrechte Zeit- und Formvorschriften in der DSGVO, wonach vollständig und richtig beantwortet werden muss. Ansonsten drohen Bußgelder bis 20. Mio. € oder 4 % des Jahres-Weltumsatzes der Unternehmensgruppe wegen Missachtung der Rechte der betroffenen Person.

Ein Augenmerk sollte auf das Auskunftsrecht gelegt werden, insbesondere wenn die betroffene Person eine elektronische Kopie ihrer Daten wünscht. Hier muss unterschieden werden, was muss und was kann beauskunftet werden und was unterliegt dem Geschäftsgeheimnis.

Act (Erkenntnisse in Verbesserungen umsetzen)

Erkannte Schwachstellen oder neue Anforderungen sind im ACT-Zyklus mit konkreten Maßnahmen zu hinterlegen. Danach wird mit diesen Erkenntnissen der Zyklus mit der Planung neu gestartet und anschließend im DO-Zyklus im System umgesetzt.

Fazit

Nicht nur wegen drohender hoher, abschreckender Sanktionen, sondern auch wegen möglicher Reputationsschäden, sollten Unternehmen frühzeitig die Anforderungen des Datenschutzes im HANA-Projekt berücksichtigen. Denn… „Vor-Sicht ist günstiger als Nach-Sicht“.

Anmerkung:

• *pbD = personenbezogene Daten

Der Beitrag DSGVO in SAP S/4HANA Projekten erschien zuerst auf ACENT AG.

Die Vorbereitung auf die neuen Datenschutzregeln ist für Unternehmen eine Chance, ihren Umgang mit sensiblen Daten zu überprüfen. Durch die immer stärkere Vernetzung und die Verlagerung von „Datenschätzen“ in die Cloud, wie es bei HANA der Fall ist, sind Unternehmensdaten wachsenden Gefahren durch Cyberkriminalität ausgesetzt. Neben dem gesetzlich geforderten Schutz personenbezogener Daten müssen Unternehmen auch ihre sensiblen Unternehmensdaten vor unberechtigtem Zugriff schützen.

Entwickeln Sie vor Beginn der Migration auf S/4HANA ein umfassendes Sicherheits- und Datenschutzkonzept für die Berechtigungen der User und den Datenschutz in Ihrer S/4HANA Landschaft und den angrenzenden Systemen. Denn Datenschutz ist kein Projekt, sondern ein gelebter Prozess, der ständigen Änderungen unterliegt.

Das Datenschutzkonzept sollte u.a. einen dynamischen Prozess nach dem klassischen Plan-Do-Check-Act abbilden. Vorher ist allerdings die entscheidende Frage zu stellen und zu klären:

„Wo in meinem SAP-System befinden sich welche personenbezogenen Daten?“

Sind diese transparent und dokumentiert, ist der P-D-C-A-Zyklus gestartet. Weitere wesentliche Punkte sind generisch in der folgenden Grafik dargestellt.

Frühzeitig in der Planung sind die Grundsätze des Data Protection by Design and Default zu beachten:

• Data Protection by Design bedeutet dabei nichts anderes, als in der Planung darauf zu achten, dass nur die pbD* erhoben und gespeichert werden, die unbedingt erforderlich sind (Datensparsamkeit).
• Data Protection by Default bedeutet für das Customizing, eine nutzerfreundliche Voreinstellung so vorzunehmen, dass die Standard-Usability datenschutzkonform konfiguriert ist.

Zugriffsberechtigungen erlauben Benutzern, Objekte zu schreiben, anzuzeigen, zu ändern oder zu löschen. Dies ist bei Zugriff auf pbD* streng zu reglementieren. Denn aus Datenschutzsicht darf ein User nur aufgrund seiner Aufgabe oder Rolle im Unternehmen pbD* schreiben oder darauf zugreifen, lesen und/oder verändern oder löschen. Zusätzlich muss dies auf Grund der Rechenschaftspflicht in der DSGVO nachträglich nachgewiesen werden können.

Somit ist auf das Berechtigungskonzept unter Datenschutzgesichtspunkten ein wesentliches Augenmerk zu richten, neben dem sowieso zu berücksichtigenden 4-Augen-Prinzip in einigen Prozessen. Hierzu mehr im zweiten Teil dieses Blogs.

PbD* in Testumgebung

Zum Testen benötigt man praxisnahe Daten. Dabei sollten pbD* für die verschiedenen Testphasen synthetisch erzeugt oder anonymisiert werden. In dem Fall ist man aus der DSGVO raus und das Testen wird deutlich einfacher. Lässt sich dies partout nicht umgehen, ist das gleiche, strenge Berechtigungskonzept wie für die Produktionsumgebung anzuwenden.

Das Löschkonzept

Die Unternehmen, die HANA bereits eingeführt haben, beklagen einen erheblichen Aufwand, um SAP S/4HANA für die DSGVO fit zu machen. Dies betrifft zu einem wesentlichen Teil die Anforderung der DSGVO, pbD*, deren Erhebungszweck entfallen ist und die keiner Aufbewahrungspflicht aufgrund anderer Gesetze unterliegen, zu löschen oder zumindest zu sperren. Es ist offenbar nicht einfach und mit einem gewissen Aufwand verbunden. Viele Unternehmen sahen sich gezwungen, in ergänzende Produkte zu investieren, um die gesetzlichen Anforderungen zu erfüllen.

Insbesondere das „SAP NetWeaver Information Lifecycle Management“ (ILM) stellt dabei aus DSAG-Sicht eine wichtige Komponente dar. Ohne dieses Werkzeug sei die Umsetzung der Datenschutzvorgaben nur mit hohem Zusatzaufwand machbar. Das ILM wird unter anderem zum Sperren und Löschen von personenbezogenen Daten benötigt.

Fazit

Nicht nur wegen drohender hoher, abschreckender Sanktionen, sondern auch wegen möglicher Reputationsschäden sollten Unternehmen frühzeitig die Anforderungen des Datenschutzes im HANA-Projekt berücksichtigen. „Vor-Sicht ist günstiger als Nach-Sicht“.

Der zweite, folgende Teil zum Thema DSGVO in SAP S/4HANA Projekten beschäftigt sich mit der Umsetzung (Do), der regelmäßigen Kontrolle (Check) sowie der Umsetzung der Erkenntnisss in geeignete Maßnahmen (Act).

Anmerkung:

• *pbD = personenbezogene Daten

Der Beitrag DSGVO in SAP S/4HANA Projekten erschien zuerst auf ACENT AG.

Scoping-Vorprojekt

Es empfiehlt sich, ein Scoping-Vorprojekt mit den Fachbereichen durchzuführen – noch vor den Aktivitäten des SAP-Movement-Programms, mit dem der Kunde gemeinsam mit SAP oder einem Implementierer Wege zu S/4HANA und mögliche Realisierungen analysiert.

Im Vorprojekt sind unter anderem die folgenden Fragen zu beantworten:

• Geschäftsprozesse
  Wie ist der Automatisierungsgrad der administrativen Geschäftsprozesse? Gibt es KPIs, z.B. Mitarbeiterminuten je Vorgang, …  Wie viele Mitarbeiter (FTEs) arbeiten eher transaktionale Routinevorgänge ab? Wie ist die derzeitige IT-Unterstützung? Wie ist die Integration von administrativen und anderen Geschäftsprozessen (Produktion, Marketing, …)? Ist die Governance der IT eher zentral oder dezentral geprägt? Soll dies so beibehalten werden?
• Historische Daten
  Wie stehen die historischen Daten zur Verfügung? Wie relevant sind sie für die verschiedenen Fachbereiche?
• Mitarbeiter
  Wie viele Mitarbeiter-FTEs aus betroffenen Fachbereichen und IT stehen zur Verfügung? Wie ist der Ausbildungsstand bezüglich der für die Transformation notwendigen Themen?
• Veränderungen des Markts
  Ist mit disruptiven Veränderungen des Marktes z.B. durch neue Mitbewerber und/oder neue Technologien zu rechnen? Ist die Einführung neuer Geschäftsfelder geplant?
• Lizenzen
  Wie ist die derzeitige Lizenzstrategie? Gibt es bereits Überlegungen / Festlegungen zur zukünftigen Lizenzstrategie?
• Enterprise Architecture
  Wie integriert / harmonisiert ist die derzeitige IT-Landschaft? Gibt es Subsysteme – lokal oder funktional, die in der Vergangenheit häufig Probleme bereitet haben? Gibt es Legacy-Systeme, deren Bedienung altgediente Programmierer/Administratoren erfordert? Welche Funktionen werden zukünftig innerhalb und welche außerhalb von SAP abgebildet?
• Zeit- und Budgetplanung
  In welchen Zeitraum und mit welchem Budget soll die S/4HANA Migration realisiert werden? Welche internen und externen Ressourcen werden dazu benötigt? Wie soll die Projektorganisation aussehen?

Durchführung des eigentlichen S/4HANA-Projekts

Für den Kern des eigentlichen SAP-Projekts schlägt SAP eine Activate genannte Projektmethodik vor. Sie geht in sechs Schritten vor, der Vollständigkeit halber seien sie hier genannt: Discover, Prepare, Explore, Realize, Deploy, Run. Unternehmen, die eine S/4HANA-Einführung planen, sollten sich mit der Methode und ihrer Einbindung in unternehmensspezifische Projektmethodiken vorab vertraut machen.

Ein wichtiger Bestandteil von Activate – nebst Empfehlungen für die Vorgehensweise im Projekt – sind die sogenannten best practices: Für alle Geschäftsprozesse, die mit S/4HANA durchgeführt werden, schlägt SAP einen Standard vor. Im Laufe des Projekts wird analysiert, an welcher Stelle bestehende Geschäftsprozesse durch den Standard abgebildet werden können und an welcher Stelle Anpassungen vorgenommen werden müssen. Nachgerade banal zu schreiben: je mehr der Standard zum Tragen kommt, umso geringer die Kosten für Bau und Betrieb des Systems.

Von herausragender Bedeutung ist die erste Phase, Discover, in der die Unternehmung ihre Ziele und grundlegend den Weg dorthin definiert. Wiederum für den SAP-Teil bietet SAP allen Kunden mit Enterprise-Support kostenfrei das sogenannte Movement-Programm an: Mit verschiedenen Tools kann der SAP-ERP-Kunde sein(e) Bestandssysteme(e) auf S/4HANA-Fähigkeit untersuchen, Vorschläge für die Optimierung der kaufmännischen Fachbereiche sowie eine grobe Übersicht über Aufwände und die Projektlaufzeit aus Sicht der SAP erhalten.

Transition Paths

Ihr S/4HANA-System können Sie auf verschiedenen Wegen, sogenannten Transition Paths, einrichten. Der geneigte Leser mag bereits die Begriffe Greenfield, Brownfield oder andere Bezeichnungen aus dem Farbspektrum gehört bzw. gelesen haben. Im Wesentlichen bedeutet ja Greenfield „wir bauen ein neues System von Grund auf“ und Brownfield „wir migrieren die Bestandssysteme in das Zielsystem“.

Etwas detaillierter dargestellt: der Greenfield-Ansatz, im SAP-Sprachgebrauch New Implementation, wird in den oben genannten drei Ausprägungen angeboten, namentlich Any Premises, Cloud Essential Edition und Cloud Extended Edition. Im Brownfield-Ansatz gibt es zum einen die System Conversion, bei der ein System migriert wird, und die Landscape Transformation, in der mehrere Systeme, ggf. auch Schritt für Schritt, transformiert werden. Der Brownfield-Ansatz kann nicht gewählt werden, wenn das Zielsystem eine S/4HANA-Cloud-Lösung Essential oder Extended Edition ist – für diese Zielarchitektur ist immer der Weg über eine New Implementation vorgegeben.

Die folgende Tabelle fasst die im Blog vorgestellten Transition Paths und S/4HANA Zielarchitekturen zusammen:

Es gibt also, wie so häufig, viele Wege nach Rom. Den am besten geeigneten Weg zu identifizieren, ist eine Aufgabe, die die Verantwortlichen möglichst frühzeitig erledigen sollten.

Last but not Least

Nach mehreren aktuellen Studien verhalten sich viele Unternehmen noch abwartend. Ein Blogbeitrag, der im Juni 2020 veröffentlicht wird, muss ja nachgerade einen Hinweis auf CORONA enthalten, hier ist er: seit März wurden viele IT-Einführungsprojekte auf „on hold“ gesetzt, einige gar ganz gestrichen. Wir hoffen, dass etwa nach den Sommerferien „unser Land wieder angeworfen wird“, um die Werbung eines Kfz-Herstellers zu zitieren; dann sollte in vielen Projekten der Faden wieder aufgenommen werden. Wir empfehlen, mit dem Beginn der Überlegungen bzw. dem Fortführen der Vorbereitungen nicht zu lange abzuwarten: zumindest im Rahmen einer Voranalyse ist ein Scoping mit recht geringem Aufwand durchführbar, und es gibt frühzeitig wertvolle Erkenntnisse für die Definition Ihrer Strategie für die Digitale Transformation. Legen Sie los!

Hinweise:

• ACENT nutzt aus Gründen der besseren Lesbarkeit bei Personenbezeichnungen ausschließlich die männliche Form. Sie gilt im Sinne der Gleichbehandlung grundsätzlich für alle Geschlechter und stellt keine Wertung dar.
• SAP S/4HANA ist eingetragenes Markenzeichen der SAP SE.

Der Beitrag Erfahrungen mit SAP S/4HANA erschien zuerst auf ACENT AG.

Die Anwendung S/4HANA wurde vor fünf Jahren ins Leben gerufen. Schon seit fast zehn Jahren gibt es den Namen HANA (ursprünglich für High Performance Analytic Appliance) für die darunterliegende Datenbank. SAP sagt recht unbescheiden, mit S/4HANA sei „the intelligent enterprise“ möglich. (Anmerkung: An Anglizismen im SAP-Universum haben wir uns gewöhnt, auch dieser Blog-Beitrag wird keine Übersetzungsversuche unternehmen.) Im Kern bietet S/4HANA die performante Verarbeitung und Analyse erheblich größerer Datenmengen als im bisherigen System möglich, mehr Informationen in Realtime, vereinfachte Simulationsmöglichkeiten, einfachere Bedienungsoberflächen und die Möglichkeit, auf das eine oder andere Vorsystem oder Umsystem, das im Wesentlichen aus Performancegründen eingerichtet wurde, zu verzichten. Dem uralten Menschheitstraum von der Single Source of Truth kommt Ihr Unternehmen mit S/4HANA ein gutes Stück näher. Dies wird ermöglicht durch die Architektur der unter S/4HANA liegenden Datenbank (die nicht Gegenstand dieses Beitrags ist) und das auf die Architektur ausgerichtete Neuschreiben der Applikation S/4HANA.

Das Minimalziel,

das eine Unternehmung mit der Einführung von S/4HANA erreicht, ist das Ersetzen des bisherigen SAP-ERP-Systems durch ein System, das – man beachte! – im Wesentlichen einen gleichartigen Umfang beinhaltet. Man findet nicht mehr unbedingt die vertrauten Modulnamen wie FO, CO, MM und SD. Viele grundlegende Transaktionen hingegen (Buchung einer Eingangsrechnung, Buchung eines Warenausgangs, …) sind dem Wesen nach gleichgeblieben – manchmal in neuem Gewand. Sogar dieses Minimalziel ist jedoch bereits eine Transformation, die tief in die Prozesslandschaft der Unternehmung eingreift: durch die neue Technologie wird eine neue zentrale Tabelle der Datenbank, die den „eingängigen“ Namen ACDOCA trägt, in Echtzeit aktualisiert. In dem Moment, in dem die ebengenannten Beispiele (Eingangsrechnung, Warenausgang) gebucht sind, steht die Information allen Modulen, allen Transaktionen und Auswertungen sofort zur Verfügung. Damit fallen einige Transaktionen zwischen Modulen weg, andere Prozesse werden verschlankt oder beschleunigt.

Weitergehende Ziele

Jedes SAP nutzende Unternehmen legt selbst fest, welche Geschäftsprozesse in die Digitale Transformation aufgenommen werden sollen – und welche Produkte und Technologien zum Einsatz kommen sollen. Im Umfeld von S/4HANA bietet SAP entsprechende, die Funktionen erweiternde Systeme an, die in der Regel durch Zukäufe ihren Weg in das SAP-Universum gefunden haben und in die Gesamtarchitektur integriert werden. Bekannte Beispiele sind Successfactors, Ariba und C/4HANA. Der SAP-Kunde muss evaluieren, ob er SAP-Produkte oder Produkte alternativer Anbieter einsetzt. Die Nutzung neuer Technologien wie Artificial Intelligence, Machine Learning oder Robotic Process Automation ermöglicht an vielen Stellen das Verschlanken und die Beschleunigung der Prozesse. Auch bezüglich dieser Technologien muss das Unternehmen evaluieren, welche Technologien für welche Geschäftsprozesse erfolgreich eingesetzt werden können. Ebenso das Erstellen eines optimierten Zeit- und Ablaufplans ist von entscheidender Bedeutung: Welche Transformationsgeschwindigkeit kann das Unternehmen bewältigen? Welche Ressourcen können für die Transformation freigemacht werden?

IT-Architektur: S/4HANA als Software as a Service oder als Produkt

Eine wesentliche Entscheidung, die das Unternehmen bei der Einführung von S/4HANA treffen muss, ist die Frage, ob das System in der Form Software as a Service oder als Produkt erstellt und betrieben werden soll.

S/4HANA als Produkt: dies ist sicher eine Struktur, die der Ist-Situation am Nächsten kommt. S/4HANA wird einmal im Jahr funktional aktualisiert; es ist im Entscheidungsbereich des Kunden, wie häufig er auf die neue S/4HANA-Version umsteigt. Die aktuelle Version ist 1909, eingeführt im September 2019; es steht zu vermuten, dass im September 2020 die nächste Version, 2009, eingeführt wird. Der Kunde ist eher frei, Anpassungen und Erweiterungen vorzunehmen (möglichst nicht am Code von S/4HANA selbst). Das Produkt S/4HANA wird von SAP als „AnyPremise“ vermarktet; der Kunde hat die Wahl, das System im eigenen Rechenzentrum (On Prem) zu betreiben, im Outsourcing oder bei einem Hyperscaler (Azure, AWS, …); es besteht auch die Möglichkeit, den von SAP angebotenen Infrastructure as a Service-Dienst Hana Enterprise Cloud (HEC) zu nutzen; in dieser Variante leistet SAP über die Bereitstellung des Produkts S/4HANA hinaus einige Services im Betrieb des Systems.

In der Ausprägung S/4HANA Software as a Service werden zwei Versionen, „Essential Edition“ und „Extended Edition“, angeboten:

Cloud, Essential Edition: diese Edition bietet S/4HANA als reines Software as a Service-Modell an, die Governance des Systems liegt bei SAP. Die Software bekommt alle drei Monate ein Update; derzeit läuft die Version 2005. Die Updates werden automatisch von SAP eingespielt; der Kunde hat hier nicht die Möglichkeit, einen Cloud-Anbieter (AWS, Azure, …) selbstständig zu wählen. Der Kunde hat des Weiteren vergleichsweise wenig Möglichkeiten, das System zu verändern. In dieser Version ist die Standardisierung sicher am höchsten, die Total Cost of Ownership dürfte am niedrigsten sein, jedoch auf Kosten der Flexibilität und Erweiterbarkeit. Die Essential Edition richtet sich eher an Firmen, die in einem Land tätig sind und nicht branchenspezifische Anforderungen mit dem S/4HANA-System abbilden wollen. (Diese Edition hieß bis vor kurzem Multi Tenant Edition.)

Cloud, Extended Edition: obwohl auch als Software as a Service angeboten, ist diese Edition dem Wesen nach sehr nahe an On Premises; die Software nutzt zwar die gleiche Basis wie die Essential Edition, der Funktionsumfang ist jedoch so groß wie bei der On Premises-Variante: SAP hat diese Edition für 25 Branchen und 50 Länderversionen ausgeprägt – ergo können viele länder- oder branchenspezifische Anforderungen im Standard abgebildet werden. Auch liegt hier die Entscheidung über Upgrades etc. beim Kunden. Der Unterschied zu on Prem ist also eher technisch, sprich das System wird in der Cloud betrieben, und lizenzrechtlich, sprich das System, wird als SaaS betrieben – beispielsweise bei SAP, oder auch bei anderen Anbietern (AWS; Azure, …). Ergänzend sei erwähnt, dass diese Edition bis vor kurzem Single Tenant Edition hieß.

Es gehört zum Projektinhalt in einer recht frühen Phase, die Entscheidung über diese IT-Architektur zu treffen.

Aus unserer Erfahrung hat es sich bewährt, diese Fragen in einem vorbereitenden, neutralen Scoping Projekt zu beantworten. So stellen Sie sicher, dass sie den maximalen Nutzen aus Ihrer S/4HANA Migration ziehen.

Hinweise:

• ACENT nutzt aus Gründen der besseren Lesbarkeit bei Personenbezeichnungen ausschließlich die männliche Form. Sie gilt im Sinne der Gleichbehandlung grundsätzlich für alle Geschlechter und stellt keine Wertung dar.
• SAP S/4HANA ist eingetragenes Markenzeichen der SAP SE.

Der Beitrag Erfahrungen mit SAP S/4HANA erschien zuerst auf ACENT AG.

In unseren Projekten begegnen wir häufig den unten aufgeführten Situationen – den aus der Situation entstehenden Wunsch nach Verbesserung haben wir jeweils in der Überschrift aufgeführt. Auch wenn sich die Beteiligten häufig an diesen Status Quo gewöhnt haben, ist doch eine Verbesserung in Effizienz und Effektivität empfehlenswert und im Rahmen einer Digitalen Transformation mit und um S/4HANA möglich.

• Der Wunsch nach Alternativen: Sie haben ein zentrales ERP-System mit dem heutigen Stand der Technik  – wohl von SAP, aber vielleicht auch von anderen Herstellern, die, by the way, auch nicht schlafen… vor einer so großen Transformation wie einer S/4HANA-Einführung mag es durchaus angeraten sein, auch einmal links und rechts nach Alternativen zu schauen.

• Reduzierung der Komplexität: Sie haben entweder ein einzelnes System oder – insbesondere bei international vertretenen Firmen mit ganz unterschiedlichen Aktivitäten ist dies der Fall – eine komplexe Landschaft, die im Laufe der Jahre organisch oder durch Zukäufe gewachsen ist.

• In die Cloud: Sie betreiben die Masse Ihrer Systeme selbst, im eigenen Rechenzentrum (On Premises, häufig abgekürzt on prem). Die Alternative „Betrieb in der Cloud“ ist bereits im Einsatz, der Anteil der entsprechenden Systeme hingegen ist überschaubar.

• Weniger Heterogenität: Sie betreiben nebst Ihrem SAP-System diverse Vor- und Umsysteme. Zwischen den Systemen gibt es Updates, die häufig nur in Batches vorgenommen werden, meist in der Nacht.

• Weniger Abstimmungsarbeiten: Abstimmungen nehmen viel Zeit Ihrer Mitarbeiter in Anspruch. Sei es die Abstimmung zwischen Finanzbuchhaltung und Controlling, die Abstimmung von Umsatzdaten verschiedener Systeme, zwischen Tochterfirmen und zentrale oder dergleichen mehr. Unterschiedliche Aussagen aus verschiedenen Systemen sind oft nur mit viel Aufwand, bisweilen gar nicht vollständig zu erklären.

• Real Time Reports: Sie betreiben verschiedene Datawarehouses, die periodisch „betankt“ werden und häufig nicht tagesaktuell sind. Die Menge der Daten, die im DWH verarbeitet werden kann, ist begrenzt. Auswertungen über viele Jahre oder über viele Dimensionen stoßen an ihre Grenzen.

• Bessere Usability: Ihre Mitarbeiter nutzen in der Regel die SAP-Maske des guten alten SAP GUI (SAP Graphical User Interface). Diese Maske ist nicht auf Schönheit optimiert, sondern auf Standard. In der Tat kommen Bearbeiter, seien sie in der Verwaltung oder im Lager, nach hinreichend langer Einarbeitung gut damit klar und erledigen effektiv viele Buchungen pro Zeiteinheit. Weniger schön ist der GUI inklusive der Navigation im System für Gelegenheitsuser. Bereits heute gibt es von SAP modernere Benutzeroberflächen (neudeutsch User Interfaces); diese sind aber noch nicht sehr verbreitet.

• Weniger Engpässe: Mitarbeiter im IT-Betrieb, zuweilen Techies genannt, sind rar. In heutigen Systemen wird viel Zeit darauf verwandt, Systeme nur am Laufen zu halten beziehungsweise nach einer Störung wieder anzufahren. Zeit für Optimierungsmaßnahmen ist nicht im Überfluss vorhanden. Sogar sicherheitsrelevante System-Patches werden nicht immer aktuell eingespielt.

In allen oben genannten Situationen lässt sich mit S/4HANA eine Verbesserung erzielen. In den Teilen 2 und 3 werden die Ziele und Wege dazu erläutert.

Hinweise:

• ACENT nutzt aus Gründen der besseren Lesbarkeit bei Personenbezeichnungen ausschließlich die männliche Form. Sie gilt im Sinne der Gleichbehandlung grundsätzlich für alle Geschlechter und stellt keine Wertung dar.
• SAP S/4HANA ist eingetragenes Markenzeichen der SAP SE.

Der Beitrag Erfahrungen mit SAP S/4HANA erschien zuerst auf ACENT AG.

Sowohl bei SAP-Projekten als auch bei Sales Force Einführung oder Bankensoftware liefert immer ein Software-Standardprodukt die Basis. Viele der notwendigen Funktionen sind bereits vorhanden, sie werden über Customizing oder andere Zusatzentwicklungen angepasst.

Wie gestalte ich diesen Prozess der individuellen Anpassung bei einer agilen Projektsteuerung?

Wir alle kennen die klassische Wasserfallmethode aus vielen IT-Projekten. Hier versuchen wir zunächst den gesamten Projekt Scope zu definieren und dann bis zur Feinspezifizierung festzulegen. Ist das erledigt, wird der quasi in Stein gemeißelte gesamte Verlauf freigegeben. Anspruch ist fortan, die definierten Schritte 1:1 umzusetzen. Veränderungen und Anpassungen sind lästig und nur in Change Request Boards durchzusetzen. Da Anforderungen und Use Cases zunehmend komplexer werden, erweist sich dieses Vorgehen als zu wenig flexibel.

Die agile Vorgehensweise hat einen komplett anderen Ansatz: hier wird Veränderung zum Bestandteil des Projektmanagements, sie ist integrativer Bestandteil. Wie funktioniert das?

Die Scoping Phase ist auch für agile Projekte substanziell. Zu Beginn müssen die Grundzüge der Lieferobjekte klar definiert werden. Das gemeinsame Verständnis für das zukünftige Produkt ist die Basis der späteren Projektarbeit.

Agile Projektsteuerung geht mit Komplexität anders um. Jahrelang in einer Organisation aufgebautes Wissen kann man nicht mal eben schnell nachlesen, verarbeiten und in eine perfekte Lösung gießen. Mag die Ablösung eines separaten Datev-Systems noch überschaubar gewesen sein, wird es viel komplexer, wenn verschiedene Firmen nach einem Merger in ein komplett neues integriertes System zusammengefügt werden. Auf diese Herausforderung gibt die agile Steuerung gute Antworten.

Im agilen Projekt sind Vertrauen und Transparenz der Schlüssel zum Erfolg.

Alle Businesspartner sind durch den gesamten Verlauf aktiv eingebunden. Die Kundenanforderung insgesamt, aber auch individuelle Anforderungen der Fachabteilungen werden in Use Cases „portioniert.“ Alle Beteiligten beschreiben konkret, welche Aufgaben sie abwickeln und welche Unterstützung sie dazu benötigen.

Die Qualität der so erarbeiteten Use Cases in der Scoping-Phase ist ein erfolgskritischer Faktor. Sie sind der rote Faden, der durch das Projekt leitet:

In der Anfangsphase hilft der Use Case, das Produkt – also das Ergebnis der Projektarbeit – wirklich zu verstehen. Später dient er als Implementierungshilfe beim Customizing. Er kann Anleitung für den Testleitfaden sein und Basis für die Konzipierung der Trainings.

Kritische Anforderungen, bspw. zum Datenschutz, können ergänzt werden. Alles wird funktional definiert. Prozessuale Anforderungen können aufgenommen werden.

Kurzum: Die agile Projektsteuerung modularisiert und clustert Anforderungen. Im Ergebnis entsteht der Leitfaden für ein prototypisches Vorgehen, heruntergebrochen auf einzelne Module oder Cluster: der Golive ist in einzelnen kleinen Schritten möglich.

Der „Big Bang“ nach dem Durchlauf aller Pakete einer „Wasserfall-Planung“ ist damit Vergangenheit. Bei agilen Projekten können wir durch laufende Diskussion der Anforderungen, gemeinsame Priorisierung und kontinuierliche Tests das eigentliche „Endprodukt“ ständig optimieren. Insofern hat diese Vorgehensweise auch eine qualitätssichernde Funktion. Zum festgelegten Termin muss das MVP (Minimum Viable Product) funktionieren. Dann arbeitet das Team inkrementell weiter und setzt nach und nach produktiv.

Ein weiterer Vorteil: wenn erste Funktionen zur Verfügung stehen, entfallen häufig zunächst von den Product Owern geforderte Sonderlösungen. In der Scoping Phase fehlt manchmal das Abstraktionsvermögen, wie Prozesse nach Umsetzung des Projektes wirklich laufen. Es werden Funktionen gefordert, deren – auch finanziellen – Aufwand man sich sparen könnte. Stakeholder lassen sich davon überzeugen, wenn sie verstehen, dass Anpassungen auch im Nachhinein noch möglich sind.

Stichwort Termin: wie plane ich bei Agilität überhaupt einen Termin? Und wie plane ich die Kosten? Ist das abschätzbar?

Lange wurde behauptet, 70 % aller IT Projekte schlagen fehl, reißen Termine und Budget. Die Ursache lag nicht selten in den Wasserfall-Methode, die dazu verführt, an jedem noch so unwichtigen Detail festzuhalten, nur weil es im Plan steht. Genaue, voluminöse Projektpläne, alles auf den Tag genau definiert, erwiesen sich als Makulatur. Die unbedingte Sicherheit war damals und ist heute Illusion.

Wie steht es um die Budgetplanung bei der agilen Projektsteuerung? In der klassischen Wasserfall-Welt glaubten wir an Festpreise und haben damit gelebt, dass diese regelmäßig in Change Requests angepasst wurden.

Die agile Vorgehensweise will den Scope mit den vorhandenen Rahmenbedingungen managen und den Fokus auf das Wichtigste richten. Die Termine sind fix, der Scope kann angepasst werden.

Gleiches gilt natürlich für die Kosten und Ressourcen. Sind diese Dimensionen vereinbart, bleibt gar nichts anderes übrig, als den Scope zu optimieren. Das stellt das klassische Projektmanagement-Dreieck auf den Kopf, führt aber zu guten Ergebnissen.

Der entscheidende Unterschied liegt in der Art, wie das Wichtigste definiert wird. Die Definition liegt nun bei allen Beteiligten, insbesondere bei den Product Ownern. Die Perspektive der Verantwortung dreht sich. Das Ergebnis fällt nicht mehr allein in den IT-Verantwortungsbereich, sondern ist ein gemeinsames Ergebnis. Das ändert die gesamte Zusammenarbeit.

Diese Arbeitsweise erfordert großes Vertrauen in das gesamte Team, Abschied von gewohnten Kontrollmechanismen und vor allem eine andere, eine neue Fehlerkultur.

Wo liegen die Stolperfallen für CIOs?

Der Einkaufsprozess solcher Projekte stellt die bisher üblichen Verfahren auf den Kopf! Das wird oft unterschätzt. Einfach vergleichbare Angebote mit Festpreisen gibt es nicht. Die Einkäufer müssen intensiv und früh eingebunden werden, um zu verstehen, was prototypisches Arbeiten heißt. Oft wird zu Beginn nur ein kleines Volumen für kleine Schritte verhandelt. Das widerstrebt dem Wunsch nach einem Gesamtbudget. Weit verbreitet ist auch die Befürchtung, dass ein einmal beauftragter Dienstleister nach dem ersten Schritt nicht mehr mit sich verhandeln lässt.

Mein Rat: unbedingt im Vorfeld mit allen Beteiligten diskutieren, wie das Arbeiten in anderer Herangehensweise funktioniert. Das finden nicht alle toll. Es ist teilweise unbequem für die Fachabteilungen, weil die Mitarbeiter mehr Zeit investieren müssen und konkret Verantwortung übernehmen. Früher hat die IT an externe Dienstleister delegiert.

Agile bedeutet, in Gesamtverantwortung zu gehen. Das ist ein Paradigmenwechsel, der sich lohnen kann! Der Anfang zu einer schrittweisen Veränderung kann die Umsetzung eines ersten geeigneten Projekts mit der neuen Methodik sein.

Für CIOs ist es wichtig, sorgfältig abzuschätzen, welche der Projektleiter für ein solches Pilotprojekt geeignet sind:

Stakeholder Management, Kommunikation, Führung von Mitarbeitern, Kunden und Dienstleistern … all dies sind Aufgaben, die Projektleiter bisher nicht in dem Umfang übernehmen mussten und oft noch nicht gut beherrschen. Da braucht es Unterstützung und Begleitung.

Ist das Ziel, komplett auf die agile Methodik umzuschalten?

Agiles Projektmanagement sollte auf keinen Fall als neue verbindliche und einzige PM-Methode eingeführt werden. Jeder CIO sollte sich fragen: Ist das geplante Projekt besser agil oder klassisch umzusetzen?

Wenn ich z.B. bei einem Roll-out- oder Releasewechsel-Projekt auf einen erprobten Masterplan zurückgreifen kann, empfehle ich nicht, auf agil umstellen, sondern entlang der erprobten Best Practise die Planung aufsetzen.

Wenn ich jedoch für komplexe und neue Anforderungen eine optimale Lösung erarbeiten möchte, ist agile eine gute Antwort.

Bei der Entwicklung einer komplexen neuen Anforderung stößt unser Gehirn unweigerlich an Kapazitätsgrenzen. Wir können uns häufig nicht vollumfänglich vorstellen, was passiert, wenn verzahnte und übergreifende Gesamtanforderungen miteinander in Verbindung geraten. Hier ist es unglaublich hilfreich, die Messpunkte eines prototypischen Vorgehens zu haben. So lassen sich Scope und Lernkurven sehr gut managen.

Zusammengefasst lautet mein Tipp an CIOs und IT-Führungskräfte:

wenn Sie sich für eine agile Projektsteuerung entscheiden, beginnen Sie mit einem Pilotprojekt, das in besonderer Weise geeignet ist. Nehmen Sie nur Mitarbeiter(innen) in das Team, die diese Arbeitsweise ausprobieren möchten und eine hohe Akzeptanz mitbringen, beziehen Sie die Fachbereiche, Product Owner und den Einkauf von Anbeginn und intensiv mit ein.

Der Erfolg gehört dann allen!

Der Beitrag Können SAP-Projekte agile sein? erschien zuerst auf ACENT AG.