Big Bang or Evolution?


What do you recommend for the path towards S/4? Do you need a corporate strategy or do you start in accounting with S/4 Finance?
Hinrich Mielke: In order to realize the potential of the change to S/4 Hana, the conversion from ECC 6.0 to S/4 Hana is a project for business process optimization, if necessary even for business process redesign.
The use cases that are possible and profitable as a result are customer-specific and always require a corporate strategy on the goals and intent of the project. After that, it can be approached in a goal-oriented manner.
Coordination with the business side leads to the first use cases. Then, for example, a start is made with accounting or with a business unit that acts as a beacon. The credo is always: "Think big, start small." The big bang will rarely fit the customer situation.
The S/4 roadmap in terms of adapted and new business processes is a construction site, when and how does a Fiori roadmap emerge?
Mielke: The customer-specific Fiori roadmap follows the corporate and S/4 Hana strategy. If new user layers are envisaged (e.g., in the plant of an automotive manufacturer), Fiori must be designed differently than if, for example, a buyer is to receive an information worker interface for his tasks and to increase efficiency. This is where an integration of Fiori elements and information from a SharePoint can be the right solution.
What is the bigger challenge for new S/4 Hana users: the adapted business processes or a new UI?
Mielke: If one follows the new paradigms and implements S/4 Hana in its entirety, the business and work process itself changes. These new workflows are no longer transaction-oriented, but are based on the process and user requirements:
A change in thinking is required here, especially for experienced users. This changed approach is mapped by Fiori. The SAPGui can still be used for the existing transactions, so that a continuous change process can be designed here for the users.
The platform for S/4 is always Hana or Hana 2 - what are the differences?
Mielke: SAP Hana 1 will receive bug fixes, but no new features. It is the "stable release" so to speak. Hana 2 is the next step here, taking the Hana platform to a new level, ready for new business requirements such as IoT and technological efficiencies such as active/active-read-enabled scenarios. The highly exciting Hana Cockpit 2.0 comes with Hana 2 and is a significant step forward, according to Alegri research.
What does Alegri recommend and why - Hana or Hana 2?
Mielke: For Suite on Hana, Hana 1 is currently to be used. Current projects with S/4 Hana are generally still based on Hana 1 and will not change a stable basis in the short term without compelling reason.
However, since there will be no SPS13 for Hana 1, customers will be required to switch to Hana 2 in the medium term anyway. Thus, Hana 2 should be the choice in newly starting S/4 Hana projects. In future releases of S/4 Hana, Hana 2 will be required as a substructure.
Is it possible to switch from Hana to Hana 2? Advantages? Disadvantages?
Mielke: Hana 2 is the next technological step, builds on SAP Hana 1 and is backward compatible. The changeover is analogous to the upgrade of a new PLC for the Hana database. The technological risks and steps are identical, as is the testing effort.
For older source systems, however, an intermediate step to SAP Hana 1 SPS12 may make sense. However, since the "Datacenter Service Points" are no longer required, the right time and the right package for the change must be determined individually for productive environments.
What are the license differences between Hana and Hana 2 and how can the existing SAP customer come to a decision?
Mielke: SAP Hana licenses depend on the type of use and on the database and SAP application functions used. SAP Hana 2 does not in itself require a different license than SAP Hana 1, but Hana 2 introduces new uses in the integration area - which may require additional licenses.
As a rule of thumb, what is included in Hana 1, SPS12 will not require further licensing in Hana 2. The needs and benefits of licenses for Hana 1 or 2 can be determined based on a corresponding preliminary investigation.
Every existing SAP customer can probably part with some Abap enhancements. But what happens to the indispensable Z-functions?
Mielke: From our experience, up to 85 percent of Z programs/modifications are not used! Here, a temporary shutdown and then an expansion makes sense The remaining ones are converted and adapted.
Therefore, an automated usage analysis makes a lot of sense, so that the indispensable work is carried out preferentially. Alegri therefore offers an automated usage analysis of its own developments as part of the "Hana Readiness Audit" - as well as an "Impact Analysis" of the transactions used.
To what extent does the "conversion" take into account the Z namespace and Abap modifications?
Mielke: The conversion takes all Z programs and modifications with it. Proper functioning is ensured as part of the project and may require adjustments. The resulting need for adaptation can be identified and carried out in advance, which is why the previous usage analysis is so important.
What is Alegri's experience in terms of project time and cost regarding S/4 conversion?
Mielke: This always depends on how much a system has been expanded or modified. In a current customer project, we are converting an existing ECC 6.0 system to S/4 Hana within a project duration of three months. This system is close to the standard and can thus be converted with a total of 15 person-months.
In addition to the business processes, the data must also be moved: What does the existing SAP customer need to know and observe with regard to data convergence?
Mielke: The mere conversion of data to S/4 Hana is not critical; more exciting are the future cross-system processes and information sources. New methods are required for comprehensible and transparent use, which should be implemented at the same time as the new possibilities are realized.
Enterprise information management will take on an essential role in companies; here, the data, the processes and also the organizational prerequisites must be illuminated.
To what extent must the S/4 architecture be taken into account for data convergence?
Mielke: An important question! The interfaces for data exchange will change and influence the optimal architecture. This must be taken into account at an early stage. The architecture on which the integration will be performed should be determined as soon as possible.
For example, this can be HCI, Hana on-boarding resources (e.g., virtual tables) can be used, or an on-premise PO can emerge as a good solution. Likewise, a mix of these options may be optimal.
What are the main differences in terms of data management between a classic database and Hana's in-memory computing concept?
Mielke: A significant difference (in addition to the well-known in-memory concept) is that dynamic tiering makes it possible to differentiate data into "hot", "warm" and "cold". This means that the database determines the storage location of the data.
This is transparent for the application: there is one table and there is no need to differentiate between the physical storage locations. Costs can be optimized simply and elegantly here, e.g. for data that cannot be archived even after years.
On the other hand, a denormalization of the database structures can be performed due to the internal transparent compression.
In a future S/4 Hana architecture: Is Hana or Hana 2 sufficient? Or does it also need Sybase IQ, Hadoop, etc.?
Mielke: Future S/4 Hana architectures will basically be based on Hana and the goal should be to have no other database systems in use. Depending on the landscape, purpose and capacities, a real landscape at customers will usually use other data pots, e.g. there is APO with LiveCache. For big data, Hadoop is a good choice. Hadoop is already in use at some customers, independent of ERP.
And in summary, will Master Data Management under (Hana) S/4 be simpler or more complex compared to SAP Business Suite 7 on AnyDB?
Mielke: In order to exploit the potential of S/4 Hana, the demands of users and thus the coordination effort for master data management will increase. It will therefore tend to become more complex, because MDM will now touch even more areas than before.
Hana is the technological basis for many innovations and improvements due to better performance such as search and matching of master records or similarity analyses.