In recent years, large organizations have seen a resurgence taking on major SAP upgrades with the relatively new SAP business suite 4 HANA (S/4HANA) collection of applications. But what exactly is HANA? And what is S/4HANA? How is implementing or upgrading to it different from the R/3 upgrades that were significant programs for many organizations over the last few decades? As SAPs core products have advanced and their portfolio has broadened, it’s become difficult to understand how it all fits together.
In recent years I’ve met team members and stakeholders working on SAP programs who struggled to articulate the basics of HANA. SAP projects can be complicated and challenging, partly due to this lack of knowledge. SAP has been addressing this by improving their communications and training, but understanding HANA can still be quite a lot to navigate. In this article, I’ll briefly explain the history of SAP and the context that led to HANA as well as clarify the technical concepts behind HANA, why they are essential, and how the business application has changed.
A brief history of SAP and ERP
SAP has an extensive portfolio of applications. If we stick to the leading enterprise resource planning products, we can abbreviate the company’s history to six essential versions, roughly a major iteration each decade.
R/1
Let’s start from the beginning.
Some ex-IBM employees founded SAP in the early 1970s. Their first system was called RF (real-time financials) and was later re-named R/1. SAPs product strategy was based on three main concepts:
- Provide a standardized ‘of the shelf solution’: when many companies were building their applications from scratch SAPs plan was to create a software product that worked for many companies only with the minor configuration;
- Real-time: information entered into the application is available across the entire application in real-time;
- Integrated: the same data is shared across multiple functional parts of the system, reducing the need for redundant data entry.
What exactly does real-time integration mean?
Consider an example from manufacturing. Raw materials are converted to finished products and sold and shipped to a customer. This process involves many departments; procurement, warehousing, construction, finance, sales, etc. If we consider only a part of this, the receiving of raw materials from a supplier requires two activities.
Before ERP, these activities may have been done separately. For example, warehouse management may have updated their inventory list at the end of the day and then sent a copy of the information for finance to update the accounts. Throughout the day, inventory and financial information would not have been up to date or aligned. And the effort has been wasted entering the same data twice.
With ERP When warehousing update inventory, the accounting records are updated automatically in real-time. Under the hood, ERP has many connections across different tables that keep information in sync for various functions and teams.
Once we understand this, we know the value of ERP systems and why they became so popular. We can start to imagine how complex they are as they connect processes and data across the entire enterprise. Take the simple example above and imagine how the same logic could be applied across sales, marketing, production, etc.
R/2
Moving onto 1979, R/2 was released.
The switch from R/1 to R/2 was a more subtle evolution from a technical perspective, with increases in the core functionality as SAP started to increase their customer base.
I can’t write too much about R/1 and R/2. When I started my career in an IT team in 2000, R/2 was on the way out. I was trained in using AS/400 mainframe and R/2, but I had only a short time to use it. Most of my experience of R/2 is extracting data from it to cleanse before loading to R/3!
R/3
We are moving onto the 90s and R/3.
The switch from R/2 to R/3 was significant with some significant changes:
- R/1 and R/2 are classed as mainframe systems and R/3 as a client/server system. Skipping the technicalities, this allowed for:
- A fuller ‘graphical user interface’ on desktops (i.e., windows desktops or laptops);
- Cheaper, more easy to scale, and more flexible set up the server-side (note: some complex debate exists on some of these).
- The shift from R/2 to R/3 and the ongoing development of R/3 through the 90s also represented significant expansion in the business processes covered.
R/2 and R/3 are very different systems. To switch from one system to another, you need to extract and transform data before loading to R/3; you also have to map all processes. In my experience switching from R/2 to R/3 was similar to changing from a non-SAP system to R/3. In the 2000s, I managed several upgrades from R/2 to R/3 as well as upgrades from mainframe systems like BAAN, and the approach and work involved were similar.
When talking about R/3, it’s also important to consider scale and globalization. Mainframe systems were typically implemented for a single country or business unit. The cheaper, more scalable architecture of R/3 provided an opportunity to implement one R/3 system covering an organization’s business across an entire region or the world. This is important as it’s one of the factors which lead to more significant data volumes and more performance challenges.
R/3 was evolving year by year as a complex, integrated system used in large organizations on a global scale. This set’s the scene for what is to come with HANA.
A note on R/2 vs. R/3 look and feel.
For a simple illustration of how different R/2 and R/3 are, we can look at a couple of screens.
- R/2 has a straightforward interface where function keys and codes are used to navigate between fields;
- R/3 includes menus, tabs, buttons, ‘help lookups’ etc.
We will see that there is also a significant jump in how SAP looks and feels between R/3 and S/4HANA.
A note on R/3 process scope
This is a diagram that anyone that worked on R/3 will fondly remember; it outlines the different modules or ‘functional areas’ covered by R/3.
While ERP and R/3 may seem complicated, and it is, all it does is record business activities by entering transactions in a system and having the information about what happened stored in a database. It then lets you view and adjusts that information to manage your enterprise. Here are some simple examples for a few of the modules shown above:
- FI – finance
- Record periodic accruals.
- CO – controlling
- Record/view expenditure against a department
- SD – Sales and Distribution.
- Record a sales order for sale to a client
- PP – Production Planning.
- Plan a production schedule
- HR – human resources
- Pay employees.
mySAP.com and ERP
When we come to 2000, branding becomes a little confusing.
There were several key focus areas, and we saw R/3 being referred to as mySAP.com and also ERP (technically ECC). The noteworthy focus was:
- The emergence of web technologies and the need for ERP to be able to connect on a B2B or B2C basis via the internet, mySAP.com was used as a brand, and various integration technologies were available.
- An increasing number of ‘add on’ products for data analysis;
A note on data analysis
R/2 and R/3 are technically optimized as systems to record data. They are not optimized to analyze data. The late 90s saw the release of the first business warehouse system (BW). This system is technically architected to analyze data. Organizations would use ERP to record data and carry out simple real-time reporting and then send data in daily batches to BW for more sophisticated analysis. I’ll come back to this with an illustration later.
A note on acquiring competitors
During this period, there was a boom in niche software providers, particularly in data analytics. SAP took the opportunity to acquire some leading competitors to cover regions where their applications were weaker, such as this cover:
- Analytics, planning & reporting – e.g., Outlooksoft, Business Objects
- User experience & process execution in niche process areas – e.g., SuccessFactors, Concur, Ariba.
Interestingly, with the addition of the business warehouse, the SAP solution was no longer a real-time integrated architecture.
Furthermore, the architecture for many companies was becoming somewhat convoluted with many different applications from different providers. This leads to a lot more solutions in areas like interfacing and master data management.
Business suite
During the 2000s, the number of processes covered by the R/3 or ERP was continuously increased. In addition to that, several additional applications were launched to provide more advanced capabilities in certain areas. SAP started to package a number of these together in the late 90s under the name “business suite.” The main components of the business suite are:
- ERP (enterprise resource planning):
- The evolution of R/3 – the core of business suite, including financials, human capital management, operations, corporate services, etc.
- CRM (customer relationship management):
- Sales, marketing, and service.
- SCM (supply chain management):
- Procurement networks, production networks, distribution networks, planning, organization, and execution of supply processes.
- PLM (product lifecycle management):
- Product ideation to production.
- SRM (supplier relationship management):
- Procurement for materials, goods, and services. Requirements determination to ordering to payment.
A note on OLAP vs. OLTP
As mentioned, a significant issue that existed with R/3 was the inability to handle reporting for increasing data volumes, especially with the growing demand for quick analysis. R/3, as a system, is not designed to scan data. This led to the development of stand-alone systems such as SAPs business warehouse that were optimized to read data. The following terms were used to describe these two different types of systems:
- OLTP – online transaction processing (e.g., R/3)
- OLAP – Online analytical processing (e.g., BW)
As a result of this, large organizations often ended up with systems landscapes that include multiple OLTP systems and various OLAP systems all connected. And this is before we even consider topics such as web applications, big data, etc.!
Increasing complexity
Before the launch of HANA, it’s useful to reflect on where the SAP portfolio was:
- The core of ERP has been developed over decades with a continuing increase in volume, the complexity of processes covered;
- Multiple industry-specific solutions were also available;
- Requirements for many geographies were covered;
- There was a split between applications for recording transactions (OLTP) and carrying out simple reporting and applications for information analysis (OLAP). Real-time integration was not present across the entire range of applications;
- The product portfolio became huge due to multiple new products being developed by SAP and in part by a large number of acquisitions;
- Significant advancements in the standards and approach to integration and web technologies over the years.
Altogether the complexity of business systems landscapes has been massively increasing since the mainframe days. I think this is a topic that is not addressed as much as it should within architecture plans, while we should embrace new technologies we should also rationalize old technologies.
It brings us to the 2010s, where a part of SAP’s focus is on reducing the complexity of core products while also continuing to advance in new technologies. HANA plays a significant role in reducing complexity and bringing real-time back to include analytics capabilities.
S/4HANA
It brings us to the question of what is S/4HANA? It stands for “SAP business suite 4 SAP HANA, and it’s a collection of different things. It’s one of the reasons why HANA is not well understood. It can’t be correctly called either a technical upgrade or a functional enhancement; it’s a combination of the two. Furthermore, as part of a S/4HANA conversion, there are a lot of optional items. Each company needs to define its scope for a S/4HANA conversion based on their objectives.
In this article, I’ll cover three main building blocks of S/4HANA. These are:
- The HANA platform (or HANA database) – a new database that solves the problems faced by ERP;
- S/4HANA (i.e., the HANA business suite) – an updated version of business suite 7 taking advantage of the benefits of the HANA platform;
- Fiori – a new approach to UI with more focus on flexible app style development and mobile.
In this post, I’ll spend most of the remaining time explaining the HANA platform and its impacts on business suite, which I think is not commonly understood. For the business suite and Fiori, I’ll give a brief overview as these topics are quite deep, and SAP has plenty of available information. Plus, when looking at these topics, it needs to be done piece by piece, e.g., by function or UX case.
The HANA platform
Understanding memory
To understand HANA, we need a little consideration of how memory works on a computer. Bear with me; it’s not that technical!
The main constraints were the cost of processing power and storage. The hardware limitations led to limitations in the logic of the software, which led to a number of the problems that we have already discussed above.
However, considering Moore’s law, the increases in processing power and storage and reduction in hardware costs allowed SAP to re-think the architecture of ERP. It brings us to HANA.
HANA is the term used to refer to a new database whose development was led by one of the founders of SAP. HANA stands for:
- Hasso’s New Architecture ;
- (Hasso Plattner is one of the five founders of SAP);
- alternatively, “High-Performance Analytical Application.”
You can learn about HANA from Hasso himself on the open learning platform from the Hasso Plattner Institute for software systems engineering (note this is very technical, only for people who love databases I guess!):
https://open.hpi.de/courses?lang=en.
Three key features allow the HANA platform to solve the problems ERP and BI face:
- In-memory computing;
- Columnar database managemnet & data compression;
- Parallel processing.
We will take a look at the first two topics to understand better what HANA is. The third, parallel processing, is a fairly common concept where modern computers can use multiple processors simultaneously on an operation.
How memory works
To start the explanation of how HANA uses memory, let’s consider the example of a regular desktop computer. Memory can be categorized into three types:
- Auxiliary memory: the most significant and cheapest memory. Either magnetic disk or solid-state drive. Data is retained when the power is off. To write or read information is extremely slow;
- Main memory: mostly made up of RAM, more expensive, but much faster than auxiliary memory. Information is lost when power is off.
- Cache memory: A small amount of high-speed memory close to the CPU that stores data the CPU is currently using.