1. Define SAP S/4HANA goals
   Strategic goals in the context of the SAP S/4HANA transformation
2. Determining the ACTUAL state
   "SAP S/4HANA Readiness": Complete analysis and inventory
3. Understanding SAP S/4HANA
   Strategy & Movement
   Value Proposition & Scope
   Innovations & Simplifications
   Deployment & Switching Options
4. Define target state
   "SAP S/4HANA Readiness."
   Scoping & performing a gap analysis
   Determination & evaluation of optimization, consolidation and harmonization potentials
   Definition of deployment and change options
5. Define SAP S/4HANA Roadmap
   Creation of a roadmap taking into account dependencies in business and IT, and a budget and resource framework

The implementation of an SAP S/4HANA oadmap is characterised by three phases:

1. preparation

• Ensuring the commitment of decision-makers
• Start and maintain continuous change management at an early stage for all relevant stakeholders within and outside the project organization.
• Define project approach and project methodology along the SAP Activate Framework
• Develop project organization and project governance with roles and responsibilities
• Ensure availability of resource requirements
• Prepare project team
• Project management: Define and provide processes and tools

2nd SAP S/4HANA ERP implementation

• Carry out preparatory projects according to the project strategy and SAP S/4HANA requirements, e.g. master data cleansing, archiving, SAP Business Partner
• Execute SAP S/4 HANA ERP transformation project along the selected change option (New implementation, System Conversion, Selective Data Transition)

3. optimization / extension

• Optimization and enhancement projects after SAP S/4HANA ERP implementation e.g.
  • • Implementation of further SAP S/4HANA ERP innovations, e.g. SAP Fioris, embedded analytics
    • Implementation and integration of SAP S/4HANA cloud solutions e.g. SAP Customer Experience, SAP Ariba, SAP IBP
    • Implementation and integration of intelligent technologies, e.g. artificial intelligence, machine learning, IOT

Markets and companies are subject to rapid and continuous change. The resulting demands on the skill set of decision-makers and project participants are high. The implementation of complex transformation projects such as SAP S/4HANA can only be successful if the project organization and each project member has the role-specific skills and is well prepared.
The requirements are complex:

• Understanding and documenting integrated E2E business processes and industry specifics in the enterprise ecosystem
• Understand, formulate and prioritize strategic and operational business requirements
• Development, implementation and testing of valuable solutions and innovations
• Communicate with internal and external stakeholders
• Teamwork in complex, international project environments
• Preparing and making decisions, identifying and mitigating risks
• Understanding and applying new procedures, methodologies and tools

The opportunities of an SAP S/4HANA transformation are as exciting as they are unique - both for the company and the individual project member. Take up the challenge!

Forms have their very own significance in every company. For some it is a necessary evil in which only minimal time and effort is invested, for other companies it is an important opportunity for a professional image. In both cases it is true that these are usually important, regulatory documents where mistakes are annoying in the simplest case and leave a bad impression on customers.

However, there can also be noticeable consequences, for example delayed incoming payments due to invoices that are formally objectionable, or even worse. Since there is little potential for process optimization with forms, an architecture that is as maintenance-friendly and efficient as possible is necessary here. However, multilingualism, diagrams and extensive pricing can quickly lead to a high degree of complexity, and here too the tensions between old and new technologies are being bridged. SAPscript forms are usually very maintenance-unfriendly, but mostly still deeply anchored in the SAP standard.

Smartforms, on the other hand, offer much better possibilities in this respect, so that adjustments to the layout in particular can be carried out quickly. For more complex requirements, the most modern SAP product in this area - Adobe Forms - is usually a good alternative. In addition, third-party applications such as Lasersoft or StreamServe can also contribute to the efficient creation of forms. In any case, the development of forms deserves the greater attention of specialists in order to guarantee long-term resource efficiency.

User interfaces form the interface between each system and its users. Over the years, SAP has introduced many technologies in this area to the market. The screens already introduced with R/3 continue to be used as the main technology. Dynpro technology makes it possible to create complex dialog applications with quite simple means, but their maintainability and extensibility is often very time-consuming due to the obsolete architecture.

Newer technologies such as BSP/Web-UI or Web Dynpro are more flexible but technologically much more complicated. There are also numerous special technologies such as ITSMobile or Web Dynpro for Java. In recent years, Fiori and SAPUI5 applications have established themselves as one of the latest technologies, and this is where one of the central areas of conflict in dialog development becomes clear. On the one hand, there are users who have learned to work efficiently with existing screen applications over several years, sometimes decades, on the other hand, there are newcomers to the profession or users who only access the SAP system irregularly (the creation of vacation requests is a prime example).

For the second group of users, the usability of these applications is of great importance and can represent an enormous savings potential due to reduced susceptibility to errors or training requirements. It is therefore often not enough to rely on the absolute technical expert but the cooperation of experienced application specialists, UI designers and developers leads to optimal results. This applies all the more to the replacement of existing applications based on older technologies.

When implementing new applications, one of the central questions is often the choice between using SAP standard processes or developing your own with various available web frameworks. A general recommendation cannot be made for this decision and must be reassessed on a case-by-case basis. The respective general advantages and disadvantages are widely known.

However, the possibility of combining the advantages of both variants is rarely considered here. The flexibility and extensibility of web applications with the revision security and the extensive range of industry and accounting standards from SAP. This combination usually presents different challenges compared to a completely homogeneous system landscape. In particular, licensing issues as well as authorization and authentication can create greater difficulties on the SAP side. Problems in these areas can usually be solved quickly, but they are often show stoppers and can delay projects for a long time.

For example, the creation of a single-sign-on mechanism can be accomplished comparatively quickly in such a system combination by using standards such as SAML2, but can also reach a certain complexity when using SAML2 Bearer Assertions, since experts from the various system worlds have to coordinate their efforts.

A large number of interfaces, especially to external systems, are often seen as signs of high complexity and attempts are made to avoid them. Interfaces can also help to make existing media breaks in system landscapes less error-prone and to reduce manual activities. With the introduction of SAP UI5 as a new interface technology and the Netweaver Gateway as a new system component, interfaces in SAP systems are becoming even more important.

The general challenge is often to manage all these interfaces and maintain their compatibility with changes and upgrades. As in many other areas, there is a certain tension between long-established technologies such as ALE or EDI and the comparatively young OData interfaces. All these technologies still have their raison d'être and, depending on the application, it should be decided which technology is to be used when.

For example, the choice between SOAP or REST should not degenerate to a philosophical question, but should always try to find pragmatic and future-proof solutions.