Is SAP S/4 HANA a New Application Architecture?

Executive Summary

  • Hasso Plattner provides a summary of the benefits of S/4HANA’s new application architecture. However, Hasso’s proposals are all false.
  • We cover these false benefits in this article.

App Arch

Introduction

Hasso Plattner has written a great deal of promotional literature about S/4HANA. One of his proposals is that S/4HANA is a new application architecture. In this article, we will cover this topic and analyze the legitimacy of the claim.

Hasso on S/4 HANA as a New Application Architecture

“The in-memory database SAP HANA allows for a radically different application architecture and a new philosophy with regards to the data model simplicity. While most of the business functionality of the business suite will be  carried over to SAP S/4 HANA, new workflows, larger transaction volumes, real time analytics on  transactional data, unmatched flexibility when changing reporting structures and even real time  simulation of business scenarios are possible. And all this comes with a completely new UI and a new framework for modifications and extensions. SAP S/4 HANA will continue to be developed at a different speed in order to match the new requirements of the digital age.”

Hasso does not explain why “in-memory database” allows for a radically different “application architecture.” According to Wikipedia, the definition of application design is the following:

“Applications architecture is the science and art of ensuring the suite of applications being used by an organization to create the composite architecture is scalable, reliable, available and manageable.”

Interpretation

I don’t think Hasso’s claim here holds true. He may be able to propose that that HANA creates more scalability — although that could be easily debated. I see no reason why HANA makes S/4HANA or ERP functionality more reliable, available or manageable. SAP ECC is already quite reliable; it is available. It ‘s hard to maintain, but that is only in a small way related to its database. Much more of the difficulty in maintaining ECC has to do with its user interface, learning curve, issues with maintaining master data and other non-database related issues.

See our The S/4HANA Implementation Study. For the real story and details on actual S/4HANA implementations.

Conclusions

There is not much to take away from this section of the paper by Hasso Plattner. The statements are not substantiated.

Search Our Other S/4HANA Content

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

Is S/4HANA Actually Designed for the Cloud?

Executive Summary

  • Hasso provides a summary of the benefits of S/4HANA.
  • We review the accuracy of these benefits.

Introduction

One of the common areas of confusion is S4HANA cloud. That is the deployment of S/4HANA in the cloud. S4HANA cloud is the concept, often presented by SAP S/4HANA is somehow explicitly designed for the cloud.

There has been a great motivation of SAP to commingle both HANA and S/4HANA with the cloud. In this article, we will review how legitimate this is.

Hasso on S/4HANA Deployment in the Cloud

Hasso Plattner had the following to say on S/4HANA Cloud deployment.

‘There are many advantages to deploy the system in the cloud, but if regional preferences call for an implementation on premise — no problem, it might be just a different cost factor. It has to be understood that the deployment in the cloud has a principal advantage when it comes to the implementation of new functionality. Just take the new online sales scenarios with different revenue creation and recognition practices. Most companies will be in need of these features pretty soon and only with SAP S/4HANA can really accelerate the adoption. SAP offers a test migration of SAP ECC 6.0 systems in the cloud and the customer can later decide where to run the production system.”

Implementing in the Cloud?: Implementing HANA (the database) in the cloud is quite expensive, as I cover in What SAP Moving to the Cloud Means for Current HANA On-Premises Purchases.

Hasso may want to explain why, so few HANA purchases are sold in the cloud. The latter part of this paragraph seems to have some logical connection problems. However, SAP S/4HANA is simply ECC ported to HANA. So it does not make sense to say that it will

“actually accelerate the adoption”

..of something.

And again, Hasso seems to be relying on the assumption that SAP S/4HANA is going to be sold in the cloud quite a bit, which remains to be seen.

But if the software is sold in the cloud or is installed on premises, this does say things about functionality. Cloud applications do tend to be more distributed than on-premises applications — so cloud may say something about access — but it does not relate to the functionality — such as the sales scenarios, revenue creation, and recognition practices.

Analysis of Hasso’s Statements

HANA has nothing really to do with the cloud. HANA can be placed in the cloud, just like other databases, but up until this point, there have been few cloud-based implementations of HANA.

S4HANA cloud is a term that sounds new and different, but in fact, S/4HANA is not particularly cloud-centric or cloud ready. As so few SAP ERP instances lack customization, it is unlikely that..

“S4HANA cloud”

will be much of a factor into the future.

But what Hasso is describing here is nonsense. It is merely a series of words strung together designed to make an impact, but upon review, the concepts explained here by Hasso by not correct.

Now let us look at the significant points one by one.

SAP’s New Customer Facing Applications?

“With New Customer Facing Applications Like Those From Hybris. Success Factors, Ariba, Field Glass, Concur and the Internet of Things projects with SAP HANA Vora.” 

This is similar to Hasso’s argument regarding Hadoop that I have been pointing out.

None of these items that Hasso is referring to have anything to do with S/4HANA. It is not a “unique offering” it is a particular offering based upon some somewhat foreign acquisitions that SAP has engaged in to get the analysts thinking that SAP is becoming a cloud company so that it will get the stock price up.

SAP Offers a Unique Suite of Products?

“SAP Offers a Unique Suite of Products, which Can be Installed and Activated Quickly.”

Well, the acquired products — which are cloud-based do install quickly. But if we are talking about S/4, there is no reason to think that S/4HANA will install (or be implemented is what Hasso must mean, as installation does not take you live) quickly. S/4 will be a tough installation.

So Hasso seems to be trying to commingle the implementation ease of say Success Factors with S/4, and the two applications have nothing to with one another.

SAP HANA Cloud Platform Allows for Easy Implementation and Extension?

“The SAP HANA Cloud Platform Allows for Easy Implementations of Extensions to Integrate other Software Products or Bespoke applications.”

SAP has followed a multi-decade strategy of making itself difficult to integrate to so that other software vendors would be at a disadvantage against them.

SAP’s strategy was to capture the ERP system, and then push into other application areas using the argument that integrating with other vendors was risky. Why SAP would reverse, this decade’s long strategy, that has turned them into the largest enterprise software company in the world is difficult to swallow.

Did SAP See a Dramatic Increase in SAP S/4HANA in the Third Quarter?

“SAP Saw a Dramatic Increase in SAP S/4HANA Projects in the Third Quarter.”

We don’t know if this is true, as SAP has even stopped breaking out HANA license purchases. The dramatic increase, if it occurred would be on a minuscule base of S/4 projects. However years after this statement (July 2018, S4HANA has continued to have few implementations with SAP’s June 2018 estimates of 1500 live S4HANA implementations false)

A Lack of Information or Overly Conservative Attitude Hinders Companies to Move to S/4HANA?

“It Would be a Shame if Lack of Information or an Overly Conservative Attitude Hinders Companies… to Make the Move to SAP S/4HANA.”

SAP customers have been bombarded by HANA information. HANA has been SAP major marketing tentpole for over 4.5 years as I covered in Has SAP’s Relentless HANA Push Paid Off? 

So a lack of information cannot be blamed for hindering companies from moving to S/4HANA.

I am in contact with some businesses and what is blocking enterprises in this regards is that S/4 is too expensive, it is too risky, it dictates to the customer too much, and furthermore many previous promises regarding how SAP’s products would benefit them have not paid off. That is the truth.

See our The S/4HANA Implementation Study for real story and details on actual S4HANA implementations.

The Wall Street Journal’s Cloud Confusion

I have recently forwarded an article by a cloud vendor from the Wall Street Journal blog. One quotation caught my eye.

“In the process, she’s pitted Kenandy against both software giants like SAP and Oracle and older manufacturing software companies like QAD, all of which are racing to redesign their software for the cloud.”

That is interesting, because the ability to offer applications by cloud has existed for some time, and the only SAP product that is I can think of that is cloud-based is SAP’s product offered through Amazon’s AWS service, which represents some minuscule percentage of SAP’s global revenue. Secondly, the article does not seem to consider that enterprise cloud is the opposite of SAP’s business model, and cloud represents one the most significant challenges to how SAP does business. To highlight this, let’s discuss what cloud is.

Cloud is where a hosted solution, which is already up and running at a software vendor (typically), allows a client to access its services in return for a monthly fee. The features of cloud are the following:

  1. Cloud solutions implement very quickly, because the installation is already complete, and it is a matter of configuring a running application.
  2. Cloud solutions have the highest value in the enterprise software space. The total cost of ownership of cloud solutions tends to be low compared to the on-premises model.
  3. Cloud solutions provide tend to have a lower sales orientation and offer online trials of their software, which means that clients have a better idea of what they are buying than on-premises implementations. I cover in this article and the book Supply Chain Forecasting Software. That most companies select the wrong forecasting applications for a variety of reasons, but major ones being that they generally don’t understand the software they are buying very well, and are misled by large consulting companies and companies like SAP and Oracle into buying weak applications due to the tremendous marketing muscle of the significant monopoly vendors.
  4. Cloud solutions do not tend to follow the standard enterprise sales model that is controlled and distorted by corrupt consulting companies intent on recommending software, like SAP, that maximizes their revenues at the cost of their client’s interests.
  5. Cloud vendors provide a high degree of flexibility to their clients, and companies can much more easily switch between cloud providers as the fees are monthly. Cloud solution providers are very much about providing value to clients rather than locking them in. SAP, Oracle, and IBM are about locking their clients in solutions.

Monopoly Power

SAP is a monopoly vendor, much like Microsoft, that puts out uncompetitive software that is propped up by relationships that restrict the choice of consumers in the marketplace. In the case of Microsoft, they have relationships with retailers and computer OEMs. SAP has relationships with the advisory companies that recommend software in the enterprise space. Neither SAP nor Microsoft can win anywhere near as much as they do in a competitive market. Both vendors also very much have a strategy based on “lock-in.” Companies are very hesitant to move to a new solution once they invest so much money in SAP. This is true even if the results are poor. However, cloud allows clients to leave as the contracts are month to month freely. SAP has no interest in this business model. Cloud is the exact opposite of how SAP, Oracle, and IBM have made their money and become highly successful organizations.

Can Cloud Fight Monopoly Power in Enterprise Software?

Cloud has the potential one of the few industry trends that have the potential to undermine the monopoly power of the companies. The author states in the article that was forwarded to me that SAP and Oracle at least are “racing to redesign their software for the cloud”? How did this author “learn” that SAP is racing to cloud-enable their applications? Did they hear this from an SAP representative and then retype the statement.

Conclusion

There is not much to take away from this section of the paper by Hasso Plattner. The statements are not substantiated and once against Hasso Plattner can’t seem to get through more than a few sentences without unleashing some falsehood. In July 2018 (when this article was last updated) S/4HANA still has less than 100 S/4HANA Cloud customers live. And the customer that are live looks suspicious as the following graphic shows.

Almost every company on this list of S4HANA customers is an SAP consulting partner. However, these are not real customers. They implemented S4HANA Cloud to build skills to resell S4HANA consulting projects. No professional services company needs an ERP system; they only need HR and finance functionality. All of these companies would have been far better off implementing Workday. 

Search Our Other HANA Content

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://blogs.wsj.com/digits/2012/05/04/silicon-valley-pioneer-kurtzig-goes-after-sap-oracle/?mod=google_news_blog

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

How to Understand SAP S/4 HANA and SAP Customization

Executive Summary

  • Hasso Plattner provides a summary of the benefits of SAP S/4 HANA
  • We review this summary for accuracy.

Introduction to S/4HANA and Customization

S/4HANA has a very high customization adjustment overhead. In this article, you will learn about the reality of the S/4HANA customization overhead versus what SAP proposes.

SAP’s Presentation on S/4HANA Customization

Hasso Plattner has taken an interesting step in describing what would happen to a SAP customization or SAP enhancement that has been added to an existing ECC system. This is of particular importance as 92% of SAP implementation has a moderate to high level of SAP customization or SAP enhancement.

Hasso on SAP S/4HANA Allowing the Dropping of SAP Customization or SAP Enhancement

“It is interesting to see regional differences in the speed of adoption. It is similar to the introduction SAP R/3 in 1992/3. The SAP R/3 system was meant to be for smaller companies and who jumped on it first? The large and super large ones. I am absolutely convinced that smaller and midsize companies will now benefit even more, since they might be able to drop most of their modifications, as a consequence reduce the TCO, and have significantly more productive users, who will gain business insights like never before.”

…Smaller and Midsized Companies Will Now Benefit Even More, Since They Might be Able to Drop Most of their Modifications:

Really?

How can using the same functionality in ECC allow any company, regardless of its size to drop its modifications?

The vast majority of changes that exist in SAP customers are because of gaps in functionality.

Mitigating Deficiencies for S/4HANA or SAP Marketing Instructions?

These deficiencies are not altered because S/4 does not provide more or different functionality than ECC. In fact, most of the modifications that companies have made to ECC will never be addressed by future versions of SAP’s ERP systems because they are unique to the company’s requirements.

Without additional functionality, no modifications should be expected to be dropped. In fact, these changes will need to be rewritten.

Our Interpretation

It took me so much time to complete this article. I understand that Hasso wants the customer to buy S/4 licenses, but customers should look at how many statements that are said about S/4 HANA are true or where they cannot be determined if they are true if they are likely to be true.

Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.

The Ridiculous Quotation from Deloitte

One of the areas of S/4HANA that has been obscured by SAP has been customizations. In this article, we will describe what happens when S/4HANA is implemented by a company moving from ECC. And we will also delve into comments made by Deloitte regarding its highly customized version of ECC.

Moving From ECC to S/4HANA

As S/4HANA uses a different database schema from ECC, S/4HANA is the first ERP system that will break all integrations and customizations that customers added to ECC. SAP has released confusing information on these topics would prefer to keep them hidden and obscure as it would negatively impact S/4HANA purchases. SAP has instead changed the topic and has said that S/4HANA represents an “opportunity” to SAP customers to evaluate all current customizations and to remove them. SAP appears silent on the topic of integrations that will break and will need to be rewritten when S/4HANA is implemented. SAP is currently deceiving customers on this point and instead of telling them that S/4HANA provides an opportunity to evaluate all customizations and to eliminate them.

Deloitte’s 33,000 Customizations

In a press release that was supposed to promote S/4HANA, Deloitte admitted that it performed 33,000 customizations when it implemented a very narrow area of functionality in ECC. 

“Deloitte was an early adopter of SAP’s R/3 ERP system back in 1995 despite it “not really being designed to be used by a professional services firm,” Bray said. “So guess what? We customised the hell out of it,” he added, with more than 33,000 SAP finance customisations made over 20 years.

Over the years Deloitte has adopted some of the professional services-specific editions of SAP software, but was still facing the typical challenges of having an ageing system. Namely, long run times, maintenance issues, little flexibility due to the number of customisations, and outages. Now it is looking to fully upgrade to the next-generation S/4HANA suite, which is built on the software vendor’s in-memory HANA database.”

It is difficult to see how Deloitte, that after all just does consulting, accounting services and outsourcing would need so many customizations. The vast majority of SAP customers will not have anywhere close to that many customizations. Again, if you have that many customizations a few questions naturally arise. 

  1. Did we choose the right application?
  2. Do we even fit into the category of a packaged application?

Deloitte’s Misstep in Releasing Truthful Information on S/4HANA

Maybe the company with 33,000 customizations simply needs a custom built application. Also, it boggles the mind that business as simple as Deloitte would need that many. Furthermore, Deloitte did not realize it, but they are directly contradicting SAP by admitting they had to make so many customizations. According to SAP, you should not need customizations because all best practices are already contained in their applications. If even one of their top consulting partners needed to perform so many customizations, then what hope do customers have to stay away from them. 

Deloitte may not remember the marketing material and what they present to their clients, but SAP contains all the best practices in the universe within the application. SAP is extremely clear in its messaging that most of the customizations that clients make to their software — which remember contains all best practices — are unnecessary.

It is still amazing to me that Deloitte even admitted this. They are supposed to get this stuff approved by SAP before its released as a complete story for ComputerWorld to reprint. It is incredible that some people don’t even know the implications of what they are saying. SAP marketing is going to ream them out big time. And from what SAP partners who are vendors tell me, it is not a pleasant experience. I heard what SAP did to Gartner over S/4HANA, and it was very humbling for Gartner. That information related to customizations may get retracted in a day or so. But it’s too late, I have taken a copy of the article to my Evernote. I may write an article on this; it is too humorous to pass up.

Comments by Sam Graham

In a discussion on this topic on LinkedIn, the following comment was made by Sam Graham

“So, Deloitte, who earn hundreds of millions of dollars every year from implementing SAP are going to revolutionize their business by moving to, guess what?. SAP! What a surprise! And I wonder of all of the companies who implemented R/3, under advice from Deloitte, realized what a low opinion Deloitte had of R/3? What was that phrase, “We customized the hell out of it”? At whose cost; I wonder? And will they also ‘customize the hell’ out of S4/HANA? And, having spent millions or tens of millions on S/4HANA, following Deloitte’s recommendation, will their customers be paying millions more for the customization that Deloitte recommends?”

Customizations Not a Good Measure of Fit of an Application?

In the LinkedIn interaction, Pete Chapman stated the following:

“Gosh everyone is a cynic 😉 The conclusion most large enterprises come to involves a mix of COTS products with mods where possible, custom build where it offers a competitive advantage and messy integration. Who wants to build their own finance package from scratch? Horses for courses. I’m sure there’s a better way out there, let me know when you find it…”

Shaun Snapp’s Comment

“I can’t speak to what everyone wrote on this thread, but my proposal was simply that S/4HANA Finance was not a good choice for Deloitte and that Deloitte did not select S/4HANA for its match to business requirements, but for marketing and skill development reasons. Deloitte would be better served with a financial best of breed combined with an HR solution. I did not propose building a finance application from scratch but instead proposed a best of breed financial application that was not part of an ERP suite. On the topic of messy integrations, customizing applications is not any less messy. It’s coding. Its development hours, etc.. I don’t think going with a 100% internally developed application is preferable, though in some areas there is no packaged solution that meets the requirements (some forms of production planning and scheduling are a perfect example of this) if you have 33,000 customizations in mostly a single module, then how much of the standard functionality was used?”

Sam Graham’s Comment

“Pete; can you justify 33,000 modifications to a system that most customers have paid many million of dollars for? How many ERP systems have an implementation consultant who advises that a customer should make 33.000 modifications? Are you saying that Deloitte are irresponsible or just incompetent? If customers haven’t paid for these 33,000 modifications that a SAP implementation partner deems necessary; are they using an inferior system? Can you explain?”

Pete Chapman’s Comment

Without commenting on a specific case global implementations accumulate a lot of custom code after 20 years of business change – some of it technical debt. You know it: Workflows. Reports. Interfaces. Conversions. Enhancements. Forms. Authorisations. Plus entirely new transactions. 33,000 is meaningless without proper context. Ideally changes are justified by commensurate benefits – although good governance is under appreciated. Major ICT transformation programmes can now cost hundreds of millions of dollars with benefits measured in billions. Context matters. I’d rather build a well-tailored experience on COTS services than train 50,000 users on generic screens.

Shaun Snapp’s Comment

“I learned something really amazing from these comments Paul. The number of customizations, even after Deloitte pointed out the heavy maintenance of ECC is absolutely meaningless. The decision that Deloitte made was fantastic. And if you disagree with mass idiocy, you may be a cynic. As long as we have financial bias promoting analysis, one will always come to ludicrous conclusions.”

Paul Coester Comment

“Cold facts are though that SAP is not quite as adept at the end to end stuff as the hype says it is. Forget DTT, even now today that is true. Case in point…Not one of the EAM Fiori apps work…But SAP flog them into the customer base like it’s THE thing…”

Pete Chapman Comment

“Paul Ever since ITS I’ve wished they would publish some light services with templates in popular web technologies. As long as business data and logic doesn’t leak from the application side the UX would almost be “disposable”. 

Conclusions

There is not much to take away from this section of the paper by Hasso Plattner. The statements are not substantiated.

As for Deloitte, this is what happens when a person who knows nothing about system implementation makes statements that he does not realize can be triangulated to determine that SAP made an enormous error in selecting SAP ECC. But for course, this could also have been determined by simply analyzing Deloitte’s business and understanding ECC. However, the match was unimportant to Deloitte. Deloitte wanted to implement SAP for marketing and skill development reasons.

Search Our Other S/4HANA Content

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

References

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

How to Deflect That You Were Wrong About HANA

Executive Summary

  • SAP and SAP consulting firms have made a large number of false claims around HANA.
  • When confronted with these claims, HANA proponents continually change the topic and deflect to other claims about HANA that are also false.

Introduction to Deflection of HANA Claims

There is a popular trend afoot in the HANA community that comes from either HANA defenders in SAP or HANA defenders in the SAP partner community. I call this pretending you weren’t wrong about HANA. SAP and its partner community have proliferated so much false information about HANA over the past five years. Once called out on it, they need to respond not to be seen as either unknowledgeable or dishonest. There are important principles at work here. Let us take a minute to review them.

  • There is HANA software to be sold!
  • There are HANA services to be sold!
  • It is imperative to be able to continue to mislead customers in an unmolested fashion!

In this article, I will describe the essential tactics that they employ.

First Some Background on the HANA DB

HANA DB was at some point around 2011 approved as the primary marketing tentpole for SAP. Since 2011 Dr. Hasso Plattner has written four books on HANA DB related topics. SAP marketing and sales have released a torrent of information about HANA. My research shows that this information has in just about ever case been either inaccurate or exaggerated. Dr. Hasso Plattner seems to be a true believer in HANA. Somewhere along the way, he seems to have become obsessed with HANA DB technology. People at SAP did not stand up to him and tell him he is overemphasizing on one topic (to the detriment of other important topics). I have brought up on many occasions that processing speed is not even among the top ten items that plague SAP projects. And if you work on SAP projects, it is hard to propose the opposite.

Fear of Confronting Hasso

Instead of having anyone push back on Hasso, SAP went all in on HANA. The problem is that Hasso is not a reliable source of information on computer topics. I have concluded that Hasso Plattner makes up things about as much as Donald Trump. The major difference is that Hasso Plattner is considerably smarter. And he covers topics that are far more sophisticated than the subjects covered by Donald Trump. Thus his deceptions are much harder to ascertain. But if you study Hasso Plattner’s writing and speeches long enough, a pattern of premeditated deception becomes impossible to ignore. The comments he made about a Chinese company that had an MRP run time of 24 hours, which SAP reduced with S4 running on HANA, many months before S4’s production planning module had even been developed is symptomatic of provably false statements made by him. (I have a future example of a very long MRP runtime, but alas the conclusion is not purchasing HANA DB.)

Hasso is much like most of the partners at large consulting companies that I have met. They simply do not care what happens. What they care about is what they can pull over on other people. This is not idle criticism but is based upon quite a few conversations with partners at major consulting companies. What they care about the perception rather than the reality. And they have in fact told me that this is the right way to think.

Follow that Money that Supports False Claims Around the HANA DB

As is usually the case the vast majority of money resides on the side of those that make exaggerated claims. The money is squarely on the side of exaggerating expectations, not on telling people the truth. The truth us much less exciting and does not appeal to the desires of the audience. The audience wants to hear that the thing they purchase will have incredible performance. That everyone who uses it loves it, that it is leading edge, has a low TCO, which it will result in being able to cut overhead, etc..

Things have not changed much since the traveling medicine show salesman. Wall Street wants to hear that SAP is all about both driving innovations through HANA as well as delivering more and more applications through the cloud. Therefore, regardless of what is true, the data will be gerrymandered to give this impression. Quotas must be met, and stock options must be exercised. SAP can choose from an unlimited number of type people who will tell any lie SAP wants in any language it wants in return for money.

For this reason, people in conferences and private visits compete with each other to misrepresent reality.

And the competition is fierce.

SAP Conferences as BS Mills

Conferences like SAPPHIRE and ASUG are filled with false information. Lies were emanating not only from SAP and their partners but employees within customers. They compete in giving mis-impressions on how much progress they have made with SAP’s newest applications. In interviewing companies that interact with SAP and SAP partners and I observe the information that is provided to these enterprises. I find one misleading statement after another. I should not be surprised. The lying in the documentation is simply repeated in the actual sales process.

There is all manner of problems with this overemphasis on HANA DB. But one easy item to point out is that the overall performance of the system does not match the database speed of the system. That is just because you can make the database run faster by say 100 points of measurement does not mean that this 100 point translates to 100 points in application performance. And whatever the improvement in application performance does not translate to business value.

False Performance Enhancements Applied Generally

Think about a Lamborghini Veneno. This $400,000 car has a 750 horsepower engine.

A Honda sedan may have a 100 horsepower engine. Does the Veneno get you around town 7.5 times faster? Of course not. The reason you can’t convince people to sell their house to buy a Veneno is that everyone drives and so they can’t be tricked into thinking their commute will drop to 2 minutes if they buy a Veneno. But not everyone has years of database experience. Thus it is easier to trick them into thinking that HANA might have such incredible benefits. But if they didn’t, and I was unethical, I could simply do the math that 750 hp is 7.5 times more than 100. I would then contend that people that have a 15-minute commute could have a 2-minute commute. That is 13 minutes saved each way, which is 26 minutes a day in extra time saved!

Imagine what you could do with that time back.

Hasso Plattner’s Falsehoods on In Memory and the HANA DB

In Dr. Hasso Plattner’s writings, he seems to propose a direct proportional benefit from database speed to a host of other benefits. This has lead SAP to exaggerate the benefits of HANA. And the primary reason for this is to penetrate into the database layer.That is SAP is willing to mislead as many people as necessary to meet the sales quotas on HANA. People that buy HANA often don’t see the second act coming.

Here is the second act. SAP has some other databases and applications that it wants to sell as a follow-on to HANA. And of course, none of these things will work well with “other databases.” HANA is the wedge to all sort of related items it wants to sell you.

All of this fanciful talk about a brave new world with in-memory computing is part of a campaign to tie companies into a closed system. A system that will benefit SAP. I have seen many companies now with HANA on BW.

Putting HANA on BW

BW is probably the SAP application with the most predicted benefit from HANA. It has not changed things at these companies much at all. In most cases, the business continues to use Excel while the queue of reports that the BW/BI team has to work on continues to grow. This is because new technology was added without asking the fundamental questions about the problems with BW/BI productivity and report usability.

What this means is that software salespeople and those with a sales quota at most IT consulting companies feel perfectly fine in telling a constant stream of lies to customers. Every inaccurate statement is an arrow in their quiver. Even statements that have been proven quite some time ago to be incorrect.

SAP’s HANA DB Claims

The following are good examples of the items that are exaggerated claims by either SAP or SAP partners.

  1. No aggregates EVER!!!
  2. Extreme OLTP performance as well as extreme OLAP performance
  3. Need little RAM as we compress EVERYTHING to very small…
  4. A whole new user interfaces in Fiori.
  5. HANA will lead to business process simplification when used with S4 because the data model has been simplified.
  6. Updates are superfast as we update only one field instead of the whole record
  7. Making use of CPU/RAM at the hardware level.

Every one of these proposals by SAP or by those that have some HANA quota to fill is false.

False Claims About HANA

  1. HANA DB still uses aggregates. There are in fact many good reasons for maintaining aggregates. Reference tables are aggregates.
  2. SAP is not releasing benchmarks on HANA DB for OLTP because as per HANA’s design these benchmarks are likely to be disappointing. But this does not stop SAP from claiming that HANA DB is equally effective at OLTP and OLAP (transactions and reports — excuse me “analytics”)
  3. SAP’s compression estimations are greatly exaggerated and require heavy archival (a cost) and will result in companies having to go back to SAP after the fact to purchase more HANA license GBs.
  4. Fiori is not a complete UI for S4. Instead, Fiori is a niche set of apps. A set of apps has yet to be demonstrated to work any better than the parts of SAPGUI they are replacing. And a set of apps that in 98% percent of cases will only work with applications that sit on top of HANA DB.
  5. S4’s data models are not simplified. There are more tables than ever with a column-oriented database as many of the columns have become their tables. Indexes are eliminated with column-oriented databases. That is a reduction in complexity. But other areas increase in complexity, including the need to rewrite every single adapter that connected to ECC. Simplification of data models (even if true) does not lead to simplified business processes (which is the SAP claim).
  6. SAP never mentions the need to update 20 fields in one record; we end up with 20 updates instead of one update on row-based databases.
  7. The CPU and the RAM are the hardware level. You cannot benefit from using something at a level if it is already used at that level. This would be like saying “you will be able to use the steering wheel at the automobile level.” There is no another way to interpret this except it is a purposely redundant statement that is supposed to sound technical and esoteric. It is designed to impress people who don’t know how software works.

Selling Nonsense

If you sell nonsense for a living, you are not going to stop just because I call you out on it. You need to obscure the issue so you can keep selling nonsense. From financial advising to medicine to IT consulting and strategy consulting, nonsense is a great thing to sell. It is great for your career and your pocketbook. It is about impossible to meet a quota without it.

 Saving that Face

Face-saving. As I learned when I worked in Asia, face-saving is big in Asian culture. And the term was used a lot when I worked there. But while I don’t support mean-spiritedness, people that make big claims that turn out to be the false need to own up to it and be exposed for being wrong. If not we would not have science. We would be more concerned about embarrassing people who were wrong and never make progress. So to protect Stan’s face, we would continue to agree that the moon is made of green cheese.

This is presently a big problem in IT and IT forecasting. I like to say that the only thing anyone is held accountable for regarding prediction is meeting their sales quota. Gartner has quite a poor accuracy level in their forecasts.

  • They were responsible for priming the ERP bubble in the eighties.
  • The marketplace bubble in the late nineties.
  • They are currently pumping up the Big Data and analytics bubble as well as the IoT bubble.

But do you see Gartner paying a financial penalty for being the Helen Keller of IT forecasting? No, they are richer, more powerful and more influential than ever.

Unfortunately, there is no entity that calls out individuals or companies that knowingly distribute false information on IT topics. And this has lead to a bubble in buffoonery.

Diverting Attention from Previous False Statements

I have spent a good deal of time investigating the performance claims and many other claims on HANA DB. Here is what I have found.

  • The uniqueness of HANA’s performance has been explained in my previous articles as entirely manufactured by SAP. There was never any truth to it. The people that proposed this are diminished in my eyes for the lies that they told. At the tip of the lying spear is Dr. Hasso Plattner, but there are plenty of other culprits.
  • SAP has proposed that end of period close, and MRP use is held back by not having a database like HANA. This is false as neither process is a bottleneck at the vast majority of companies. If as a company you have a system processing constraint with either of these processes, you are in the distinct minority. Instead of moving to HANA, you should try to find lower cost ways of figuring out what the problem is. As soon as a person raises either of these issues, I know that one of two things must be true. Either they know its incorrect but are willingly stating that these things are the case. Or secondly, and perhaps what can be more forgiven, they are simply repeating what the read in some SAP marketing material. Let us discuss reasonable expectations. One should not expect account managers or partners who have never touched SAP in 10 years or been on an SAP project to be reliable sources of information on technology topics.

Backflushing is Performed Because of a Lack of Database Speed?

Recently SAP proposed that even backflushing is performed because of a lack of database speed. And that HANA was going to come to the rescue to all these poor companies that have had to perform backflushing because their ECC systems cannot perform goods issue due to system performance problems. This is truly farcical as backflushing moves the goods issue processing from real-time to be run in batch. Can SAP seriously think they can convince people that ECC sitting on a non-HANA database lacks the processing capability to perform something as simple as a goods issue in real time??

Backflushing has never been done (at least in the modern era) because of performance limitations. Backflushing is performed because the company wanted to carry out the activity first and record the issues after the fact. Backflushing is very common in process industry manufacturing. This is because it can often be unclear how much material will be consumed in a manufacturing process.

Diverting Attention

HANA proponents enjoy diverting the attention from the original topic. They gain the high ground by claiming other benefits that come from these other areas of “improvement.” The deflection mechanism is the consistent approach by those who have been consistently wrong on HANA. The algorithm looks like this:

  1. Standard HANA DB Pitch: If you find an uninitiated audience, give the standard line about how HANA is revolutionary due to its speed. Hide the fact that other database vendors have the same technology. Pretend that you invented the idea that data can be stored in an SSD.
  2. Dealing with Hecklers, Malcontents & People that Won’t Accept the Sales BS: If (on the rare occasion) you find an individual who knows this is not true, respond that HANA is much more than a database and about “much more than speed.” Do this even though you know that each of the items that are “not just a database” actually has their names like HANA Studio, HCP. And that these products have no logical reason to have the term HANA in their product name. And further, ignore that SAP’s first promotion of HANA DB has been based upon database speed.
  3. Misdirection: Having regained the argumentative high ground, now make false claims, but now in different areas. I call this maneuver the “Hasso Plattner.” Make so many claims in so many different areas that the person you are speaking to may not feel comfortable addressing them all. Force the respondent to perform research in many different areas to respond to your proposals. But you conduct no research at all! Simply repeat false statements provided to you by SAP marketing.
  4. Use Project “Proof”: Bring up illusory benefits that you have seen at all these clients you have visited. Where HANA is just transforming, the way companies do business. This will also communicate to the LinkedIn community that you are a real expert in HANA. Don’t bring up any complications of HANA. And never discuss costs.
  5. Employ the Concept of Universal Virtue: Talk about how you are all about improvements. And that these things are necessary to make these improvements. Promote the concept that both you and SAP are all about “client value.” I had one commenter state that SAP should be allowed “maximum forgiveness” for any false statements that it made. The reason? Because it was all about moving companies to a “fill in the blank” (digital economy), (memory resident future), (IoT), (running simple),(integrated solutions).

Massive Exaggerations

If SAP has massively exaggerated the issue of HANA DB performance. Both of the perspective of the performance itself as well as the application or business case for that performance. Then that is a problem. It is not an adequate or honest response to respond to this particular criticism with a comment related to how HANA DB is “more than a database.”

That only starts up another discussion. It may or may not be, but the statement I made is regarding HANA’s performance and value. That statement needs to be answered without diverting into other areas because one can’t respond to the actual question with convincing evidence.

When faced with the inaccuracies from SAP a few SAP consultants moved to a new approach to divert attention from HANA’s false claims. This was to declare that it was not relevant because the database was after all “not that important.” 

SAP’s Official Position the Database

SAP’s official position is that HANA is a massive differentiator. So if SAP says something and it turns out to be false, then that is relevant.

Since HANA’s introduction, it has been a steady drumbeat from SAP as to why the database is critical and why customers need to switch as soon as possible to HANA. ASUG’s position is that as SAP is the strategic vendor, those companies need to migrate to S/4HANA. There is no backing off of the emphasis that SAP has placed on the database since HANA was introduced in 2011.

The Logic for Limiting S/4HANA to HANA

Let us also remember the logic for limiting S/4HANA to HANA — that no other database vendor can keep up with SAP’s innovation. SAP is restricting choice and doing so for purely commercial reasons, all while telling people it is for technical reasons. This entire storyline is false and is provable as false.

SAP’s Credibility Hit Due to HANA’s Claims Being Found to be False

If what is true is important than this is a problem not only for this specific subject but for companies that intend to listen to advice from either SAP or SAP consulting companies on other subjects.

HANA’s Predicted TCO

Second, our research predicts that HANA will have a greater than 2x TCO versus competing databases. Again, SAP stated that HANA’s TCO would be lower — lower even than when HANA replaces an existing database and will implement faster than an already implemented database. The second sentence is impossible, and it should be obvious why. You don’t have to pay this extra TCO, but disrupting the database layer for what turn out to be negative reasons (that is you are worse off as a company after you do it) but the customers do have to deal with this wasteful disruption. This means that SAP has been and will continue to misdirect IT budgets into HANA.

HANA’s Performance Problems with S/4HANA

A final reason to care about HANA even within the context you mention is that HANA has performance problems in supporting ERP as we covered in the article The Mismatch Between HANA and S/4HANA and ERP. 

This fact alone means that S/4HANA’s value proposition is compromised. But once you include S/4HANA’s implementation history, how S/4HANA’s risk is so high, its difficult to find a major application with higher risk right now.

The Issue with the Perceived “Importance” of the DB

We all tend to think that the “important thing” is whatever we happen to work in. I focus more on the application area myself. However, I am personally amazed by what databases can do. Databases are an amazing intellectual achievement. Once you spend time with a database person or developer who takes you through what is possible, they seem like magic. Non-database people tend to think terms of spreadsheet tables with the tables just pointing to each other (as the ERD diagram).

However, that is a vastly oversimplified construct.

Many application people tend to see development as something not to focus attention. They may say “just give me the app.” I used to think that way myself. Better understanding development as I have in the past year or so leads one to question application design rather than accepting what is available. The current applications we have are just what someone thought made sense. They are not necessarily right or the best way to do things, and with development capability, you can make whatever you want, not what someone else thinks is right.

Taking Things for Granted

It is also easy to take things for granted once they have been mastered. Databases run far more smoothly than applications at this point, so it is easy to think that they are not as important.

Its a bit like how often you think about your feet is how directly proportional to how good your shoes are. If you have good shoes, you do not really think about your feet.

Understanding Pivot

It seems like there is a pattern that is established. It goes like this…

  1. The first position is that SAP is 100% correct and this is the future. The early presentations were that SAP had the best database in the world with HANA, and everyone who did not switch to HANA was an idiot. Hasso Plattner had a well-known blog post where he said those who question HANA’s value “just don’t get it.”
  2. When faced with evidence that undermines SAP’s claim, there is a transition to saying that there are some “misunderstandings” about SAP.
  3. When SAP is proven entirely wrong, and or to have deliberately misled people, that the topic area is not important anyway. Then the pivot happens to another topic, and new claims are made that once investigated are also false.

Using this strategy means that SAP is never held accountable for what they say.

Conclusion

Getting quality IT information is a tricky business. There are a lot of overconfident and dishonest people out there who will unthinkingly repeat false information and then defend their positions if questioned. They will try to sell the future. They will pretend they have seen benefits where they haven’t. They will use unproven arguments like a new application that no one has performed a TCO calculation on automatically lowers TCO. They will use ad-hominem attacks. They will rely on concepts that have been long ago disproven (best practices, preconfigured solutions, rapid deployment solutions).

They will even stoop to proposing that the database is not that important anyway.

The one thing they all have in common is never admitting they were wrong.

Search Our Other HANA Content

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

I cover Gartner in depth in the following book.

The Gartner Book

 

GARTNER-1Gartner and the Magic Quadrant: A Guide for Buyers, Vendors, and Investors

How to Figure Out How to Effectively User Gartner

Whether you are a software buyer, a large or small vendor, or are wondering how Gartner can help you make better investment decisions, this book will give you new insights to Gartner’s research. By studying the methodology behind such popular analytical tools like the Magic Quadrant, you will understand how a vendor earned its rating and whether or not the ratings are justified!

Understanding Gartner, It’s History, and It’s Incentives

Starting with the history of Gartner and how it compares to other IT analyst firms, this book gives a realistic assessment of the value of Gartner research to a company and provides ideas about other resources that could complement Gartner’s analysis. You will also have the tools to level the playing field between large, medium and small vendors when using Gartner’s analysis in selecting software.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: An Overview of Gartner
  • Chapter 3: How Gartner Makes Money
  • Chapter 4: Comparing Gartner to Consumer Reports, the RAND Corporation, and Academic Research
  • Chapter 5: The Magic Quadrant
  • Chapter 6: Other Analytical Products Offered by Gartner
  • Chapter 7: Gartner’s Future and Cloud Computing
  • Chapter 8: Adjusting the Magic Quadrant
  • Chapter 9: Is Gartner Worth the Investment?
  • Chapter 10: Conclusion
  • Appendix a: How to Use Independent Consultants for Software Selection
  • Appendix b: What Does the History of Media Tell Us About This Topic
  • Appendix c: Disclosure Statements and Code of Ethics

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

How Accurate Was Hasso Plattner on SAP S/4 HANA?

Executive Summary

  • Hasso Plattner makes an enormous number of inaccurate statements about S/4HANA.
  • How much of what Hasso Plattner said about S/4HANA was true?

Risk Adverse HANA

Introduction

On November 30, 2015, Hasso Plattner published How to Understand the Business Benefits of SAP S/4 HANA Better.

This article shows some apparent frustration on the part of Plattner with the well-documented fact that SAP’s customers are having a problem seeing the value in SAP S/4 HANA.

Let us understand each of observations by Plattner and see how they stack up. You can first read the article by Plattner, which I have provided the link above and then read this one as I have taken out what I think are the most relevant quotes. I have each of the quotes and my comments organized under the specific headings that are from the article by Hasso Plattner.

Let us begin at the end of the article.

Slow MRP

Hasso’s Introduction

“It is sad to still hear the same arguments after all the sales success, the implementations in record time and happy productive customers. We have written books, where we describe dozens of new or improved application scenarios, specific events are taking place throughout the world and we have many success stories on our website. I just heard of a Chinese fashion manufacturer who installed SAP S/4HANA and reports a game changing improvement of the MRP2 run from more than 24 hours to under two hours. My advice for the smaller and midsize SAP Business Suite customers is to carefully watch the early adopters, soon approaching 2000, especially in related industries.” – Hasso Pattner

In the first part of the quotation, Hasso declares the sadness to hear some general arguments against HANA due to sales success. However, has HANA had sales success? No. HANA has been the most significant marketing initiative ever undertaken in the enterprise software space, however, while SAP has “sold” quite a few HANA licenses (at a debatable cost), the number of live HANA instances is tiny. I have seen HANA at literally one of my customers, and of course, it was for BW. So this success is an assumption made by Hasso that merely is untrue.

On the next topic of the case study that Hasso presents above, why is MRP taking 24 hours to run at this Chinese company?

Interpretation

Let us start off by understanding that MRP is the simplest of the supply and production planning methods and it was first designed to run on hardware from the 1970s.

It is true that current MRP goes further down the bill of materials then perhaps MRP runs did in the 1970s. Still, if MRP is taking 24 hours to run in any system then either the hardware is tiny, or there is something wrong with how MRP is setup — which is strange because MRP in SAP has very few settings. If a company is taking 24 hours to run MRP, something is very wrong and needs to be evaluated. Hasso did not explain if this evaluation happened, but instead stopped and declared that the solution was implementing HANA. However, implementing HANA for MRP means implementing S/4HANA — which is a major issue. This means a Chinese company, which tend not to be new technology adopters, and do not have significant IT budgets compared to the US and European companies — decided to implement HANA.

  • I cover MRP in the book Supply Planning with MRP, DRP, and APS Software, and have extensive experience with MRP and all of the supply and production planning methods, and Hasso’s statements here do not make any sense.
  • Secondly, in my book Repairing your MRP System, I explain that a significant factor which holds back running MRP well is the fact that MRP is so frequently run from the ERP system — and ECC and S/4 HANA are ERP systems.

This is because ERP systems provide poor quality MRP functionality when compared to applications that specialize in supply planning. For instance, if I talked about a 24 hour MRP runtime with the best of breed vendors that I know of that can run MRP they would fall laughing. We better move one, because I am starting to laugh thinking about this proposal myself.

There is something very fishy about this story of a 24 hour MRP processing run. Much more would need to be explained, but under no scenario should it take anywhere close to that amount of time to run MRP.

Hasso on The Reduction in Complexity from S/4 HANA

“For years our customers complained about the complexity of the business suite and asked for simplification. Now some fear they have to relearn a lot and that will cost time and money. The simplification of the UI is real and will save time with the first day of productive use. The business functionality of the transactions is still the same but comes in a much more efficient form.

The dramatic simplification of the data model, the fact that any field can be used as an index for selecting data and the unprecedented short response times are allowing for much faster development cycles of new applications. The deployment of extensions in SAP HANA Cloud Platform is an elegant way to enhance SAP S/4 HANA systems or to build completely new applications. SAP S/4 HANA combines the proven set of core business functionality, in many languages and for nearly all countries, with the ability to venture into completely new dimensions of applications. This capability is key when business processes are developing at an ever increasing speed and core enterprise systems cannot just be complemented by point solutions but have to also accommodate these changes.  This reduction in complexity also lowers the threshold for smaller companies to switch to SAP S/4 HANA.”

Let’s look into the detail in each area brought up by Hasso.

  • For Years Our Customers Complained About the Complexity of the Business Suite (ECC): Yes, this is true. However, most of the complaints did not have to do with what HANA is improving (which is primarily analytics). Many of the companies complained about complexity with the SAPGUI, or areas of functionality that did not work, or problematic help that made the feature difficult to decipher, or a long list of complicated items that make up SAP software. So Hasso seems to be mingling a number of issues here. However, again SAP buyers cannot expect Fiori to cover many of the ECC screens for some time. So Fiori will be used along the same old SAPGUI. Therefore, complaints will continue.
  • The Dramatic Simplification of the Data Model: I cover in Getting Clear on S/4 HANA, that it is debatable whether HANA simplifies the data model.
  • ..The Ability to Venture into Completely New Dimensions of Applications: It’s hard to see how this is true. S/4 has a (partially) new UI. And Fiori can be customized much more easily than SAPGUI. However, it’s still a lot of work, and there is not a consensus on Fiori yet regarding whether it will stick long term. The later part of this paragraph is fanciful sales talk, and it is difficult to address what Hasso is describing.

Interpretation

This quotation is mostly incorrect.

Hasso Plattner on How Disruptive is SAP S/4 HANA

“All master and transactional data will be migrated, all the business processes are still available, the new UI is easy to comprehend and most importantly the application configuration can also be carried forward. Many long term SAP customers are contributing in the design efforts of the new user interaction. By applying the principles of design thinking, end users, consultants, domain experts and developers interact till the most comprehensive solution is found. All predefined aggregate data (totals, info cubes) have been eliminated and the system offers now the highest flexibility in reporting and analysing business data.

The first step in an SAP S/4 HANA project should be the evaluation of the system without the company specific modifications and extensions but using the customer production data set. Many new features are added and may make modifications obsolete. Don’t extrapolate the amount of work and training from previous experience with ERP release changes. Once the data is carried over to SAP S/4 HANA everything will be much faster. In case of an on-premise or hosted deployment, the previous UI will still be available in order to ease the transition phase.”

The first part of this quotation is not really to be commented upon because of there it is generalized. For instance, the idea that all the business processes are still available is evident, as S/4HANA directly takes ECC functionality and puts it onto HANA. But later on in the first paragraph, there is something to comment on.

  • All Predefined Aggregate Data (Totals, Info Cubes) Have Been Eliminated?: Yes, this is true. All of the things that used to be performed on the backend in the BW now is not necessary for HANA.
  • Don’t Extrapolate the Amount of Work and Training from Previous Experience: Not only is Hasso’s proposal here untrue, but it will also be significantly more work, and it is indeed more risk to upgrade to S/4 HANA. S/4 HANA has a new database and a new user interface. It changes all of the enhancements that SAP customers have because the tables structures have changes, which means the already existing improvements must be modified. There is all manner of questions as to S/4 HANA implement ability as Simple Logistics was just very recently released. It is merely an absurd contention that S/4 will be less work to upgrade than previous versions of SAP’s ERP system.
  • Once the Data is Carried Over to SAP S/4 HANA Everything Will be Much Faster?:  The fact that S/4 HANA will be faster should not be blended with the amount of work and training and risk associated with implementing such a new and lightly implemented application. And analytics will be faster, but transactions will only process faster because of the hardware advantage of HANA. Columnar databases are sub-optimized for transactions, or that is most of what SAP’s ERP systems do. I cover this in detail in the article What Makes HANA So Fast? 
  • The previous UI will Still be Available to Ease the Transition Phase: This contradicts earlier statements that the UI or Fiori will be so much easier than SAPGUI. However, potential buyers of S/4 HANA should also know that probably a more important reason that the SAPGUI will be used no matter what is because Fiori is not complete for all of the old ECC screens, a fact that Hasso is leaving out of his article. I cover this topic is What is Actually in the Fiori Box? 

Interpretation

This quotation is mostly incorrect.

Hasso on How Complete SAP S/4 HANA Is

“One of the reasons why companies have more long-term plans for SAP  S/4 HANA is the completeness of the product. To recreate the wealth of functionality of the business suite is quite a challenge, but now financials, sales and logistics are available and most of the industry specific solutions will follow soon. SAP wants to achieve a better separation between the industries in order to reduce potential conflicts between them. Every transition case from SAP ECC 6.0 to SAP S/4 HANA has to be evaluated individually but most of the installed base should be covered by now. Many clients choose to become familiar with SAP HANA by moving the business warehouse onto SAP S/4 HANA or start with completely new projects in product research or service including internet of things scenarios.”

Interpretation

This is not at all correct. Let bulletize this list because there is a lot here:

  • Companies Have S/4 HANA in Long-Term Plans? I don’t think its established that companies have long-term plans for SAP S/4 HANA. SAP has an enormous installed base, and they have heavily pushed S/4 HANA, and there are still extremely few clients live on S/4 HANA. There are many questions regarding its actual implement ability.
  • Recreate the Wealth of Functionality of the Business Suite: I don’t know why Hasso is phrasing it this way. SAP is not recreating anything – it is porting ECC functionality to a new set of tables, the columnar tables of HANA. And secondly, not all functionality in ECC is making it over to S/4HANA.
  • Industry Specific Solutions: Most of the SAP Industry Solutions are more for marketing than anything else. Once you get to implementing you will find that there is little to leverage. I have gone through this with many different industry solutions. They are primarily marketing fiddle-faddle. For example, SAP has a Repetitive Manufacturing Industry Solution, and after you get through analyzing it, its makes no sense to turn on, but you can waste a lot of time analyzing and testing it. So, whether S/4 HANA is ported to “Industry Solutions” it’s not real.
  • Converting the Installed Base to S/4 HANA: The idea that most of the installed base should be converted to S/4 HANA now, considering that there are so many implementation questions about S/4 HANA’s readiness, considering the extra cost, considering that all the previous customizations that customers have written will need to be rewritten, considering a number of other items are utterly delusional.
  • BW: BW can be moved to HANA most easily because HANA is primarily an analytics database. BW’s implementation onto HANA is quite smooth. However, HANA happens to undermine many of the functionality of BW, which can be the topic of a future post.

HANA Disruptive

Hasso Plattner on How Disruptive is SAP S/4 HANA

“All master and transactional data will be migrated, all the business processes are still available, the new UI is easy to comprehend and most importantly the application configuration can also be carried forward. Many long term SAP customers are contributing in the design efforts of the new user interaction. By applying the principles of design thinking, end users, consultants, domain experts and developers interact till the most comprehensive solution is found. All predefined aggregate data (totals, info cubes) have been eliminated and the system offers now the highest flexibility in reporting and analysing business data.

The first step in an SAP S/4 HANA project should be the evaluation of the system without the company specific modifications and extensions but using the customer production data set. Many new features are added and may make modifications obsolete. Don’t extrapolate the amount of work and training from previous experience with ERP release changes. Once the data is carried over to SAP S/4 HANA everything will be much faster. In case of an on-premise or hosted deployment, the previous UI will still be available in order to ease the transition phase.”

The first part of this quotation is not really to be commented upon because of there it is generalized. For instance, the idea that all the business processes are still available is evident, as S/4HANA directly takes ECC functionality and puts it onto HANA. But later on in the first paragraph, there is something to comment on.

  • All Predefined Aggregate Data (Totals, Info Cubes) Have Been Eliminated?: Yes, this is true. All of the things that used to be performed on the backend in the BW now is not necessary for HANA.
  • Don’t Extrapolate the Amount of Work and Training from Previous Experience: Not only is Hasso’s proposal here untrue, but it will also entirely be significantly more work, and it is indeed more risk to upgrade to S/4 HANA. S/4 HANA has as new database and a new user interface. It changes all of the enhancements that SAP customers have because the tables structures have changes, which means the already existing improvements must be modified. There is all manner of questions as to S/4 HANA implement ability as Simple Logistics was just very recently released. It is merely an absurd contention that S/4 will be less work to upgrade than previous versions of SAP’s ERP system.
  • Once the Data is Carried Over to SAP S/4 HANA Everything Will be Much Faster?:  The fact that S/4 HANA will be faster should not be blended with the amount of work and training and risk associated with implementing such a new and lightly executed application. And analytics will be faster, but transactions will only process faster because of the hardware advantage of HANA. Columnar databases are sub-optimized for transactions, or that is most of what SAP’s ERP systems do. I cover this in detail in the article What Makes HANA So Fast? 
  • The previous UI will Still be Available to Ease the Transition Phase: This contradicts earlier statements that the UI or Fiori will be so much easier than SAPGUI. However, potential buyers of S/4 HANA should also know that probably a more important reason that the SAPGUI will be used no matter what is because Fiori is not complete for all of the old ECC screens, a fact that Hasso is leaving out of this article. I cover this topic is What is Actually in the Fiori Box? 

Interpretation

This is a tough portion of the article from Hasso Plattner. There is lots of commingling of separate concepts and things that do not make sense.

S_4 HANA New

Hasso Plattner on The New Concepts for Sales, Customer Support, Product Development

“After the simplification of the main application in sales, logistics and finance, the development of new functionality has started and will be rolled out in short release cycles. It is paramount that SAP and its community learns how to efficiently deal with shorter release cycles, without introducing any kind of instability. The reduced complexity of the data model and the removal of transactional data aggregation clearly improves robustness.  The focus on the SAP HANA platform allows for better applications, because the technical advantages of SAP HANA can now be exploited without consideration for compliancy with other platforms. This is a formidable advantage and as mentioned before a strategy taken by all other providers of cloud services.”

Interpretation

  • Simplified Sales, Logistics and Finance and Shorter Release Cycles: It is not clear how sales, logistics, and finance were simplified with S/4. And SAP could have developed new functionality over a decade ago for ECC but chose not to. The reason was to get more sales from non-ERP products that they could sell a new license for. So this seems to be an empty promise. SAP should learn how to deal with shorter release cycles without introducing any stability efficiently, but currently, SAP has problems even with very long release cycles without introducing functionality that is broken upon arrival. So it’s a strange thing overall for Hasso to say.
  • The Focus on the SAP HANA Platform Allows for Better Applications Because the Technical Advantages of SAP HANA Can Now be Exploited Without Consideration for Compliancy with Other Platforms: Why is this true? Hasso is repeatedly referring to advantages of S/4HANA and HANA without providing any reason at all to think this is true. SAP is only one part of the picture within SAP customers, so SAP must always content with other platforms. Secondly, Hasso is speaking in such an unspecific manner that it can be difficult to confirm or disconfirm his statements, this one being a perfect example, because he is not even clear what he means. It is difficult to see why that is true. Why is being compliant with other platforms, not a consideration? Nothing has changed here. Any system must be implemented with consideration with how it connects to other systems.

Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.

Conclusions

There is not much to take away from this section of the paper by Hasso Plattner. The statements are not substantiated.

Search Our Other S/4HANA Content

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://news.sap.com/how-to-understand-the-business-benefits-of-s4hana-better/

I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

Does SAP S/4HANA Actually Have a Simplified Data Model & Faster Financial Reconciliation?

Executive Summary

  • SAP has proposed that HANA and S/4HANA has a simplified data model.
  • We validated these claims including different account silos, faster reconciliation, understanding the performance of the columnar database.

Introduction: A Simplified Data Model?

SAP has been very consistent in pointing to the benefits of S/4HANA’s simplified data model and as part of its SAP Run Simple marketing program.

However, after listening to this sometimes, and reading on quite a bit of SAP marketing literature, I began to question this assertion of the SAP Run Simple program. In this article, you will learn whether S/4HANA has a simplified data model.

Interpreting SAP Run Simple Related to S/4HANA and HANA

When watching a presentation by SAP, or reading through documents related to S/4HANA and HANA generally, the proposed benefits “come at you” very fast.

It takes some time to sit down and look at each of the proposals individually to determine if they are either true or likely to be true.

Importance of Verifying the Simplified Data Model for SAP Run Simple

Understanding the concept of SAP’s proposal regarding a simplified data model is important as it is used as a foundation on which to build an argument for other benefits, one of the most important beings that overall S/4HANA is more simple to use. However, the one I will use in this article is the proposed benefits to financial reconciliation.

The SAP states clearly regarding S/4HANA having a simplified data model for SAP Run Simple.

Jens Kruger from SAP has a video on S/4HANA, and he states that.

“S/4HANA offers a simplified data model.”

And that…

“All data is available without reconciliation, leaving financial departments to strategic tasks instead of  just doing administrative functions. How can this be done? This is based upon a simplified data model. The simplified data model enables insights into financials data. “

He then goes on to say:

 “All of those silos required a reconciliation in order to get a consistent view on the data. And therefore getting instant insight into data across all silos is not possible. Therefore, the power of SAP HANA underneath the universal journal entry creates a single source of truth, and there is no reconciliation needed.”

 “Under a traditional close, it is consists of a lot of steps. They must be performed in a batch fashion since they are just running too long. With the SAP HANA platform we are now able to reduce this.”

And Jen also provides specific speed improvements.

Here is where the proposed speed improvements are declared by SAP. This is interesting because I had never heard that reconciliation was negatively impacting so many global FI/CO implementations, which is what Jens Kruger is proposing. 

Different Accounting Silos?

Jens identification of Financial Accounting Documents, Controlling Documents and Profitability Documents as separate silos are strange. These are all integrated transactions within the FI/CO module currently in ECC. However, his point seems to be that reconciliation times in ECC presently make them break into different silos.

S/4HANA’s Data Model

Let us clarify what a data model is before we go through to validate the claim regarding its simplification.

A data model is the set of tables and the relationship between tables that are used — in this case — for the application to call upon. I have included just a small part of the data model in SAP ECC related to Work Centers, the Bill of Materials and the Production Version.

A simplified data model would mean that the tables and the relationships, as well as the primary versus secondary or supporting tables, are simplified. However, it can only partially say to be true of HANA. Here is why: 

  1. The Use of Columnar Tables
  2. Relationships Between the Tables
  3. Fewer Indices and Aggregation Tables

The Use of Columnar Tables

HANA uses columnar tables, which means that many tables are a single column. This of course significantly increases the number of tables that are necessary, and because the previous tables need to be emulated for people that need to see and work with the data, the data model is not simplified.

Relationships Between the Tables

SAP’s point is probably that they cleaned up the relationships, and having reviewed many previous SAP tables and modeled the tables in ERD diagrams, I can say that many of the tables and the relationships between the tables were indeed convoluted in their design.

When software development happens, the idea is that all the tables are laid out ahead of time, but the reality is that often the tables are added in a way that is more holistic, and much of ECC was written before more advanced data modeling tools were available.

Fewer Indices and Aggregation Tables

There are fewer database speeding mechanisms needed like aggregates and indices, but this is not the actual data model. SAP may be using a shorthand here that when they refer to the term “data model” they mean all of the tables used in the database. I think that could be a fair point. It is true that columnar databases tend to need fewer supporting tables. However, HANA still uses aggregates, although they call it something else. In fact, it is right on the SAP HANA website. Aggregates are beneficial because they are precomputed combinations that are always reused.

What should be apparent from the bullet points above is that the “data model” simplification that is so breezily referred to by SAP is not definitive in any shape or form. With a columnar database, some areas become more simple, other areas more involved. Overall, there are also complexities involved with a new database, so I would predict that HANA will be more complicated than a company’s previous database installation. That is the issue with new products, and the more new, the more unpredictable outcomes.

I cover these type of risk interpretation topics in the book Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects. One of the issues I bring up in the book is if the software vendor has too much influence over the consulting company, the outcome can be highly risky projects being proposed.

Simplified Data Model = Faster Reconciliation as Part of SAP Run Simple

Is it the simplified data model that speeds reconciliation and therefore creates a single version of the truth? As I just discussed, using a columnar database uses fewer assisting or secondary tables, But it also creates a lot more tables, with many more relationships, in addition to having to generate the views of the previous tables of ECC. As it is illogical to work with just a bunch of columnar tables.

If you go into ECC on HANA, you will see all the same tables that you have seen before because they are emulated by HANA — so how much this is simpler depends upon your point of view.

Understanding the Performance of the Columnar Database

Secondly, a columnar database like HANA will underperform a standard row based (aka relational database) in transaction processing — and this includes year-end close (all other things being equal).

When HANA is proposed to be universally virtuous in performance in all situations, remember that a columnar database only outperforms relational databases for analytical applications. However S/4HANA is intended to sit only on HANA (although I see this exclusivity changing in the future), but HANA uses much more expensive and higher speed hardware, so the increase in speed, in this apparent non-analytical application, will come from more costly and higher speed hardware only.

Therefore, the statement that HANA’s “simplified data model” will lead to faster reconciliation is not true.

Why Faster Hardware is Actually What Will Lead to Faster Reconciliation

However, if we give it some consideration, this faster settlement will be equally available a company that would simply port its current ECC system to faster hardware.

Multiple Versions of the Truth?

It seems that SAP is changing the previous story on ECC to make points for S/4HANA. I don’t think that SAP would be talking about how terribly slow its reconciliation and period closing is in ECC if they were not trying to sell S/4HANA (call me cynical). If this is all true about reconciliation latency, then the question is do other software vendors face this issue.

To find out I reached out to two financials vendors, Intacct and FinancialForce, two accomplished vendors in the area of financial applications, to determine if they have similar reconciliation problems. Neither of them uses an in-memory database. Neither of them seemed to have heard of the problems with reconciliation and period closing that is described by SAP. When I spoke to FinancialForce they had the following to say about reconciliation and period closing in their system:

“You need to do all the things to setup the year end, and we have an automated button that performs all of the reconciliation. The a button is hit and the journals are created for you. This is not even a batch job process — in that it may take 30 minutes to 2 hours, with 2 hours being on the very long side.”

Therefore, what amounts to a quarterly or yearly process takes in most cases roughly 45 minutes. So if we take SAP’s proposal, S/4HANA will cause save 420 hours on the quarterly close. If that is the number of hours saved, how many total hours are present ECC systems taking exactly? That just sounds terrible.

Something which is not being adequately explained by SAP is that there are things to check before reconciliation is performed.

Reconciliation Speed Issues?

ECC’s hardware, not the data model of ECC versus S/4HANA is what is attributed to reconciliation speed changes. But secondly, two financial vendors are unaware of the batch problems in their systems that SAP has attributed to ECC.

Here are some important things to consider when interpreting the message of reconciliation and period closing as described by SAP:

  • It should be remembered quarterly closing is only a small portion of the activities performed within FI/CO.
  • Finance is not an area which requires a lot of computing power, and SAP is stretching here to find something that can help sell S/4 Simple Finance.

Conclusion

The information provided by SAP on this topic is convoluted, and once broken down into its constituent pieces it does not add up. Jens Kruger of SAP is commingling several different topics to make a case for S/4HANA Simple Finance, but the items that he attributes to HANA are not related to what he calls out. All of this is part of the attempt to fit into the SAP Run Simple marketing program. However, SAP Run Simple has little to do with reality. SAP Run Simple is nothing more than a marketing construct.

There is also appears to be the exaggeration on the part of SAP as to the impact of quarterly closes. This is not the first time I have seen this type of proposal from SAP. SAP also uses the example of long run times for MRP used to justify Simple Logistics. Why these issues have not been brought up more on articles on S/4HANA is a concern. However, I suppose that gives me the opportunity to provide some very good value to my readers and my clients. But it brings up a lot of issues regarding either the knowledge level or the independence of many of the media outlets that carry stories and are supposed to analyze SAP. For software buyers, if you have a consulting company that is proposing to you that the SAP S/4HANA data model is simplified, that would bear explanation on their part as to why that is. If they are just blindly agreeing with SAP on everything, then they will be limited in how much they can help you.

Recommendation

My recommendation is that the time required for reconciliation and quarterly closes be benchmarked in the client’s current ECC system to determine whether or not this is an issue. Statements about the reconciliation and quarterly close time should not be looked at in a separate matter but checked against what other software vendors in the area have to say on the topic.

Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.

Search Our Other S/4HANA Content

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

Marketing constucts like SAP Run Simple and simplified data models that have nothing do do with reality detract from implementing beneficial programs. I cover how to interpret risk for IT projects in the following book.

The Risk Estimation Book

 

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.

project_software_risk

Getting Clear on SAP’s Claims on S/4HANA

Executive Summary

  • It is very difficult to get clear on S/4HANA. SAP uses the language of selling to propose a number of false concepts including the idea that S/4HANA has a simplified data model, that Fiori is complete, that there has been a reimagined business model and business process. Further, that SAP will never have any latency, and that everything will run so smoothly on HANA.
  • In other words, just a typical explanation from SAP.

SAP HANA Introduction

SAP HANA is SAP’s database which combines a columnar database with very fast hardware.

There has been quite a bit of marketing information written on S/4HANA or HANA ERP. S/4 is the ERP system then runs on the HANA infrastructure in the most recent release. The “S” is supposed to stand for simple, and the “4” being what would follow “3” as in R/3. The overall naming convention is strange and confusing all by itself. When the finance area is referred to it is “S/4HANA Simple Finance,” and when the supply chain area is referred to its “S/4 Simple Logistics.” There is no way I can see the world “simple” being continually used on projects, so these names are going to have to change at some point. HANA is the infrastructure/database, and I am not aware of any application having the database name as part of its name, so at some point, S/4HANA will probably be renamed to something without HANA in the overall name.

S/4HANA or HANA ERP is the first major upgrade to what was R/3. It would take a lot of time to explain all the changes, but this article won’t focus on that. Instead, I will concentrate on making sense of the statements made about S/4HANA or HANA ERP by SAP. This should of significant value to people because the messaging on S/4HANA is confusing.

In this article we will cover some of the common claims made by SAP about S/4HANA.

The Language of Selling

What should be understood is that S/4HANA marketing documents are not necessarily designed to be true, but to sell S/4HANA. That is why much of the S/4HANA material often seems strange to an experienced implementer. There was never anything that was ERP in 2004. R/2 was a green screen system. R/3 was a client-server system, which had a Windows user interface. R/3 has been renamed over the years to ECC and then to SAP ERP (which never took) and then to Business All in One, but none of these names meant anything regarding referring to something new in the application, they were just marketing terminological changes.  R/3 has stabilized some years ago, which means that it has seen little in functionality enhancement since that time.

SAP proposes that S/4HANA has the following benefits:

  1. Simplified Data Model
  2. Completely Fiori
  3. Guided Configuration
  4. Reimagined Business Models
  5. Reimagined Business Processes
  6. No More Batch — All Processes in Real Time
  7. Reimagined Business Decisions

Claim 1: Simplified Data Model?

I moved this response over to a separate article titled Does S/4HANA have a Simplified Data Model?

Claim 2: Completely Fiori?

Fiori is the new SAP user interface. However, SAP S/4HANA has a tremendous number of screens, and there is no way that SAP is finished with all of these screens at this time. Therefore, a large number of screens cannot yet be Fiori.

Claim 3: Guided Configuration?

I can’t tell you how many times I have heard about guided configuration. It should be remembered the IMG, which ships with the previous ERP version of SAP ERP was supposed to be guided setup as well, but it never was. S/4HANA may have a few helpful screens, but it won’t be guided configuration.

Claim 4: Reimagined Business Models?

S/4HANA brings ECC to HANA. It is a monumental task to do that simply. It’s very likely that business models will be “reimagined,” instead what companies should look for is if S/4HANA can be made to work.

Claim 5: Reimagined Business Processes?

Same thing, SAP is not offering new application functionality in S/4HANA. ERP on HANA is about an infrastructure and user interface upgrade. The business functionality is roughly the same as in ECC.

Claim 6: No More Batch — All Processes in Real Time?

S/4HANA is an ERP system, and that means it’s a transaction processing system. There are some processing that is performed in batch, such as MRP and closing the quarter for financial reconciliation, but this is a very simple type of processing. Most transactions in ERP are already processed immediately or in real-time.

Claim 7: Reimagined Business Decisions?

Hmmm…this one seems to propose massive differences on reporting for ERP on HANA. Clearly, S/4HANA will be much faster, however, the idea reporting would be so much better also depends upon the reporting application. HANA has several tools, such as HANA Live Browser, but this is not S/4HANA, and all of these tools are too new and unproven to make big statements about.

SAP shows slides with reducing in the time for processing. However, it overestimates the time that the transaction processing system takes. Yes, ERP on HANA will be better, but companies currently don’t have a real problem with closing. It’s a nice to have, but SAP is overemphasizing the benefits here.

Again this focuses on the two most processing-intensive processing within ERP which is financial closing, reporting, and MRP.

I had to say that having written books on MRP and tested MRP in many systems if an in-memory computing is being justified to run MRP faster, there is something wrong with that story. It may be that many people do not know that MRP is very simple and was designed to run on hardware from the 1970s. I quote from my book Repairing Your MRP System:

“Even though MRP is mathematically simple, it performs a number of repetitive calculations that prior to MRP had to be calculated manually, which was a very tedious task. Converting large volumes of sales orders into production orders and purchase orders was quite a feat when this capability was first developed independently in the early 1960’s at J. I. CASE and Stanley Tools. Yet quite a few companies continued using their old systems before industry converted over to MRP in the late 1970’s.”

Claim 8: TM and Ariba Run on HANA?

SAP implies in slides that TM and Ariba run on HANA. Yet, neither SAP TM nor Ariba runs on HANA. I can’t tell if that slide is trying to say that, or that S/4 just can integrate to other SAP applications. However, that is not a feature of S/4 as the same was true of ECC/Business All In One.

I assume that SAP would agree that it offered an integration solution before S/4 showed up on the scene. I will have a future article on what this means from the integration perspective. However, all new tables say all new mapping for the interfaces that do exist.

The slide also includes all the trendy terms, like Internet of Things and Big Data — and one I had never heard of before, called Omni-Channel. Omni-Channel simply means to offer a sales experience across multiple retail channels — such as online, offline, etc.. This has nothing to do with SAP as SAP has no product that does this — and these three things just tell the executive that “we do the new sexy.” It’s a subliminal messaging that “we get it.”

A big message about S/4HANA or ERP on HANA has been getting lean. So SAP has a few good slides on this that explain how this works. The first slide shows database aggregates and indices in the database.

Claim 9: Reducing the DB Footprint?

SAP has proposed that one of the benefits of columnar databases is that they require less aggregation and indices. The blue are the aggregates and indices that are still necessary with ERP on HANA.

This shows how SAP was able to shrink the size of the data that S/4HANA or ERP on HANA takes up. However, it also needs to be stressed that you will pay a lot more per GB when using anything on HANA, so these changes won’t translate to cost savings.

Claim 10: Data to Flow Through HANA Outside of ERP?

SAP proposes that data will now be pulled through HANA ERP and to areas outside of HANA ERP.

Why is this true? This is one of the most bizarre claims that I have seen from SAP. Is information currently pushed in R/3/ECC? But not in HANA ERP. This is the first time I have heard of this. If anyone has a perspective on this that may support some validity, please comment on this article.

Claim 11: S/4HANA in the Cloud Little Used?

There is a lot of talk about all the options available for S/4HANA or HANA ERP. However, S/4HANA in the cloud is quite expensive. And being able to put an ERP system in the cloud, or any other application for that matter should not be considered a big deal.

I happen to find most of the SAP’s material on the cloud more confusing than anything, and I have spent so much time on sales proposals where the topic of either on-premise or cloud is discussed, and it always seems to break toward on-premise. Also, except for purchased applications like SuccessFactors or Ariba, most of the SAP investments are still being sold on-premise.

Conclusion

Statements about HANA ERP have to analyzed because a lot of the information in these types of sales slides is fanciful. It is easy just to view a slide and let it pass you by, and I think I tended to do this for a while on S/4HANA and HANA. It’s another thing to evaluate if what is written makes sense. I have worked on HANA ERP sales pursuits, and I don’t like using these types of slides because they create expectations that are too high.

Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.

Search Our Other HANA Content

Brightwork Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

References

https://en.wikipedia.org/wiki/Multichannel_retailing

I cover MRP in the following book.

MRP Repair Book

 

MRP System

Repairing your MRP System

What is the State of MRP?

MRP is in a sorry state in many companies. The author routinely goes into companies where many of the important master data parameters are simply not populated. This was not supposed to be the way it is over 40 years into the introduction of MRP systems.

Getting Serious About MRP Improvement

Improving MRP means both looking to systematic ways to manage the values that MRP needs, regardless of the MRP system used. It can also suggest evaluating what system is being used for MRP and how much it is or is not enabling MRP to be efficiently used. Most consulting companies are interested in implementing MRP systems but have shown little interest in tuning MRP systems to work to meet their potential.re

The Most Common Procedure for Supply and Production Planning?

While there are many alternatives to MRP, MRP, along with its outbound sister method DRP, is still the most popular method of performing supply, production planning, and deployment planning. In the experience of the author, almost every company can benefit from an MRP “tune up.” Many of the techniques that the author uses on real projects are explained in this book.

Chapters

  • Chapter 1: Introduction
  • Chapter 2: The Opportunities to Improve MRP
  • Chapter 3: Where Supply Planning Fits Within the Supply Chain
  • Chapter 4: MRP Versus MRP II
  • Chapter 5: MRP Explained
  • Chapter 6: Net Requirements and Pegging in MRP
  • Chapter 7: Where MRP is Applicable
  • Chapter 8: Specific Steps for Improving MRP
  • Chapter 9: Conclusion
  • Appendix A: Calculating MRP