Abstract: The introduction of S/4HANA requires thorough planning, clear goals and careful implementation to ensure security and efficiency. It is recommended to involve an experienced partner and to focus on training, testing and data migration during realization.
As I explained in the introduction to BLOG 26, the “Red Thread” posts form a summary of the 25 previously published BLOG posts by project phase:
- Project Preparation -> concluded with the Project Kick-Off Meeting (see BLOG 26).
- Scoping & Prototyping -> completed with the end-to-end (e2e) process integration test (without RICEF and without connected sub-systems) (see BLOG 28)
- Realization -> completed with the end-to-end (e2e) acceptance test (incl. RICEF and connected subsystems)
- Implementation -> completed with the go-live and the complete handover of the system to the business owners respectively the operational support organization (planned in BLOG 30)
This article is about the realization.
Phase 3: Realization
During realization, the R(eports) I(nterfaces) C(onversions) E(nhancements) F(orms) W(orkflows) identified in the previous phase are technically specified and realized.
In retrospect, in my experience it is still most important to define the scope completely and unambiguously as part of the additional developments and then to manage it accordingly. On the one hand, it is a matter of determining which RICEF objects are to be developed at all and, on the other hand, what they should finally contain or perform.
Below are the best practice principles for each development object type from my current retrospective perspective during realization. This is generally based on the following thoughts:
- With each additional development, I create something that is not later supported by SAP support; I therefore limit my benefit from SAP standard support. In addition, many superficially supposedly “small” developments, such as the extension of master data fields, often cause a number of subsequent developments, which are often not included in the initial evaluation – in my perception, this problem has been exacerbated by the adaptations of analytical FIORI apps in S/4HANA, which may be necessary.
- With each additional development, I get a bit into the individual personnel dependency of the respective developer; even if the fairy tale exists that this can be avoided through appropriately structured programming and good complete documentation, this does not take place in 90% of the projects, because ultimately the time pressure becomes too great … and in most cases this is then also no longer reworked. I have at least experienced various situations in which in-house developments in SAP could no longer be continued because the last developer who was still working on it and could maintain the development was no longer available. In itself a risk, which one wanted to exclude by using a standard software.
- In most SAP projects, very large sums are spent on developments that prove to be obsolete after a short time and are no longer used; this is particularly true for reports, forms and the migration of historical databases.
For this reason, I would already base the scoping of the development objects on the following principles:
R(eports): In principle, no reports are developed during the implementation project. Exceptions can be (these should always have to be proven):
1. reports required by law in a specific format (where these would need to be included in the SAP standard).
2. reports requested directly by the owner or key business partners in a defined format.
Otherwise, it should be assumed that the information needs of the business departments can be satisfied with the options available in the SAP standard, and if it turns out after the go-live that this is not the case in certain areas, the comprehensive options of embedded BI in S/4HANA can certainly be used to remedy the situation in a timely manner.
I(nterfaces): See BLOG 21 – Analyze your surrounding systems and interfaces before starting the project. This is a suggestion for a structured approach for the conversion to S/4HANA: “Integration Solution Advisory Methodology (ISA-M)”.
C(onversions): See BLOG 22 – Ensure from the beginning that you work effectively on cleaning up your data and make it business ready – this is the nuts and bolts for a Boring Go-Live.
In this context, also define future Master Data Governance- with S/4HANA MDG: The added value of S/4HANA is also defined by high quality master data. MDG covers the increasing governance and compliance requirements and is an internationally deployable and standardized platform for the central creation, maintenance, management, distribution and consolidation of all relevant master data – regardless of whether the connected target systems are SAP or non-SAP systems. How can your company use the MDG and which requirements are necessary? To learn this in a compact and cost-effective way, I recommend the workshop “2100-MDG” of T4T (4 hrs / 200,– EUR) – please contact us for the current dates and registration modalities.
E(nhancements) – In order not to restrict the degrees of freedom in system deployment, please refer to BLOG 18 -How can or should the term “SAP Standard” be handled in S/4HANA, and why is it important to define this?
F(orms) – I would suggest the following principles for forms today:
- A standard form development technology, such as Adobe Forms, that is easy to maintain internally is used
- For forms used internally only (e.g., in production or maintenance), focus purely on content and efficient use, not on layout.
- For externally used forms, a uniform C(orporate) I(dentity) layout defined by the responsible department is set up once and used uniformly in all forms.
W(orkflows) – a lot has happened in S/4HANA in this area:
Procurement Workflows: Although SAP Business Workflow has been around since ERP SAP R/3, the topic has come back into the focus of companies in the course of digitization and process automation. At the same time, SAP has expanded and renewed the workflow component in the area of purchasing as part of its S/4HANA strategy. In addition to the existing release options and processes (which continue to be supported), SAP has developed the so-called flexible workflow. Here it is possible to define release processes based on an easily customizable set of rules for the various object types in purchasing. The change in GUI technology to SAP Fiori has also made it easier to work with SAP Business Workflow.
A very compact introduction to the new workflows is offered by T4T’s course “2100-WFMM” (3 hrs / 150,– EUR) – feel free to ask us for the current dates and registration modalities.
Sales workflows: In the area of Purchasing (MM), SAP Business Workflow is already used intensively by most companies. In the Sales and Distribution (SD) area, workflow has long led a shadowy existence. With the exception of releasing credit and debit memo requests, companies have primarily used custom workflow implementations. However, with the introduction of S/4HANA, SAP has made it possible to define additional standard workflow scenarios. Using the flexible workflows, it is now also possible to quickly and easily configure workflows for orders and quotations, thus automating and digitizing processes.
A very compact introduction to the new workflows is offered by the course “2100-WFSD” of T4T (3 hrs / 150,– EUR) – please ask us for the current dates and registration modalities.
Final acceptance test: If you have used the Accelerated Testing environment in the previous integration tests, you are well prepared for the final acceptance test due to the 100% reusability and the integrated translation capabilities. For details, please refer to BLOG 19 – What is the Accelerated Testing Environment, and how do I prepare it?
Underlying testing principles of the final acceptance test should be:
- Everything is tested e2e incl. RICEFW, authorizations, process and user documentation as well as input and output devices.
- Everything is tested in all relevant languages.
- The system is operated exclusively by the business and NOT by a consultant.
- Testing is based on a complete load of the data migration – this should have final production quality.
- The business determines what is tested – but it should be only real existing test cases.
- Each successfully completed test script is formally approved by the business owners.
- During realization period incident handling is done in the same way as planned for productive operation, or using the same.