12.2    Carrying Out a Transformation Project

As we discussed earlier in Chapter 5, each SAP S/4HANA project can be divided into various project phases. These phases also apply to system landscape transformations, and deviations may occur within the various transformation scenarios. The following phases are usually carried out in landscape transformation scenarios:

1. Preanalysis and planning
2. Blueprint document and project team finding
3. Test runs
4. Production conversion
5. Support after go-live

The runtimes of the individual phases can differ significantly and can also depend on the complexity of the individual projects. A rough guide is shown in Figure 12.4. In general, you can assume that, above all, several test runs of the system transition will take up the largest share of the time required for the overall project, followed by detailed preanalysis.

Figure 12.4    Duration of the Individual Project Phases

The following overview lists typical activities within the individual project phases:

• Preanalysis and planning:
  • Analysis of the current situation and design of the target situation with a clear definition of the desired transformation
  • Technical analysis of the systems, e.g., delta Customizing, in the case of a system consolidation
  • Definition of the required roles in the project and of their responsibilities
  • Creation of a business case
  • Decision on a realization path
  • Provision of a project budget
  • If necessary, procurement of professional consultation
• Blueprint and project team
  • Concept creation using a blueprint
  • Structure of the project team and the initial kick-off
  • Provision of the necessary infrastructure, e.g., the test systems
  • Planning of the test cycles and test cases
  • Installation of the required tools
• Test runs
  • Multiple test conversions of the system to be transformed. A distinction can be made between purely technical tests, which are usually carried out at the beginning of a project, and at least one complete run in order to simulate the production conversion.
  • Dynamic adjustment of the conversion based on the results from the test runs
• Production conversion
  • Preparing the existing system landscape for the conversion to the new systems
  • Locking the systems involved for the actual conversion
  • The actual production conversion (typically taking place over a weekend operating 24 hours per day)
  • Final acceptance of the converted system by the end users
• Support after go-live
  • Support from the project team for end users working with the new system landscape after the production conversion
  • Integration of SAP Support for the newly introduced SAP S/4HANA standard components

The following sections discuss the activities during the individual phases in more detail.

12.2.1    Preanalysis and Planning

The aim of preanalysis is to evaluate the upcoming tasks and to find and discuss possible solutions. In addition to technically driven questions (such as the question of providing the infrastructure for the transformation, for example), preanalysis also includes a cost-benefit analysis. The result of the process should be a clear recommendation for action that provides direction for the subsequent phases of the project.

SAP LT offers numerous options to technically support such preanalysis. The results can be relevant depending on the scenario so you can estimate the cost of the necessary conversions. Only on this basis can a comprehensive business case be prepared and thus the feasibility of a project be examined.

Particularly when new products are introduced to the market, such as SAP S/4HANA, detailed knowledge is essential for successful project completion. System landscape transformation projects in particular are not part of the traditional day-to-day business of IT departments, which is why the expertise of external consultants is often sought. Based on the preanalysis, the requirements for these specialized roles can be defined by the project’s participants, and the right experts and consultants can be contracted.

Preparing a project plan is also recommended at this point. The initial milestones can be set so you can better estimate the total duration of the project. Ideally, time planning uses backward scheduling from the go-live date. Particularly for international organizations, only limited maintenance windows are available for a transformation scenario during the course of a calendar year. Based on the project plan, you can determine early on whether the planned schedule is realistic and when you should have an alternative go-live date for possible delays in the project.

12.2.2    Blueprint and Project Team

The central document for any project is a blueprint. A blueprint accurately describes the transformation you want to carry out as well as its impact on the system landscape and business processes. Depending on the transformation scenario, a blueprint can also be used as one of the documents of relevance to the auditor. As you can see, this document is quite important, and you should prepare blueprints with great care.

Blueprints should completely document the whole conversion in order to anticipate any effects on the IT landscape. A blueprint can be structured in various ways depending on the scenario. In general, however, the following aspects should be included:

• All modifications and the objects and processes affected
  All business objects affected by an implementation must be listed, and you must provide information on the form of implementation you want. (You can read more on this in the following sections, for example, in Section 12.3.)
  This list also contains all process changes and technical adjustments, such adjusting number ranges, and as describes rules about how you want to carry out these adjustments.
• Overall project plan
  The overall project plan includes all phases of the project as well as the schedule for each step and for the production conversion.
• Impact on the overall landscape
  You have to check all effects, not only those that impact the landscape you are transferring, but also any satellite systems that may exist (for example, through existing interfaces), including programs and solutions developed by your customers.
• Test concept
  The test concept is also central, along with an overview of all scheduled test cycles including the test cases to be implemented. This applies both to the regular test conversions as well as to the acceptance test after the production conversion.
• Project team
  Finally, you’ll need an overview of all teams and team members so you can contact the parties responsible for specific topics at any time. This team overview should also include an escalation path for potential issues through all levels of the team hierarchy.

To prepare such a blueprint, a large number of employees from all affected areas of the company must work together closely. As already mentioned, external experts involved in transformation projects on a regular basis have the required project know-how and are often brought in for this purpose. After the blueprint is prepared, the document is accepted by all parties involved for several reasons. First, this buy-in ensures that all parties involved are comprehensively informed of any planned changes and, second, that individual parts of the blueprint do not contain any gaps that could lead to problems at later stages in the project.

During this phase, the infrastructure is also provided, and the tools are installed. The number of required test systems varies from scenario to scenario and depends on the number of affected systems in the IT landscape. As SAP LT is delivered as an SAP add-on, the installation is relatively easy. Additional tools required should also be integrated into the landscape at an early stage, so that they are immediately available on the test systems set up later on, thus reducing the cost of basic activities.

12.2.3    Test Runs

In this phase, all transformation tests are carried out. Even if the various test runs have different requirements depending on the progress of the project, their conditions should always correspond as precisely as possible to the conditions of the planned production conversion. These test runs are the only way to identify problems at an early stage and provide reliable estimates for the cut-over. The number of test runs also varies from scenario to scenario. However, at least two complete tests are recommended at minimum. In complex consolidations, four or more test conversions may be necessary.

These tests are primarily about ensuring quality and consistency. The implementation rules are set and validated by the following end-user tests. Depending on the scope of the adjustments, for example, between 1 and 3 weeks per cycle may be scheduled.

The requirements of the individual test runs can differ as follows to cover all factors:

• Technical validation
  The first test primarily serves as a technical validation: Are all tools available? Are users and authorizations set up correctly? Do the connections within the network work? Is the performance of the test systems sufficient?
• Testing the transformation
  Further tests then serve to test the transformation: Were all implementation rules defined? Can all business processes be executed without restriction? Can all end users find their bearings? It is particularly important for this user group to test all test cases thoroughly.
• General test
  The last test run before the cut-over is a general test that simulates the production conversion. Ideally, all steps of the production conversion are also carried out in sequence, even if this test requires 24-hour shifts over several days. You should be aware that test systems are usually set up on hardware with poorer performance than the target system. If hardware that approaches the performance of the production system is not available for a general test, you will need to account for this difference when discussing system downtime.

The actual goal of the many tests is the gradual adaptation and improvement of the transformation. During the tests, you may discover, for example, that conversion tables and rules still need to be fine-tuned. Some changes (for example, changes within the context of Customizing) only show their overall effects when merged for the first time in the tests. Further changes may subsequently be required.

The same applies to the impact of custom developments on the new system. Therefore, we strongly recommend repeatedly providing the test systems with current data from the existing production system in the case of longer test phases.

Be sure to plan the time and effort needed for the tests so that the employees required for the tests are also available at the right time. Changes to implementation rules or found errors often have to be discussed with the user departments, which can be a time-consuming process during the test phase. How time consuming depends on the complexity of the transition scenario and your company’s organization.

Similarly, your employees involved in basic administration tasks must be included, so that the test systems are always provided in a timely manner and can be set up again after each test run. Depending on the technology used to deploy your test systems, this process can take several days. Especially when large and/or highly integrated systems are part of the transformation, rather time-consuming tasks must absolutely be taken into account during planning.

12.2.4    Production Conversion

Once all the tests, including the general test, have been successfully completed, the next step is to convert the production system. Even if technically carried out over the weekend, the preparation for converting the production system often begins weeks earlier. Generally, all users of an affected system need to be informed of the potential downtime. Even if some employees were involved in the transformation planning, they never represent the entire user group for a system. Even for highly available systems or systems accessed from multiple time zones, overlaps exist, and every affected party must be aware that the transition will occur on the weekend scheduled.

A few days before the cut-over, final preparations are made, for example, last-minute adjustments to the transformation rules and the technical preparation of the production system. At this point, no more changes to the Customizing or to the program or ABAP changes can be made to the system.

The actual conversion on the weekend starts with blocking the system to all users except for users in the project team and the persons involved in maintaining the technical operation. Jobs in the SAP system are now deallocated, background programs are stopped, and interfaces are brought to a standstill. After the system has been isolated, a full backup is created so that, in the event of an emergency, the status before the transformation can be restored.

Next, you can optimize the system so that performance resources are fully available for the transformation. For many databases, you can, for example, deactivate database logging, thus achieving a significant increase in performance. While deactivating database logging does prevent a database recovery, an extra full backup should be prepared before the conversion. After completing the transformation, these settings should be reset for normal operations.

The main tasks at this stage are monitoring and the personnel process. On the one hand, current progress is monitored to continuously estimate the remaining downtime and identify problems at an early stage. On the other hand, a smooth process between the parties involved must be ensured. A clean handover between the project teams and their tasks without any loss of time is essential to meeting the cut-over schedule.

After the transformation has been successfully concluded, the validation and final acceptance test needs to be carried out by the end user. For this test, transactions are started and business processes are simulated in the system, system contents are checked based on lists, and test postings are carried out on the converted system. If no errors are found, the system can be released to all users. You should create a full backup at this point again so you have a starting point that captures the system immediately after the conversion.

12.2.5    Support after Go-Live

During this phase, the production system is still monitored closely for a few days after the conversion to uncover any sources of errors and to address these errors immediately if necessary. Furthermore, the development and quality assurance systems can now be converted. Depending on your requirements, transforming the test system can be carried out in parallel to the production system. Alternatively, you can also set up the test system using a copy of the production system. This decision depends on your individual conditions and the transition scenario.

Like the production system, the development system is converted through transformation. The amount of data is normally much lower, which significantly reduces runtime for the transformation. However, particularly for adjustments in Customizing, exact planning is required so that no obsolete settings are transported into the new production system later on.