Run Simple

SAP S/4HANA: Simple, Fast, Different

What Does it Mean to the Business?

On February 3, 2015, SAP announced what it called its biggest product launch in the history of the company: SAP Business Suite 4 SAP HANA, or (thankfully) SAP S/4HANA for short, was touted as “the next-generation business suite to help customers run simple.” Indeed, “S” stands for simple; “4” is for 4th generation and in Information Technology (IT) circles, HANA speaks for itself. To interpret for those outside the world of IT, HANA is an advanced in-memory platform that is able to crunch through enormous volumes of data incredibly fast.

In combination these three factors hold enormous potential to change the way businesses are run. While the potential impact might seem intuitive to technologists, it is far less obvious to the typical business executive. And yet, in a world where the terms innovative, disruptive and transformative are all too often over-used and mis-used, SAP S/4HANA is disruptive innovation that can be used to simplify and transform your business. If you are interested in learning how, read on…

What is it?

SAP S/4HANA is a new product, which, like its predecessor (the SAP Business Suite) will include enterprise resource planning (ERP) and other complementary functions including:

  • Customer relationship management (CRM)
  • Supplier relationship management (SRM)
  • Supply chain management (SCM)
  • Product lifecycle management (PLM)
  • cloud functions such as SAP SuccessFactors (HCM) and its Ariba Network

Like the SAP Business Suite, it is designed for the large enterprise, and eventually will satisfy the requirements of the same 26 industries SAP has spent decades building out. This is a big and bold move for SAP. Given these similarities, some immediate questions come to mind. First of all, why develop a new product? After all, the SAP Business Suite could already run on SAP HANA. Secondly, is it really possible to replace over 400 million lines of code quickly enough or will a complete solution be decades in the making? To answer these questions we need to look at both the differences and the similarities.

At first glance, the differences that appear most obvious to the typical business user lay in the user experience and deployment models offered. Beyond the obvious is the new code line with a new and simplified data model, but more on that (and what it means to the user) later.

Choice of Deployment Models

The existing product was essentially an on-premise solution, although SAP has recently offered a cloud-based managed services option. The SAP HANA Enterprise Cloud (HEC) is a service that allows organizations to move existing (or new) implementations of the SAP Business Suite off their own servers and into SAP’s massive data centers where SAP would manage it as a single tenant solution in a private cloud. But this doesn’t carry the same benefits of lower cost and faster innovation possible with a multi-tenant software as a service (SaaS) solution.

With SAP S/4HANA comes a choice of deployment options. The On Premise Edition is available today while the Public Cloud Edition (multi-tenant SaaS) will be available soon (the first quarter of 2015), followed by the Managed Cloud Edition in Q2.

New and Improved User Experience

The user interface of the SAP Business Suite has long been a weak point, and also one of the hardest to “fix.” SAP is not alone in this dilemma. Many enterprise application solution providers struggle with this as expectations change over time, especially with the influence of consumer mobile devices. Users become dissatisfied with existing user interfaces but often getting them to change is like pulling teeth, for fear of the need to retrain users and because people (those actually using the software) get used to it and resist change.

SAP has actually been working on fixing this problem for more than two years. In the spring of 2013 it introduced SAP Fiori, a collection of 25 apps (initially) that surrounded the Business Suite, providing a new user experience for the most commonly used business functions of ERP. While useful in pleasing existing users and perhaps even attracting new users within the enterprise, SAP Fiori had limited impact for two related reasons. First, the initial set of apps just changed the user interface (UI) and did not add any significant new functionality. And yet, they weren’t free. Customers balked at paying a fee for innovation they expected SAP to deliver as part of maintenance.

The second round of Fiori apps however began to add in new capabilities, but in spite of that, SAP responded to customer complaints and made them free (with maintenance). And today there are over 500 of them available.

The intended new user experience delivered with SAP S/4HANA is based entirely on SAP Fiori and SAP expects that over time more and more transactions will come from mobile devices, a very viable option with Fiori. New customers will engage with SAP S/4HANA through these apps right from the beginning. Those SAP Business Suite customers that migrate to SAP S/4HANA will have the option of continuing to use the traditional user interface, but of course Fiori apps won’t shore up this weakness unless they are really used. Hopefully, with the mindset of running a new product, customers will expect to engage differently and therefore take better advantage of the new experience and the new functions delivered through Fiori.

Beyond the Obvious

While either or both of these differences might be compelling, even together they don’t justify the time and effort involved in replacing 400 million lines of code to produce a new product. The real game changer here is the underlying technology that allowed SAP to reduce the data footprint by a factor of 10, increase throughput by a factor of 7 and make analytics and reporting orders of magnitude faster (SAP claims 1800 times faster). SAP’s goal was to achieve a zero response time.

However, many business executives running SAP solutions, as well as those of other vendors, might not perceive themselves as having a problem with response time and the size of their data footprint is hardly something that keeps them up at night. If you consider yourself in this category, what’s in it for you? The short answer is

  • Speed in getting at data and answering questions
  • The power of iterative questions, including immediate answers to new ones you didn’t even know you had until you started looking
  • The ability to base all decisions (strategic and operational) on as much detail, in as fine a level of granularity as you can imagine

Perhaps you don’t think you have a problem because you have adapted to the limitations of existing systems. Or you don’t know response time is slow because you never put your hands directly on the system. You might be accustomed to making decisions from data that is frozen in time (a snapshot) because it is not updated and available in real time. You may have waited so long for new queries and reporting that perhaps you stopped asking for them. You probably forecast sales at a summary level by region, assuming you can’t possibly analyze and predict sales at an individual customer level, by product and region, by sales rep. What if SAP S/4HANA could change all this?

Speed is obviously a key factor, but why should you care about reducing the data footprint? The answer lies in understanding why that footprint got so bloated in the first place. As your solution footprint has grown through the years, there is a very good chance you have introduced redundant data. If you started with ERP, then added CRM, both need customer data and product data. This redundant data needs to be synchronized. SAP estimates that 40% of the data load is the exchange of data between solutions.

In addition all enterprise solutions have traditionally accumulated all sorts of totals. Some are for periodic reporting (monthly, quarterly, annually, etc.), while other aggregates are used to gain insight into different parts of the organizational structure. This aggregation enables reporting without having to sort and calculate totals across a potentially large volume of transactions. While the process is simple and effective (because you can gain access to these totals through a simple query), there were some drawbacks.

Not only is there more embedded code to maintain these totals, there is more contention within the data files. Let’s say a large enterprise has people all over the world entering sales orders. If totals are updated in real time, even though it might appear that all transactions are accessing and updating records in the files simultaneously, in reality, these updates happen one at a time. Before a transaction can update a record, it has to check to make sure no other transaction is trying to do the same. If the record is being accessed or updated by another transaction, it must wait for the record to be freed up. Of course it might take only seconds, but those seconds add up and response time slows.

This is also why sometimes these totals are not updated in real-time, and instead are calculated with batch runs. That means you are looking at a snapshot in time and not the “real” number.

And finally, keeping these totals up to date, whether in real-time or through batch runs, means you have to anticipate how and what you want to include in the totals. What happens when you want to change the organizational structure and report in a new way? Those pre-calculated totals are now meaningless. If you can instantly slice and dice and calculate on the fly using any criteria, you don’t have to do any of this aggregation and you get complete flexibility.

Removing these totals means no updates and no more contention. Dozens or even hundreds or thousands of transactions can be entered and stored, at the same time (literally, not just seemingly). This is what the technologists mean when they refer to “massively parallel processing (MPP).”

So SAP got rid of these totals and also the database indices. Database indices allow you to do key lookups. You can easily look up a customer or a product by customer number or part number because those numbers are keys, allowing the software to go (more) directly to a record without having to search through the entire file. But these indices are no longer required if you can search through even massive files and still get sub-second response.

In the end, SAP S/4HANA reduced the number of data tables from 110 to less than 10. And it also segregated out historical data from current data. By its very definition, historical data can’t be changed any more. That makes it easier to handle. So SAP segregated it and made it read-only, making it even easier to deal with the current data.

This flexibility and speed is the real value HANA brings to the business, along with improved, faster decision-making. However, to take full advantage of HANA, SAP S/4HANA must only run on HANA. Of course, this means customers will not have a choice of databases. Some industry observers are criticizing SAP for removing this as a choice. However, preserving that choice of database means SAP S/4HANA would be restricted to the least common denominator of functionality.

If SAP does not take full advantage of the benefits HANA brings, why create a new product? The SAP Business Suite already provides this freedom of choice, including the Business Suite on HANA. And SAP has promised to continue to develop and support the SAP Business Suite through 2025.

Some customers will be reluctant to spend the money on a new platform. Some will cite the skill levels of their current staffs. If customers want to remain on traditional databases, they should just stay on the SAP Business Suite, at least for now. If IT staffs have not upgraded their skill levels by 2025, they will have more problems to contend with than just limitations in response times. So maybe it is time for some “disruption.”

Disruptive Innovation

While technology industry observers love to talk about “disruptive technology,” many business executives think of disruption as a bad thing. Yet while certain types of disruption can indeed be bad, other types can also be good. Disruption that prevents you from delivering a product or service is obviously bad. Disruption that forces you to do things in a different, but better way can be very good.

Wikipedia defines disruptive innovation as “an innovation that helps create a new market and value network, and eventually disrupts an existing market and value network (over a few years or decades), displacing an earlier technology. The term is used in business and technology literature to describe innovations that improve a product or service in ways that the market does not expect…”

SAP S/4HANA is indeed disruptive innovation, but in the good sense. It is a bold move for SAP. Obviously its customers cannot transform themselves overnight, but they don’t need to. SAP S/4HANA was designed to allow existing SAP Business Suite customers to migrate without the bad kind of disruption. And of course SAP can’t transform millions of lines of code overnight either.

While the SAP Business Suite was just that – a suite of products, eventually all this functionality will be embedded and delivered as a single product. SAP started with ERP, but will eventually add in functionality from CRM, SRM, SCM and PLM. It will start with those industries most likely to see the cloud as the next stop in their extended ERP journey, and then continue to broaden its industry reach. Of course for any company taking this big next step, as always, the devil is in the details. How will companies (both new customers and existing SAP customers) make the transition while SAP itself is still in transition? Will they be able to embrace the good kind of disruption while keeping the bad kind at bay?

Conclusion

The short answer is yes, but that too will be a journey. It will not happen overnight. The key to success is in allowing all the current and new solutions to coexist. While SAP S/4HANA only has 10 or so tables, those applications like CRM, SRM and SCM are expecting to find their share of the full-blown 110 tables. That’s okay.

SAP has also defined a virtual data model that can do a translation of sorts, mapping the old tables to the new data model. This is a key factor in facilitating the migration from SAP Business Suite to SAP S/4HANA without disruption. It not only allows these (currently additional) applications to interoperate with SAP S/4HANA, but also allows customers to continue running current reports that might rely on those old totals. So current and new customers both can ease into taking full advantage of the new capabilities. This is good since it will take companies awhile to realize they can now solve problems that are currently viewed as unsolvable.

Tagged , , , , , , , , , , ,