SAP HANA is incredibly versatile. It can add value to a wide range of business scenarios, and it can be deployed in myriad ways to meet your project expectations and technical requirements. SAP HANA can also complement existing landscapes and replace outdated solutions.
With that versatility in mind, we’ll review four typical use cases for SAP HANA deployments today, as well as some of the potential scenarios for the future. These use cases are:
One way to quickly get the most value from in-memory technology is to use SAP HANA as a standalone data mart for a specific use case. In this scenario, SAP HANA acts as a central hub, collecting source-system data from multiple sources via in-memory technology and then displaying focused reports and analytics via a reporting front end. The data can then be used in multiple ways, depending on the organization’s reporting requirements and formats.
This arrangement has the advantage of providing a focused solution to an immediate business problem while minimizing disruption to the existing landscape. Such projects are usually completed quickly: The business problem is understood, and the required data and source systems are easily identified. Such installations offer instant value — making previously dificult and time-consuming tasks fast and easy.
SAP HANA is frequently used to accelerate transactions and reports inside the SAP Business Suite. As with the agile data mart scenario, SAP HANA is set up as a standalone system, side by side with the database under the SAP Business Suite applications. In this scenario, however, SAP HANA is used to “offload” some transactions or reports that typically take hours or days to run, though it is not used as the primary database under the application.
As explained previous field of topics, certain transactions or reports inside the SAP Business Suite can run slowly, primarily due to the slow I/O of the underlying disk-based database and the huge data requests required by these transactions or reports. To run its calculations and present a result, a typical budgeting or planning transaction in SAP must collect data from many different tables in the system. Reports can also be very data-intensive, requiring extensive data from many tables dispersed throughout the database. In both of these cases, the application must request the data from the database, load it into a buffer table in the SAP application server, run the algorithm or calculation, and then display the results to users.
To overcome system latency that slows down these common reports, SAP has developed “HANA fided” versions of several existing reports. These reports consist of three preconfigured reporting dashboards and 23 reports from the following business areas:
These dashboards and reports leverage existing reporting capabilities from SAP ERP. However, they offload the physical processing of the reports to a dedicated SAP HANA system that sits beside the live SAP ERP system. All relevant tables for each dashboard or report are physically copied from the SAP ERP system onto the SAP HANA system, which is then used to generate the reports and display them to users in a variety of user interfaces. Let’s review the key elements of each bundle.
The SAP HANA business content for Sales and Distribution (SD) enables sales managers and sales representatives to check basic key figures for sales in real time. Whereas sales managers use sales analytics to access instant overview information regarding the various performance indicators for their sales teams, the sales representatives focus on detailed information relating to the results of their sales activities.
The SAP HANA Financials content package provides the prerequisites for building reports that provide the following analysis data:
The purchasing content package for SAP HANA enables procurement managers to analyze key procurement processes in real time. Procurement managers use spending key figures along different dimensions including Material Groups, Vendors, Plants, and Purchasing Organizations to gain instant insight into inefficiencies that may point to savings potentials or internal and external process improvements.
Master data are essential for nearly all business transactions, irrespective of the business area. The master data in this package concentrate on master data objects that are available in SAP ERP, such as material, customer, and vendor.
The SAP HANA content for Shipping enables shipping and warehouse managers to check basic shipping and stock key figures in real time. Managers use shipping analytics to obtain instant information for planning and monitoring outbound delivery-related activities. In addition, the managers can get an up-to-date overview on materials stock at any time.
Imagine a “long-running” ABAP report within a particular business function, one that’s been an ongoing problem for users. As a result of system latency, many reports could not provide real-time data analysis — and therefore could not be used to make proactive business decisions. SAP HANA can reduce a report’s run time from several hours to minutes or even seconds, making the information much more current and valuable.
In our third use case example, SAP BW IS POWERED BY SAP HANA. In this scenario, a company replaces the previously underlying database for their SAP BW system with SAP HANA. The IT team can perform a standard DB migration over to SAP HANA and then enable specific objects to be in-memory optimized as necessary depending on the company’s requirements.
SAP BW is the first SAP application that was optimized to run with SAP HANA as its primary underlying database. With SAP HANA, SAP BW can leverage
in-memory capabilities for improved performance, without the need for any sidecar accelerators or extensive modeling workarounds. The entire database physically sits under the SAP BW system, eliminating the need for in-memory aggregation. This arrangement simplifies the data modeling and query design, which in turn greatly enhances system performance while lowering IT ownership costs.
Replacing an old database with SAP HANA generates speed and flexibility for two key reasons. First, keeping the entire database in memory eliminates the need to send large amounts of data between the application and DB servers, thereby reducing latency. In fact, running SAP BW on SAP HANA eliminates most of the problematic issues that slow down the system, from both a user and an administrator perspective.
As stated earlier, SAP HANA is a full-blown, do-just-about-anything-you-want application platform. It speaks pure SQL, and it includes all of the most common APIs, so you can literally write any type of application you want on top of it. There are a few rules and “guide rails” that are designed to keep things from going wrong. Overall, however, the sky truly is the limit when it comes to imagining what to build with SAP HANA.
Although SAP HANA is valuable for a broad range of applications, it “shines” particularly well in a few unique situations. If you’re building an enterprise-scale application for a business scenario that has high data volumes, needs detailed/granular data analysis, needs to search or aggregate huge data volumes, requires complex algorithmic or statistical calculations, or suffers from latency between transactional recording and reporting, SAP HANA is a great choice.
As SAP HANA matures and SAP updates its portfolio of solutions to take advantage of the extensive horsepower of SAP HANA, you can expect to see nearly every SAP product supported natively on SAP HANA as a primary database — plus many more “native SAP HANA” applications.
By now you must be having a good understanding of how typical use cases take advantage of SAP HANA. The next step is to ensure that you understand the best ways to deploy this new technology in your environment to drive maximum value.
Get Updates on Tech posts, Interview & Certification questions and training schedules