As a quick introduction, this is my first community post. I've been working on SAP projects since 2000 when I led R/3 implementations at Procter & Gamble. I'm a strong believer in building expertise in people, process and systems and I put together this post to help address the lack of contextual understanding surrounding S/4HANA that I observed with some colleagues in the last year or two. I hope this is useful.
Recent years have seen a resurgence in large organisations 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 complex 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 hence the context that led to HANA as well as clarifying the technical concepts behind HANA, why they are important, and how the business application has changed.
SAP has a large portfolio of applications. If we stick to the main enterprise resource planning products we can abbreviate the history of the company to six key versions, roughly a major iteration each decade.
Let's start from the beginning.
SAP was founded by a number of ex-IBM employees 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:
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, manufacturing, finance, sales etc. If we consider only a part of this; the receiving of raw materials from a supplier, two activities need to occur.
Prior to 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 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 a lot of connections across different tables that keep information in sync for different functions and teams.
Once we understand this we understand 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.
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. In fact, most of my experience of R/2 is extracting data from it to cleanse before loading to R/3!
Moving onto the 90s and R/3.
The switch from R/2 to R/3 was significant with a number of major changes:
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 switching 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 was similar.
When talking about R/3 it's also important to consider scale and globalisation. 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 organisations business across an entire region or the world. This is important as it's one of the factors which lead to bigger data volumes and more performance challenges.
R/3 was evolving year by year as a complex, integrated system that was being used in large organisations on a global scale. This set's the scene for what is to come with HANA.
For a simple illustration of how different R/2 and R/3 are we can look at a couple of screens.
We will see that there is also a significant jump in how SAP looks and feels between R/3 and S/4HANA.
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 complex; 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 adjust that information to manage your enterprise. Here are some simple examples for a few of the modules shown above:
When we come to 2000 the branding becomes a little confusing.
There were a number of key focus areas and we saw R/3 being referred to as mySAP.com and also ERP (technically ECC). Noteworthy focusses were:
R/2 and R/3 are technically optimised as systems to record data. They are not optimised to analyse data. The late 90s saw the release of the first business warehouse system (BW). This system is technically architected to analyse data. Organisations would use ERP to record data and carry out simple real-time reporting and then send data in daily batches to BW for more complex analysis. I'll come back to this with an illustration later.
During this period there was a boom in niche software providers, particularly in areas such as data analytics. SAP took the opportunity to acquire some leading competitors to cover areas where their applications were weaker, for example this covered:
What’s interesting to note is that with the addition of 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, in fact, leads to a lot more solutions in areas like interfacing and master data management.
During the 2000s the number of processes covered by the R/3 or ERP was continuously increased, in addition to that, a number of 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 business suite are:
As mentioned a major 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 read data quickly. This led to the development of stand-alone systems such as SAPs business warehouse that were optimised to read data. The following terms were used to describe these two different types of systems:
As a result of this large organisations often ended up with systems landscapes that include multiple OLTP systems and multiple OLAP systems all connected together. And this is before we even consider topics such as web applications, big data etc.!
Prior to the launch of HANA, it’s useful to reflect on where the SAP portfolio was:
Altogether the complexity of business systems landscapes has been massively increasing since the mainframe days. I think this is a topic which is not addressed as much as it should within architecture plans, while we should embrace new technologies we should also rationalise old technologies.
This brings us to the 2010s where part of the focus from SAP is on reducing the complexity of the core product, 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.
This 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. This is 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 own scope for a S/4HANA conversion based on their own objectives.
In this article, I'll cover three main building blocks of S/4HANA. These are:
In this post, I'll spend most of the remaining time explaining the HANA platform and how it impacts business suite, which I think is not commonly understood. For the business suite and Fiori I'll give a very brief overview as these topics are quite deep and SAP has plenty of information available. Plus when looking at these topics it needs to be done piece by piece e.g. by function or UX case.
To understand HANA we need a little consideration to how memory works in a computer. Bear with me, it's not that technical!
As with many applications, ERP was designed based on what could be done at the time with the technology available. 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 gave SAP the opportunity to re-think the architecture of ERP. This 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:
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.
There are three key features that allow the HANA platform to solve the problems ERP and BI were facing, these are:
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.
To start the explanation of how HANA uses memory, let's consider the example of a regular desktop computer. Memory can be categorised into 3 types:
The biggest factor in determining the speed a computer can process is how quickly it can read and write to memory. If the processor needs to access auxiliary memory then the process will be very slow.
R/3 doesn't run on a desktop, it runs on a server. But don't be concerned about IT terminology a server is the just a computer in the same way a desktop is a computer.
So we can consider R/3 ERP as a big computer, with massive data volumes, one of the main reasons it can’t be used for advanced data analysis is the time it takes to retrieve data from auxiliary memory.
As technology becomes more advanced and component prices go down, main memory is now available at a cost where it can be used for the volume of storage that was previously was only possible to store in auxiliary memory.
To directly quote SAP, “SAP HANA runs on multi-core CPUs with fast communication between processor cores and containing terabytes of main memory. With SAP HANA, all data is available in main memory, which avoids the performance penalty of disk I/O (i.e. read/write to auxiliary memory).
In plain English, the complete dataset within ERP is stored in what we think of as 'RAM' on our desktops or laptops and is easily accessible by the processor.
With HANA we don't need auxiliary memory for day to day operations as shown below. However note that it is used for back up / disaster recovery, for example in the case of power being lost.
In addition to in-memory, HANA applies database management methods that are much more efficient at compressing data. And the more compressed data can be the faster the system can run.
Consider the table below. Traditionally an OLTP type database will hold data in a row store. If you compare the row store with an alternative method; the column store, you will quickly realise that for the column store a lot of values may be duplicated side by side. Intuitively we can see a columnar store may be much easier to compress.
Compression is a fairly broad and technical topic, but simply imagine a column for 'city' in a table of addresses, we will have hundreds if not thousands of entries of e.g. 'London', if that's the case we don't need to store London every time, we can instead store the range of rows that have London as a city, this means if there is a query about London, the application does not need to work through every row to get the results.
More information:
Taking into account 'in-memory' design with 'columnar' store, the HANA platform provides a database that can operate hugely faster than the database options used in R/3 or business suite 7 or any traditional OLTP system. This is quite a big deal:
Recall we said there are three main components of S/4HANA
Now that we covered the HANA platform we can look at Business Suite. The business suite present in S/4HANA is essentially an updated version of business suite 7.
We could say that the conversion from say R/3 to S/4HANA is a technical upgrade from a database perspective. But from an application perspective, there are further changes and enhancements many of which are enabled by the database conversion.
A big part of a S/4HANA implementation is understanding which simplifications and enhancements are available and which you would like to implement. Not all simplifications are mandatory. And each simplification or enhancement has its own unique impact on the process, data etc.
SAP provides a simplification list for each HANA release. The current S/4HANA version is 1909 and the list is here:
https://help.sap.com/doc/0080a18cdc1045638d31c87b839011e7/1909.000/en-US/SIMPL_OP1909.pdf
I won't go through these in detail, it's a huge list. One note worth mentioning is that the majority of simplifications are within the finance and logistics areas. Some examples from finance:
For finance the simplification journey started back with ERP (ECC 6.0), at this time NewGL was launched which provided a significant simplification to the way financials and controlling worked:
NewGL provided a starting point for further simplifications enabled by HANA.
Fiori is SAPs new approach to user interface design.
One of the main objectives of Fiori is to allow developers to quickly create 'apps' as an interface for specific activities or tasks within SAP. These apps can feature improved visual design, role-specific actions and be adaptable between desktop, tablet and mobile etc.
Fiori starts from the launchpad where different apps can be placed as tiles along with global elements such as user personalisation options, search and notification.
(image source: https://experience.sap.com/fiori-design-web/launchpad/)
This provides a significant step forward in the ability to customise the interface to specific roles and improve the user experience. It's easy to see how having key figures and activities available at a glance could have a number of benefits.
Fiori comes with a number of SAP provided apps and organisations can also develop their own apps. For a S/4HANA conversion how much effort should be placed on Fiori? How many apps will be deployed? How much time will be spent on optimising launchpads for specific roles?
As with any ERP implementation or upgrade, a conversion to S/4HANA will be a complex project. SAP provides free training available on open sap:
In addition to training, there is a recommended roadmap. Between these, it's possible to plan out all required activities. I'd like to highlight three areas of focus:
As we've seen a S/4HANA conversion is like a hybrid between a technical upgrade and an introduction of new business features. With this in mind, what is the business case behind the investment? It could range between:
When considering the benefits, it's critical to ensure that experts who understand the state of the current systems and current ways of working are involved.
In my experience the pre-sales and business case activities are often limited to senior management and architects, this can lead to an overestimation of the benefits that the users of the system will receive.
I'd recommend validating the business case with functional and technical experts. This may lead to an adjustment of the plan for improved scope, more refined focus and a more realistic project plan.
The recommendations and learnings which I've applied to R/3 and ERP upgrades also apply to S/4HANA. The biggest of these is related to preparation. Serious work should start 3-6 months prior to the start of the project proper. The work that should start early includes topics such as:
The majority of SAP projects run into problems in the requirements, fit-gap and testing stages because the current system and process were not well understood or considered or there were hidden issues. It's critical to surface these early.
Typically a large organisation may run a global SAP upgrade/implementation something like the below:
With this approach, the best experts and 'real knowledge' may not see the planned solution until user acceptance testing occurs. By this time it's too late to change anything without major project delays. I've always disliked how user acceptance testing is included in traditional IT projects, it's never a chance to accept a system works acceptably for a business, it's often more an argument on whether the system works according to what was agreed and written down in previous project stages.
When you plan your project, look at the team staffing, from the very first phases:
Free up your at least one operational experts from each in scope function and ensure they are involved from the start. Make sure the profile of this person is someone that will continuously socialise and gain feedback and input from their peers.
There are still a lot of topics to be considered such as the details of the simplification list for each function and the impact on 'add on' systems e.g. analytics. However, hopefully understanding what HANA and S/4HANA are from an evolutionary and technical perspective makes it easier to figure out how it all fits together.
What aspects of understanding and planning SAP related work do you find most challenging?
This is also posted on my LinkedIn - https://www.linkedin.com/pulse/sap-hana-s4-alexander-roan/ And on my website - https://www.alexroan.com/category/technology/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
3 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |