Die letzten Wochen habe ich mich mit den verschiedensten Leuten zum Thema S/4 unterhalten. Die vielen verschiedenen Sichtweisen haben mich dabei etwas erkennen lassen: Die Projektart liegt im Auge des Betrachters.
Ein S/4 Projekt aus funktionaler Sicht
Menschen mit funktionalem Hintergrund neigen dazu, sich auf die erforderlichen Anpassungen der Geschäftsprozesse zu konzentrieren. Selbst wenn ein Unternehmen das einfachste, schnellste und günstigste S/4-Projekt durchführt, kann dies zu erheblichem Aufwand führen, auf Grund von Änderungen in den unterstützten Funktionalitäten. Es müssen verschiedene Vorbereitungen getroffen werden, darunter die Customer Vendor Integration (CVI), bei der für jeden Kunden- oder Lieferantenstamm im System Geschäftspartner generiert werden müssen. Der SAP Readiness Check und die Simplification List zeigen ebenfalls notwendige Änderungen an Geschäftsprozessen auf;
ein Beispiel aus dem SAP-System unserer Schwesterfirma G3G, ist die SD Erlösrealisierung. Diese Funktion wird momentan noch genutzt, ist aber in der neuesten S/4-Versionen nicht mehr verfügbar. Im Rahmen des Projekts müsste die Erlösrealisierung daher im Rechnungswesen implementiert werden. Da einige Funktionen aus GTS, EWM sowie SRM, CRM und Analytics wieder in S/4 integriert werden, wird es weitere Funktionsbereiche geben, die auf Grund der absorbierten Prozesse eingestellt werden. Aus funktionaler Sicht bietet sich dadurch die Möglichkeit, neue Funktionen einzuführen und dadurch das System zu verbessern.
Die Datenqualität wird ein weiterer wichtiger Aspekt sein der viel Arbeit erfordert; Auch hier gibt es aus funktionaler Sicht die Möglichkeit, über das erforderliche Maß hinauszugehen und die Daten vollständig zu bereinigen und das Data Governance zu verbessern.
Und dann gibt es natürlich noch das UI. Lange Zeit als großer Nachteil von SAP verspottet, wird das SAP GUI von Fiori in den Hintergrund gedrängt. Unabhängig vom Projektverlauf müssen also Änderungen an den Geschäftsprozessen und der Dokumentation vorgenommen werden, da die Benutzer nun kleinere rollenbasierte Fiori-Anwendungen und nicht mehr die großen, vielfältigen SAP-GUI-Transaktionen durchlaufen. Da unglaublich viele Fiori Apps zur Verfügung stehen, hat SAP 'Lighthouse Fiori Apps' ernannt, die den Kunden helfen sollen sich zu orientieren. Dies sind die Apps, die von der SAP als am Wichtigsten und Nützlichsten angesehen sind.
Ein S/4 Projekt aus technischer Sicht
Wenn man das Thema S/4 mit Personen aus der Basis diskutiert, wird häufig die Meinung vertreten, dass S/4 ein obligatorisches technisches Projekt ist, wie viele Upgrades zuvor auch. Für 99% der Kunden läuft das aktuelle System nicht auf Linux oder einer HANA-Datenbank. Daher ist ein OS/DB-Replatforming unerlässlich.
Die meisten Kunden haben außerdem Hardware im Einsatz, deren Leistungsfähigkeit nicht ausreicht um HANA zu betreiben oder die nicht die richtige Konfiguration hat, um den TDI-Prozess für die HANA-Zertifizierung zu erhalten (die Alternative zum Kauf von vorkonfektionierten Geräten). So wird bei diesen Projekten häufig die Cloud – entweder vollständig oder hybrid – eingesetzt. Damit einher geht die Entscheidung zu Private Cloud vs. Hyperscaler. Dieses Projekt stellt aber kein einfaches Re-Platforming oder Wechsel von Oracle zu MSSQL dar; Es liegt eine grundlegende Änderung in der Architektur der Datenbank vor, sodass das Sizing zu einer komplizierten Diskussion wird.
Die Wahrheit? Irgendwo in der Mitte
Die DSAG und die ASUG betonen im Artikel "Mapping Your Journey to SAP S/4HANA® A Practical Guide for Senior IT Leadership", dass typischerweise ein Greenfield S/4-Projekt von der Business Seite und ein Brownfield-Projekt von der IT Seite getrieben wird. Meiner Meinung nach, müsste aber auch das Brownfield-Projekt von Anfang an Input von der geschäftlichen/funktionalen Seite miteinbeziehen. Vielleicht sogar schon bei der Entscheidung Greenfield oder Brownfield.
Auch die Lizenzierungsmöglichkeiten werden ein wesentlicher Bestandteil des Business Case sein, da S/4 eine neue Lizenz ist. Die genaue Anzahl der benötigten Lizenzen hängt sowohl von den funktionalen Änderungen, die Teil des geplanten Projekts sein werden, als auch von den Hardwareentscheidungen der technischen Teams ab.
Sehen Sie alles klar durch PRISM
Wir versuchen beide Seiten zusammenzubringen. Unser S/4 Readiness Check dient als Frühwarnsystem für wichtige funktionale Hindernisse in einem bestimmten System, erkennt die Auswirkungen des Re-Platformings und unterstützt bei der Größenanpassung für verschiedene Cloud- oder On-Premise Entscheidungen. So erhält ein Unternehmen über unsere PRISM-Platform einen gemeinsamen Blickwinkel, so dass eine offene Zusammenarbeit möglich ist und die durch das Projekt entstehenden Aufwände der verschiedenen Abteilungen nachvollzogen werden können.
Dabei geht es nicht darum, den SAP Readiness Check zu ersetzen, der mit der Version 2.0 eine große Verbesserung darstellt, sondern vielmehr, die relative Größe der Herausforderungen zu kennen und sie mit anderen SAP-Kunden zu vergleichen, bevor ein einziger Cent ausgegeben wird.
Einen Kommentar schreiben