Konfiguration der S/4HANA Fabrikkalender

Die Konfiguration der Feiertage, Feiertags- und Fabrikkalender erfolgt über die Customoizing-Transaktion SCAL.

Ablauf
– Pflege der Feiertage
– Zuordnung von Feiertagen zum Feiertagskalender
– Feiertagskalenderzuordung zu Fabrikkalendern
– Ggf. Sonderregelpflege (z.B. Kurzarbeit)
– Fabrikkalenderzuordung zum Werk (OX10)

Die Definition der Feiertage erlaubt auch komplexere Konstellationen (z.B. bestimmte Tage vor/nach Ostern) abzubilden oder z.B. freie Tage zu garantieren (Feiertag der auf ein Wochenende fällt, wird auf den nächsten Werktage verschoben). Sonderregeln erlauben es zudem z.B. Kurzarbeit oder Werkferien abzubilden.

Customizingtabellen (SE11)
– Fabrikkalender-Definition (TFACD)
– Fabrikkalendertexte (TFACT)
– Feiertagskalender (THOC)
– Feiertagsdefinitionen (THOCD)
– Feiertage (THOL)
– Feiertagstexte (THOLT)

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

Fit/GAP-Analysen und Fit-to-Standard Workshops

Teil der Projektphase “Explore” ist insbesondere die Prozess- und Anforderungsaufnahme, der Abgleich mit dem SAP Standard, eine Konkretisierung des Zielsystems und das Aufspüren von Deltas. Nachdem die Grundlagen und Rahmenbedingungen in den Projektphasen „Discover“ und „Prepare“ geklärt und vorbereitet wurden, folgt die Ermittlung der Anforderungen und Analyse der unternehmensinternen Gegebenheiten. Dazu werden Fit-to-Standard Workshops mit der folgenden Zielsetzung durchgeführt:

  • Kennenlernen des Geschäftsmodells,
  • Analyse der Geschäftsprozesse und vorliegenden Daten,
  • Projektion auf SAP Best Practices Prozesse
  • Definition von Zusatzanforderungen und
  • nötigen Datenaufbereitungen.

Als FIT bezeichnet man alle Prozesse, die über die Konfiguration der SAP-Standardlösung abgedeckt werden können. Ein GAP erfordert eine kundenindividuelle Entwicklung, die oftmals als RICEFW bzw. WRICEF bezeichnet wird. Die Abkürzung RICEFW steht für die möglichen Lösungsalternativen (Objekte):

  • Reports (Berichte),
  • Interfaces (Schnittstellen),
  • Conversions (Datenformatkonvertierung z.B. CSV zu XML),
  • Enhancements (Erweiterungen bzw. Modifikationen; also Standardsoftwareänderungen),
  • Forms (Formulare, wie das Bestellschreiben) und
  • Workflows (Automatisierung von Arbeitsabläufen).

Ermittelte Deltas werden in einer Backlog-Liste zusammengetragen, es erfolgt ein sogenanntes T-Shirt-Sizing (Schätzung von Zeit und Kosten) sowie eine Entscheidung, inwiefern das Thema weiter betrachtet werden soll. Insofern eine Entscheidung zur weiteren Betrachtung getroffen wurde, folgen ggf. Machbarkeitsstudien und Umsetzungskonzepte bzw. -designs. Gute Beratung folgt dem Prinzip möglichst nahe am SAP Standard zu bleiben und eine Kosten-Nutzen-Abwägung anzuregen. Eine umfassende Kosten- und Aufwandsschätzung bezieht übrigens dabei nicht nur den Projektaufwand bzgl. Konzeption, Entwicklung, Test, Integration und Schulung ein, sondern berücksichtigt auch Wartung und Support im produktiven Betrieb.

Fit-to-Standard Workshopdurchführung

In Fit-to-Standard Workshops haben sich die folgenden Schritte etabliert. Theoretische Betrachtung der Best Practices, um Begrifflichkeiten und das Prozessverständnis zu vermitteln sowie nötige Entscheidungen vorzubereiten. Durchführung der Geschäftsprozesse im S/4HANA-System. Anregung von Diskussionen, wie die Prozesse zu den aktuellen Kundenanforderungen passen. Konkretisierung des Zielsystems, d.h. Abstimmung der Konfiguration, Stammdatenaufbereitung, Organisationsstrukturen, Berechtigungen usw. Identifikation von Anforderungen (Deltas), die nicht über SAP-Standardprozesse abgebildet werden können. Bestenfalls sollte man Kunden zudem die aktive Arbeit im System ermöglichen; ggf. kann dies auch als Teil des Workshops eingeplant werden.

Der Zugriff auf die „On-Premise Sandbox“ oder das Cloud „Starter System“, kann zudem durch guided Simulations, Online-Schulungen usw. ergänzt werden. Einen Workshop sollte man mit dem Einholen eines Feedbacks abschließen, um sich kontinuierlich zu verbessern und den Erfordernissen der Zielgruppe weiter anzunähern (Kaizen). Das Einholen des Feedbacks, kann über ein Tool erfolgen. So z.B. via Easyfeedback. Da derzeit viele Teams virtuell und verteilt zusammenarbeiten, kann die Betrachtung des Tools „MURAL“ interessant sein. Es handelt sich dabei um ein virtuelles Whiteboard.

S/4HANA-System für die Workshnops

Im Vorfeld wurde bereits ein On-Premise Sandbox System oder das Cloud Starter System für die Workshops bereitgestellt und um Best Practices (BP Explorer), eine Model Company oder Qualified Partner Packages angereichert. Die Model Company ist ein branchenspezifisches S/4HANA-System, welches bereits lauffähige Wertschöpfungsketten (Best Practices) beinhaltet. Es ist eine kostengünstige Alternative gegenüber den individuell implementierten SAP Best Practices. Über eine kostenlose Schulung, PowerPoint-Präsentation und das Whitepaper, können Sie sich detaillierter über die verschiedenen Model Companies informieren.

Fragenkataloge für die Workshops

Ergebnisse der Fit-to-Standard Workshops

  • Auswirkung der neuen Lösung auf bestehende Prozesse ist bekannt
  • Zielsystemkonkretisierung (Konfiguration, Organisationsstruktur, Daten etc.)
  • Dokumentierte Lücken (u. A. in der Backlog-Liste)
  • Bewusstsein für Wertschöpfung und KPIs bei den Anwendern vorhanden

Eigenständige Systemanalyse

Als Ergänzung zu den Workshops, können auch mit Hilfe von technischen Hilfsmitteln Analysen durchgeführt werden. Insofern das Legacy System ebenso ein SAP-System ist, finden sich SAP-Berater gut zurecht. Auch der Einstieg in ein bereits entwickeltes Projektsystem kann erforderlich sein. Ein paar Anregungen möchte der Autor daher dem Leser auf den Weg geben. So gibt es das Custom Code Lifecycle Management (CCLM) im Solution Manager, um Eigenentwicklungen und Modifikationen zu analysieren. Weitere Informationen finden Sie auf der Seite von SAP im Bereich SAP Solution Manager 7.2 sowie eine gute Übersicht zu den dazu vorhandenen Best Practices und Demos im Blog von Thomas Fischer. Die Quaellcodeanalyse kann auch über das Programm “/SDF/CD_CCA” bzw. die Transaktion „CC_APPS“ erfolgen.  Weiterführende Informationen finden Sie über einen Klick auf Fit/GAP-Analyse.

In den nächsten Artikeln werden die Beschleuniger für Fit-to-Standard-Analysen vorgestellt sowie die nötige Ergebnisdokumentation erläutert.