Wie lange dauert die S/4HANA-Einführung?

Üblicherweise dauern, im dynamischen Mittelstand mit kurzen Entscheidungswegen, Neueinführungen 6 bis 15 Monate und Systemkonvertierungen 4 bis 12 Monate. Großunternehmen müssen teilweise mehrere Jahre einplanen. Einflussfaktoren sind neben der Unternehmenskomplexität auch die Einführungsstrategie, das SAP-Team, verwendete Werkzeuge und ob der Kunde bereits SAP im Einsatz hatte. SAP-Neukunden aus dem Mittelstand haben z.B. oftmals weniger spezifische Anforderungen und diskutieren daher weniger. Man bleibt also üblicherweise näher an den SAP Best Practice-Prozessen (SAP Standard), das Template und Blueprint (Anforderungszusammenstellung) bleiben insgesamt übersichtlicher. Wenn die Backlog-Liste mit Delta-Anforderungen (nicht im Standard abbildbare Anforderungen) übersichtlich bleibt, kann dies einer kurzen Einführungszeit sehr zuträglich sein (Paretoprinzip). Viele Entscheidungsträger und kundenindividuelle Wünsche, lassen dagegen Projekte komplexer werden. Bei Neueinführungen ist die Datenaufbereitung sowie das Change-Management inkl. Mitarbeiterschulung aufwändiger. Handelt es sich bereits um einen SAP-Kunden, so verursachen die vorhandenen kundenindividuellen Entwicklungen (RICEFW) Aufwand. Change-Management bedeutet dann unter anderem auch dem Kunden SAP-Standardlösungen näher zu bringen.

SAP Team Schulungen Trainings WBTs

SAP S/4HANA Lieferplanabwicklung mit Lieferplanabrufen

Lieferpläne können auf Kontrakten oder anderen Einkaufsbelegen basieren und werden über die Transaktion ME31L angelegt (Fiori-App Lieferplan anlegen). Später kann innerhalb der Lieferpläne, über die Transaktion ME33L oder die Fiori-App „Lieferplan anzeigen“, die Abrufdokumentation eingesehen werden. Dies setzt die Wahl einer passenden Vertragsart (Belegtypen siehe SM30 VV_T161_VL) voraus, die die Abrufdokumentation vorsieht. So können dann z.B. aktuelle Lieferplanabrufe mit vergangenen verglichen werden, um z.B. Mengenabweichungen zu analysieren. Neben den in Einkaufsbelegen üblichen Einträgen (Gültigkeit, Incoterms, Zahlungsbedingungen, Konditionen usw.), finden Sie auch Fixierungshorizonte. Mit deren Hilfe können Sie Verbindlichkeitsgrade pflegen sowie die automatischen Änderungen im Bedarfsplanungslauf aussteuern. Da es bei kurzfristigen Änderungen ggf. zu Produktions- und Materialerstattungsansprüchen seitens der Lieferanten kommen kann, werden automatische Änderungen von MRP im kurzfristigen Horizont bevorzugt ausgeschlossen.

S/4HANA Lieferplanabwicklung Lieferplaneinteilungen Lieferplanabrufe

Die Grafik veranschaulicht inwiefern der Disponent in den Prozess eingreifen muss bzw. kann (blau). Später kann fast alles im Hintergrund laufen (grau) und der Disponent muss sich nur noch um Ausnahmen kümmern. Die vier orangen Prozessschritte werden im Folgenden näher erläutert:

Einerseits können via ME38 manuell Einteilungen angelegt oder automatisch über die Fiori-App „MRP Live“ bzw. Transaktion MD01N angelegt werden. Der Bedarfsplanungslauf kann später via Job erfolgen, sodass Einteilungen automatisch erzeugt werden. Die Transaktion MD04 wurde in S/4HANA um eine Fiori-App „Bedarfs-/Bestandsliste überwachen“ ergänzt. Mit dessen Hilfe die Einteilungen nicht nur überwachst, sondern auch direkt geändert werden können.

Die direkte Übermittlung der Einteilungen an den Lieferanten ist eher unüblich, aber möglich. Es werden meist zusätzlich Lieferplanabrufe angelegt; manuell z.B. via ME84 oder via Fiori-App „Lieferplanabruf anlegen“. Die Ergänzung um stundengenaue Feinabrufe wäre auch noch möglich, soll hier aber nicht weiter betrachtet werden.  Die automatische Erzeugung von Lieferplanabrufen kann später über einen Job (RM06EFLB) eingeplant werden. Die Einteilungen bleiben im vorgestellten Szenario also interne Belege und zur externen Kommunikation werden Lieferabrufe eingesetzt.

Für diese Lieferabrufe kann dann zusätzlich ein „Stopping“ implementiert werden (SM30: V_T163P). So kann bei großen Mengenabweichungen zu anderen Lieferplanabrufen, bei geändertem Revisionsstand des Materials oder gültig werden eines Nachfolgematerials ein sogenanntes „Stopping“ ausgelöst werden. Der Disponent muss dann über die Transaktion ME89 explizit eine Entscheidung (Freigabe) treffen. Dies ist der einzige Schritt, welcher später zwingend manuell durchgeführt werden muss.

Denn auch das Versenden des Lieferabrufs, kann über einen Job (RM06ENDR_ALV) erfolgen. Manuell kann dies aber auch über die Fiori-App „Lieferplanabrufe drucken“ oder Transaktion ME9E veranlasst werden. 

Lernen Sie bei uns den Solution Manager bzgl. Testmanagement kennen!

Testmanagement via Focused Build Add-On im SAP Solution Manager

Der Solution Manager bietet Fiori-Apps zur Testplanung, -durchführung, -überwachung und -dokumentation sowie zur automatischen Durchführung von Regressionstests, Einbindung von weiteren Testsystemen, für das Testdatenmanagement, Analysen, Auswertungen etc. Focused Build ergänzt diesen Funktionsumfang dahingehend, dass aus den Anforderungen bzw. Arbeitspaketen Testpläne abgeleitet werden können und die Apps „My Test Execution“ und das erweiterte „Test Suite Dashboard“ zur Verfügung stehen.

Fiori-Apps zum Testmanagement

  • Change & Release Management
  • Solution Administration
  • Test Plan Management
  • Test Suite Dashboard
  • Test Step Designer
  • My Text Execution
  • Administration
  • Assign Testers
  • Check Report
  • My Defects
  • Test Suite

Testmanagementabwicklung im Solution Manager

In Focused Build können Projekte mit Ihren Anforderungen angelegt und dokumentiert (App Solution Documentation) sowie in Arbeitspaketen zusammengeführt werden. Den Prozessschritten und damit auch Arbeitspaketen ordnet man Testfälle zu. Üblicherweise bildet man pro Arbeitspaket ein Testpaket. Aus Arbeitspaketen, die bereit für Tests sind (gem. Statussetzung), können dann wiederum die Testpläne abgeleitet werden. Mit der Zuordnung der Tester kann die Testplanung schließlich abgeschlossen werden. Aufgrund dieser Zuordnung findet jeder Tester seine Testfälle im Arbeitsvorrat (App My Test Execution), führt die Tests manuell oder automatisch aus, dokumentiert die Ergebnisse (inkl. Statussetzung) und erfasst ggf. Fehler (App My Defects). Im Rahmen von Korrekturen und Nachtests findet eine Weiterbearbeitung so lange statt, bis ein positiver Teststatus für den Testfall gesetzt werden kann. Die Solution Manager Fiori-Apps zur Testplanauswertung und -analyse, wurden um das übersichtliche Test Suite Dashboard ergänzt. Dort sieht man insbesondere den Testfortschritt/Status des Testplans, der Testpakete, Testfälle und erfassten Fehler.

Einordnung der Testarten in den agilen Kontext von SAP Activate

Einzeltests bzgl. der Work Items (Unit Test) erfolgen bereits während einzelner Sprints, während zum Sprintende Funktionstests bzgl. der Work Packages eingeplant werden. Mehrere Sprints werden wiederum zu Waves zusammengefasst und diese werden mit einem (User) Acceptance Test (AT) mit Bezug zu den Anforderungen und optional zusätzlich einem Integrationstest abgeschlossen. Während vorgelagerte Tests ggf. ohne Vorbereitung und Planung durchgeführt werden, ist der AT von besonderer Bedeutung und wird daher vorbereitet und geplant. Hier werden nämlich die Endanwender einbezogen und via Statussetzung eine Entscheidung getroffen, welche Anforderungen (Transporte) später produktiv gesetzt werden. Mehrere Waves können wiederum zu einem Release zusammengefasst werden. Dies ist ein Projektumfang der produktiv gesetzt werden soll. In größeren Projekten kann die Produktivsetzung des Zielsystems nämlich in mehrere Einzelschritte unterteilt werden. Während zuvor die Testumgebung üblicherweise ein Q-System ist, werden im Sinne von SAP Activate die Integrations- und Regressionstests auf einem vorproduktiven System durchgeführt. Im Integrationstest werden komplette Wertschöpfungsketten (E2E) getestet und im Rahmen von Regressionstests erneut bereits produktive Prozesse und Funktionen überprüft. So kann man Seiteneffekte (Fehler), durch die neu hinzugekommenen Umfänge, ausschließen. Beim Go-live kann ein kurzer Test in der produktiven Umgebung zusätzlich eingeplant werden. Dieser dient als Entscheidungsgrundlage, um ggf. eine Fallbackstrategie einleiten zu können. Im Cutoverplan bereitet man bei einer System-Conversion (Brownfield-Ansatz) eine Rückkehr zu einer Systemkopie vor und berücksichtigt die Zeit, die dafür benötigt wird (Point-of-no-Return).

Zugriff auf den SAP Solution Manager inkl. Focused Build

Auf dieser Seite können Sie sich einen User inkl. Passwort aussuchen, um auf dem kostenlosen Testsystem Erfahrungen sammeln zu können. Oder Sie nutzen die Simulation, um sich von einem digitalen Guide durch die verschiedenen Aktivitäten leiten zu lassen:

Customer-Vendor-Integration (CVI) und S/4HANA-Geschäftspartner

Geschäftspartnerstämme gibt es auch bereits im ERP-System. Diese wurden für spezifische Anwendungen (z.B. FSCM) und Industrien verwendet. Für die Brownfield-Einführung des S/4HANA-Systems müssen daher bereits in SAP ERP alle Kunden und Lieferanten mit Geschäftspartnerstammsätzen verbunden werden. Im Rahmen des SAP Readiness Checks wird geprüft, wie viele Kunden und Lieferanten noch nicht synchronisiert wurden. Dies ist eine der Voraussetzungen, bevor man ERP zum S/4HANA-System konvertieren kann.

Hilfreiche Reports

  • Konsistenzprüfung (entspricht Readiness Check) z.B. bzgl. Bankdaten, PLZ, Steuerdaten usw. (CVI_MIGRATION_PRECHK)
  • Zusammenstellung der wichtigsten SAP Notes via SAP TCI-Note 2820678
  • Für die Sandboxerstellung ohne Datenbereinigung/Readiness Check (New IMG Node)
  • Vollständigkeitsprüfung (CVI_COMPL_CHK)
  • Überprüfung der CVI-Links und des Customizings insb. nach der Massenpflege oder kurz vor der Konvertierung (CVI_UPGRADE_CHECK_RESOLVE bzw. PB_CVI_IMG_CHK)
  • CVI Massensynchronisation (MDS_LOAD_COCKPIT)
  • Die Vorprüfungen wurden von SAP im Cockpit zusammengeführt (CVI_Cockpit)
SAP Consulting und Management in Hannover bzgl. S/4HANA, Ariba und ERP