Anthony Cecchini is the President and CTO of Information Technology Partners (ITP), an ERP technology consulting company headquartered now in Virginia, with offices in Vienna. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. ITP is an Appian and Pegasystems iBPM Low-code and RPA Value Added Service Partner. You can reach him at [email protected].
As the name suggests, SoH is the traditional SAP ECC solution available on SAP HANA. It has all of the traditional functionality of an ECC environment but the engine (database) is now a HANA engine. Nearly all of the SAP transaction codes are available but there is no concept of data simplification. Access to the HANA live studio gives an ability to create real-time reporting. The solution also boasts amended transactions to utilize the HANA database and provide additional performance benefits.
The roadmap to Suite on HANA is pretty simple. You need to upgrade to ECC6 Enhancement Package 7 and then perform a database migration from your current database to HANA. This is generally a technical exercise and can be achieved without too much business involvement.
By running on HANA, the Business Suite performs faster because it is working inside the memory component. You will have the same functionality as if you were running ECC on a traditional disk database. We’ll post a new article shortly showing the differences between SAP Business Suite and Suite on HANA with S/4. For now, let’s take a look at what you can do with the basic set of tools.
The HANA database operates as the backend and the Business Suite operates as the frontend. HANA is a column-based relational database management system (RDBMS) that does what all databases do – it allows the ability to store, retrieve, and process data. However, HANA is faster than traditional databases at online transaction processing (OLTP) and online analytical processing (OLAP). HANA is faster because it runs in memory rather than on a hard drive. SAP designed HANA to leave a lower memory footprint by simplifying its structure.
Instead of running OLAP and OLTP in separate databases, HANA reduces the redundancy and runs them together in memory. Running OLAP and OLTP as columns cuts memory usage by a factor of 10 or more leading to faster performance.If you need a refresher on HANA and especially if your an ABAP developer, please take a few minutes and read this post – The ABAP Developer Road Map to SAP HANA
This unique architecture means that SAP HANA can almost process data instantaneously. The ability to do real-time analytics makes HANA extremely attractive as the Internet of Things (IoT) and big data require organizations to crunch huge amounts of data as quickly as possible. The strategic benefits of instantaneous data processing are obvious. Take a look at the evolution of analytics below…
At a very high level, there are no functional changes. So the way we configure inside the IMG stays the same, transports using CTS stays the same, the ABAP workbench is the same, and the DBA Cockpit and Solution Manager will stay the same.
There are some technical changes. So for instance Pool and Cluster tables are not supported, so they will be converted to transparent tables during migration. All row tables that contain transaction data will be converted to column tables. I believe the Metadata tables (Customizing) may still stay as row tables. Modifications are impacted, with objects using BAdi’s and BAPI’s in the SAP name space, it is possible (depending on the design) that there is a negative impact on the performance. In this case the custom coding in the user exit might need to be adjusted as SAP will provide HANA optimized versions of some existing ABAP programs, to which the BAdi’s and BAPI’s will need to be pointed to. With regards to z-programs, SAP offers the SQL Run Time Monitor tool which you can run prior to migration on your Oracle-based system. The performance tuning worklist in transaction SWLT will provide optimization opportunities for z-programs. Again this is covered extremely well in our post – The ABAP Developer Road Map to SAP HANA
As far as the GUI is concerned, SAP has provided a detailed roadmap for the user interfaces in general under the theme: New, Renew, Enable!you download the deck HERE.
Some new UI’s are provided with the new Suite on HANA transactions as well, some new interfaces are provided with the Enhancement packages. HTML5 options are delivered for the SAP HANA Live analytical applications. And lets not forget about Personas and Fiori.
I sometimes here that the speed increase is minimal. OK, Lets look at this from a different perspective…
No customer of a SAP ERP, CRM, SCM, etc system would accept if performance degrades after a maintenance cycle by as little as 10% right? Well then by moving to SAP Suite on Hana, it is estimated that we can expect an an increase of a factor two in OLTP and a factor 10 to 100 in OLAP . Why wouldn’t that increase be welcome? Isn’t Speed is the number one reason for business processes to be supported by information technology.
Just to name a few:
- earlier period closing
- better forecasting
- allow real-time planning, execution, reporting, and analytics on live data.
- better service level in the customer facing applications
The speed allows us to simplify not only how we run the applications but how we use them. We can unlock new growth opportunities first. Rethink business processes as needed and invent business models.
Another benefit is limited business involvement. Moving to Suite on HANA enables discreet technical steps to be performed prior to the move to S/4HANA. It is quicker and therefore cheaper than the cost of moving direct to S/4HANA. The business’s involvement in moving to Suite on HANA is fairly limited compared to an S/4HANA project and you will also save yourself from going through an additional number of technical processes that are required to move to S/4HANA.
As I mentioned above most of the SAP transaction codes are valid on Suite for HANA. The same goes for most of the most popular SAP applications including CRM, PLM, SCM, and the Data Warehouse. You will also be able to access Business Objects Enterprise, Data Services, and Lumira once you migrate to the HANA platform. SAP is moving more of its cloud portfolio onto HANA so you will also have access to the HANA Cloud Platform interface. Here’s a starter list of some of the applications in alphabetical order (including those I’ve already mentioned):
- Accelerated Trade Promotion Planning
- Assurance and Compliance Software
- Business Objects Enterprise
- Collection Insight
- Convergent Pricing Simulation
- Customer Engagement Intelligence
- Customer Relationship Management (CRM)
- Demand Signal Management
- Data Services
- Data Warehouse
- Fiori applications
- Liquidity Risk Management
- Lumira
- Operational Process Intelligence
Summary
SAP Suite on HANA can help customers simplify IT by bringing together analytics and transactions for reduced total cost of ownership. Since SAP HANA provides a unique ability to deal effectively with both transactional and analytical workloads, SAP Suite on HANA can help customers achieve dramatic simplification of their IT landscape. In this integrated scenario, SAP HANA can be used as a primary database for SAP Business Suite applications. Since the same database is used for both analytical and transactional needs, there is no need for any replication of data.