Rather than being the Big Bang, migration to S/4 on Hana 2 follows a process of evolution. [shutterstock: 248406532, Ollyy]

Rather than being the Big Bang, migration to S/4 on Hana 2 follows a process of evolution. [shutterstock: 248406532, Ollyy]

Hana 1, 2 and S/4: Big Bang or Evolution?

With the introduction of Hana 2, SAP customers have been presented with a further challenge on the road to S/4. In an exclusive interview with E-3, Hinrich Mielke, SAP Director at Alegri, explains the pros and cons of possible switchover scenarios.

What are your recommendations for embarking on the road to S/4? Is a Group strategy needed or should the accounts department start the ball rolling with S/4 Finance?

Hinrich Mielke: To realize the potential involved in the migration to S/4 Hana, converting ECC 6.0 to S/4 Hana is a business process optimization – possibly even a re-engineering – project. The use cases which then become possible and profitable are customer-specific and always call for a group strategy geared towards the objectives and purpose of the project which can then be tackled effectively. Coordination with the experts leads to the first use cases.

It starts in the accounting department, for example, or in a division of the company that acts as the guiding light, so to speak. The credo is always: “Think big, start small.” A big bang will rarely be compatible with a customer situation.

The S/4 roadmap for adapted and new business processes is still in the making. When and how will a Fiori roadmap be drawn up?

Mielke: The customer-specific Fiori roadmap follows the Group and S/4 Hana strategy. If new types of consumers are envisaged (e.g. at a car manufacturer’s plant), Fiori must be designed differently than, for example, if the aim is to provide a purchaser with an “information worker” interface for his tasks and to increase efficiency. In such a case, integrating Fiori elements and information from a SharePoint might be the right solution.

ad_banner

“The new workflows are no longer geared to transactions but instead to processes and user requirements.”

What is the greatest challenge for new S/4 Hana users: adapted business processes or a new UI?

Mielke: If the new paradigms are followed and S/4 Hana is implemented in its entirety, the business and work process changes intrinsically. The new workflows are no longer geared to transactions but instead to processes and user requirements: This calls for some re-thinking, especially by experienced users. This change in approach is mapped by Fiori. The SAPGui can still be used for existing transactions which means a continual change process can be designed for users.

The platform for S/4 is always Hana or Hana 2 – What differences are there?

Mielke: SAP Hana 1 will have bug fixes but no new features. It is a “stable release” so to speak. Hana 2 is the next step here and takes the Hana platform to a new level, ready for new business requirements such as IoT and technological efficiency such as Active/Active read-enabled scenarios. The very interesting Hana Cockpit 2.0 comes with Hana 2 and, according to Alegri studies, represents a significant step forward.

What does Alegri recommend – Hana or Hana 2 – and why?

Mielke: At present, Hana 1 is to be used for Suite on Hana. Current projects with S/4 Hana are generally still built on Hana 1 and will not change a stable base in the short term without good reason. But as there will be no SPS13 for Hana 1, customers are urged to switch to Hana 2 in the medium term anyway. Hana 2 should thus be the choice in newly launched S/4 Hana projects. Hana 2 will be needed as a foundation in future releases of S/4 Hana.

Is it also possible to change from Hana to Hana 2? Pros? Cons?

Mielke: Hana 2 is the next technological step, is built on SAP Hana 1 and is backward compatible. The change is similar to the upgrade of a new SPS for the Hana database. The technological risks and steps are identical as well as the testing efforts. But in the case of older source systems it might be wise to first switch to SAP Hana 1 SPS12 as an intermediate step. However, because “datacenter service points” are no longer needed, the right time and the right package must be individually established for productive environments.

What license differences are there between Hana and Hana 2 and how can the SAP customer reach a decision?

Mielke: SAP Hana licenses depend on the type of use and the database functionality used as well as on the SAP application. The license required for SAP Hana 2 is intrinsically no different to the one needed for SAP Hana 1, although Hana 2 provides new use options in the area of integration which might be subject to additional licenses. As a rule of thumb, we can say: whatever is contained in Hana 1, SPS12 will not be subject to further licenses in Hana 2. The needs and use of the licenses for Hana 1 or 2 can be established after prior investigation.

” From our experience, up to 85 percent of the Z programs/modifications are not used!”

SAP customers will probably be able to get along without some Abap enhancements. But what will happen to the essential Z functions?

Mielke: From our experience, up to 85 percent of the Z programs/modifications are not used! A temporary discontinuation and then an expansion makes sense here. The remaining ones will be converted and adapted. This is why an automated use analysis is very useful so that vital tasks are preferably carried out. Within the framework of the “Hana Readiness Audit”, Alegri thus offers an automated use analysis of in-house developments as well as an impact analysis of the used transactions.

To what extent does the “conversion” take account of Z namespace and Abap modifications?

Mielke: The conversion includes all the Z programs and modifications. Smooth functioning is ensured in the project and may make adjustments necessary. The ensuing need for adjustments can be identified and carried out in advance, which is why it is so important to carry out a use analysis beforehand.

What experience does Alegri have in terms of project time and costs for the S/4 conversion?

Mielke: This always depends on how much an existing system was expanded or modified. In a current customer project, we are converting an existing ECC 6.0 system to S/4 Hana within a period of three months. This system is close to standard and can thus be converted within 15 person months in total.

Apart from business processes, data also has to be migrated: What must the SAP customer know and bear in mind with regard to data convergence?

Mielke: The simple conversion of data to S/4 Hana is not critical; of greater interest are the future cross-system processes and information sources. To ensure use is clear and transparent, new methods are needed which should be implemented at the same time as the new options. Enterprise Information Management will play a significant role in companies, which means that the data, processes and organizational requirements must be examined.

” The interfaces for data exchange will change and have an impact on optimum architecture.”

To what extent is it necessary to take account of the S/4 architecture for the purposes of data convergence?

Mielke: An important question! The interfaces for data exchange will change and have an impact on optimum architecture. That must be taken into account at an early stage. The architecture used for integration must be defined as early as possible. This can, for instance, be the HCI, Hana standard features (e.g. virtual tables) or an on-premise PO might emerge as a good solution, although a mixture of these options might also be the right way to go.

What are the essential differences in data storage between a classical database and the in-memory computing concept of Hana?

Mielke: One significant difference (in addition to the known in-memory concept) is that with dynamic tiering, it is possible to distinguish data as “hot”, “warm” or “cold”. This means the database defines the storage location of the data. For the application this provides transparency: There’s a table and it is not necessary to distinguish between physical storage locations. Costs can be easily and elegantly optimized, e.g. for data that still can’t be archived after many years. In addition, due to the internal transparent compression, a denormalization of database structures can be carried out.

In a future S/4 Hana architecture is Hana or Hana 2 sufficient? Or are Sybase IQ, Hadoop etc. also needed?

Mielke: Future S/4 Hana architectures will in principle be based on Hana.  The aim is not to have any other database systems in use. Depending on the landscape, purpose and capacities, a real landscape will normally use further data repositories held by customers themselves, e.g. APO with the LiveCache. Hadoop is ideal for large quantities of data. Several customers already use Hadoop, independently of ERP.

To summarize: Will master data management be easier or more complex under (Hana) S/4 compared with a SAP Business Suite 7 on AnyDB?

Mielke: To leverage the potential of S/4 Hana, user expectations and thus the coordination required for master data management will increase. It will thus probably become more complex because MDM will now touch on more areas than before. Hana is the technological foundation for many innovations and improvements based on better performance such as the search and comparison of master records or similarity analyses.

You might also like

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *