SAP Target Architecture. A Process Based Approach.

The switch to SAP S/4HANA or the introduction of completely new SAP components is very often considered as an exclusive IT task and is accordingly planned as an IT project. In the beginning, it is often forgotten that this is much more than a purely technical system introduction (upgrade). In addition to technical changes, potential changes in the previous way of working due to new processes must also be taken into account.

The consequence of this is, that successful project implementation is dependent on knowledge and active cooperation, equally on IT and the relevant specialist department.

The following methodology is intended to serve as a lean, evolutionary option for architecture development, which primarily includes the active participation and cooperation of several parties, instead of relying exclusively on existing experts and wisdom.

Because of this, a corresponding project should be viewed and accompanied from the perspective of the following business units:

Specialist Department

“Applications are computer programs that perform useful functions for the user” (Wikipedia).

The user must define in which business processes, sub-processes of his activity the software should support him (which capabilities must the application include?).

Project Sponsor (Board of Directors, Management)

The development of a target architecture must be based on the support of senior management:

Guiding Principles

Reliable fundamental decisions must be made (e.g., what is the company’s cloud strategy?) .

Personnel expenditure

In total, a large number of employees are usually tied up in the project (even if not always full-time). This personnel expenditure must be known and approved.

Innovation pressure

Some customers take the target architecture as an opportunity to align their IT with it. For this, decisions must be made about the future direction of the company (e.g., from product to service provider).

IT-Department

Introduction/Operation

◉ Which applications (modules) are necessary?

◉ How/where should they be operated?

Migration (not part of the consideration of this blog)

◉ Which transactions still exist, are no longer necessary or have been simplified?

◉ What needs to be considered for the respective modules, functions and transactions?

◉ Examination of effects of the “custom code“?

◉ Changes in operation?

◉ Which functionalities can be found in which applications?

This list is not intended to be complete, but it illustrates the importance of each role/viewpoint for the success of the project.

The following steps show an example of a methodical procedure for developing a high-level target architecture based on the business processes used. A step-by-step approach, from the process to the correct technology (top-down). If all parties agree on the high-level architecture that has been developed, the next phase is to start refining/strengthening this architecture.

Procedure

Setting the Stage

What are we actually working on here?

All parties involved must be clear in every meeting about the expected goal before the target architecture can be worked out. For example, if one party in the room thinks we are working out the target architecture for the “SAP S/4HANA PoC” and the other assumes an “SAP S/4HANA Enterprise Architecture 2025” (which is exactly what happened to me, by the way), this can lead to very entertaining discussions.

NOTE:

1. The Goal: Define the goal concisely. Repeat the goal definition before each meeting to ensure clarity.

2. The Focus: We want to identify the correct technology via the process and the associated requirements.The currently used software or even the technical migration path must not play a role in this process (thematization during the migration discussion). Pay very close attention to this during the development of a target architecture and prevent discussions that go in this direction.

Guiding Principles

Guiding Principles are guidelines or fundamental decisions for the project. These are only 10-15 decisions that everyone thinks are clear anyway. On closer questioning, however, everyone has a different view of these “clear” rules.

Rule examples: Cloud first, data is an asset, data protection and privacy are key, one central ERP system, etc.

NOTE:

Write down these 10-15 rules. Designate a responsible person for every single rule (preferably a sponsor) who will take responsibility for them. Make these rules known to all participants and avoid that these rules are discussed anew in every meeting. Otherwise they will (you guessed it)….never get done.

Step 1 – Identification of the End-2-End business process

The identification of the business process(es) for which a target architecture is to be developed is elementary. Without this step, you will not be able to appoint the necessary experts in the company for the subsequent steps.

The “SAP API Business Hub”, with its SAP reference processes, supports the identification of the correct End-2-End business process: SAP API Business Hub

The outcome of this step should be to narrow down the End-2-End business processes to be considered:

Acquire to Decommission.

A sub-process of Design-to-Operate that captures the life of an industrial asset as it is received, incorporated, and maintained on site.

Idea to Market

A sub-process of Design-to-Operate that covers the necessary steps from the product idea to its transformation into a product design (including requirements).

Plan to Fulfill

A sub-process of Design-to-Operate that describes the path of product-related information through planning, manufacturing and logistics.

Lead to Cash

An end-to-end scenario from initial interaction to order fulfillment and service delivery.

Hire to Retire

A sub-process of the Recruit to Retire scenario that covers the internal employee cycle.

Travel to Reimburse

A sub-process of Recruit-to-Retire that covers your business travel – from planning to reimbursement.

Source to Pay with Central Procurement

A central procurement process that ensures end-to-end exchange of business documents.

Source to Pay

A process that covers strategic and operational procurement, from sourcing to procurement to receipt of goods and services.

Step 2 – From End-2-End process to business activity

Often, an entire End-2-End process with all its activities is not to be included in the consideration. The reference processes of the SAP API Business Hub and their associated documentation also serve to delimit the process.

The next levels of the End-2-End process (see the following Value-Flow-Diagram) help to identify the correct sub-process (modular), the business process segment, and the associated business activity (example of the End-2-End process “Plan to Fulfill”):

P2F – Value-Flow-Diagram

NOTE:

Identification down to activity level is usually very difficult to implement on the sole basis of a Value-Flow-Diagram. Ask your sales representative for support and organize a workshop between SAP and the process owners in which the overall or partial process is represented in the system.

Step 3 – Identification of the relevant applications and their relationship

 

Up to this point, the focus has been on identifying the business process, sub-process and activity, and thus on the perspective of the business department. The next steps transfer this result to the IT perspective and thus to the selection of the correct applications based on the result of the previous steps.

The “Scenario Implementation” point leads to a Solution-Architecture-Diagram (End-2-End business process), which shows the necessary components and their relationship to each other:

P2F – Solution-Architecture-Diagram

If a business process is not to be used in its entirety, the application belonging to the sub-process down to the activity-level can be identified starting from the Value-Flow-Diagram via the Software-Collaboration-Diagram.

P2F – Software-Collaboration-Diagram

Step 4 – The Platform

The previous steps represent a simple way of identifying the required applications based on the business processes used. Furthermore, it must be remembered that there are also key issues that may not be considered through this route but have a potential impact on the overall architecture.

Further potential questions:

◉ What is my data warehouse strategy?

◉ Do I have an integration strategy?

◉ What is my master data strategy?

◉ How does my master data organisation look like?

◉ What other applications need to be integrated into the processes (the world is usually not only SAP)?

◉ What are my financial consolidation and planning requirements?

◉ Do I need a solution for government communication?

◉ Does the architecture meet the requirements of the DSGVO (GDPR)?

◉ How do I implement custom developments/adaptations?

Again, this list is not intended to be complete, but rather thought provoking. Further ideas, including solution diagrams, can be found via SAP Missions: SAP Missions

Step 5 – The Unification

 

Different applications as well as their relation have now been identified via one or mostly several processes/subprocesses and platform requirements. In order to create and display a customer-specific architecture diagram from this, I recommend using the SAP Cloud Platform Solution Diagrams&Icons: SAP Cloud Platform Solution Diagrams