Abstract: A secure and efficient implementation of S/4HANA requires clear scoping that focuses on business-critical processes and an iterative prototyping phase to identify and resolve potential issues early on.
As I explained in the introduction to BLOG post 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 post 26).
Scoping & Prototyping -> completed with the end-to-end (e2e) process integration test (without RICEF and without connected subsystems) (current post – BLOG post 28)
Realization -> completed with the end-to-end (e2e) acceptance test (incl. RICEF and connected subsystems) (planned in BLOG post 29)
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 post 30)
This post is about the “scoping & prototyping phase”.
Phase 2: Scoping & Prototyping
During scoping & prototyping, all processes and functions of the future S/4HANA ERP system are determined, documented in as targeted a manner as possible, and expressed as a prototype in the S/4HANA development system and tested with real data examples. Furthermore, the R(eports)I(nterfaces)C(onversions)E(nhancements)F(orms) to be implemented in the following phase are identified and functionally specified, in which context I would like to refer to the BLOG posts concerning the I(nterfaces) and C(onversions):
BLOG 21 – Analyze your conversion systems and interfaces before starting the project.
BLOG 22 – Make sure you work effectively on cleaning up your data from the start and make it business ready – this is the nuts and bolts of a Boring Go-Live
For other developments, please also see:
BLOG 18 – How can or should the term “SAP Standard” be handled in S/4HANA, and why is it important to define?
As throughout the BLOG, I base the following recommendations on the assumption that future processes should be aligned as much as possible with S/4HANA best-practice processes or be built based on them. Furthermore, I assume that you build your own Model Company and do not use SAP’s prefabricated version -see
BLOG 9 – How to evaluate the approach based on an SAP Model Company?
The procedure essentially consists of:
The identification of the processes and functions to be mapped in the new system – here I recommend using a process list/test catalog from an end-to-end test of the current system (e.g., those from the last regression test on the occasion of a release upgrade) as a starting point for determining the current processes and functions to be replaced – and mapping them to SAP’s S/4HANA best-practice processes. In terms of a structured approach, you should proceed according to the following BLOG articles:
BLOG 10 – From the Business Process Master List (BPML) to SAP Best Practice processes and their mapping in test scripts to process documentation in a B(usiness)P(rocess)M(anagement) system – a structured way to build your own Model Company.
BLOG 11 – How do I map the S/4HANA Best Practice processes in my Business Process Master List (BPML)?
>> “BPML SAP Best Practice Mapping Explanation”
and
>> “Testscript Creation facilitating the S/4HANA Best Practice Process Steps Explanation“.
The complete sets of tools addressed in these BLOG posts to help you proceed in a structured and efficient manner can be found in our Digistore24:
>> Business Process Master List (BPML) as a sample file in MS Excel
>> The comprehensive list of SAP Business Process Steps in MS Excel
Or both in a bundle:
>> Bundle: The Business Process Master List and the Process Steps in a package at a special price.
And in this phase, you are already laying the foundation that you only need to further develop in the following phases in an evolutionary manner in order to arrive at a solution that has been completely tested and documented from the user’s point of view. So pay attention to the following BLOG articles already now:
BLOG 19 – What is the Accelerated Testing Environment, and how do I prepare it?
With the corresponding toolset:
>> Accelerated Testing Package – all tools (zip) for accelerated creation of test scripts of your processes
or in the bundle with the list of process steps:
>> Bundle: The Accelerated Testing Package and the Business Process Steps as a package at a special price
and
BLOG 25 – Value-added user documentation – an overall concept. We also offer accelerators for documenting the processes in your BPM system:
>> The S/4HANA Best Practice process flows in BPMN2 format, German, HORIZONTAL
or
>> The S/4HANA Best Practice Process Flows in BPMN2 format, German, VERTICAL
depending on which standard you have established in your company.
Integration tests in the integration system
The fully developed prototype integration system should be tested for acceptance as part of an ERP end-to-end integration – if you perform the test using the Accelerated Testing Package, you have complete documentation of the test steps on the one hand and can also check in the individual process steps whether you have captured all RICEF requirements by assigning reports, interfaces, enhancements and forms to the respective process steps.
For a documentation of the process flows, I recommend on the one hand the process documentation in the BPM system, for the application flows initial recordings in the authoring tool, in order to share these with the later users and enable them to interactively familiarize themselves with the new processes. And if you have started your data migration in good time, it should perhaps even already be possible to carry out this first integration test partly on the basis of master data that has already been migrated – this is definitely something to strive for and is also easily possible with the currently available procedures and tools in the area of data migration, provided that you have started this probably most critical workstream in good time, see: BLOG 22 – Make sure you work effectively on cleaning up your data from the start and make it business ready – this is the be-all and end-all for a Boring Go-Live.
Other important core deliverables of this phase are:
- A complete listing and functional specification of all RICEF objects. This also includes the acceptance of the functional specs by the development team under consideration of the framework conditions mentioned in BLOG 18 and adapted to your situation.
- A project order updated in detail (i.e. by adding the Business Blueprint)
- The Training Needs Analysis 1 – Enablement Strategy (see also https://www.knowx.de/de/userenablement-en/) and in this context also the final strategy for the application documentation; see also BLOG 25.
- The strategy for the authorization concept
As already stated in BLOG 27, my recommendation is to work agilely in this project phase in Greenfield and Bluefield projects and to summarize the result in a Business Blueprint at the end.