The Secret to Not Talking About The Cost of SAP HANA

Executive Summary

  • SAP HANA costs are extremely high, but there is a blackout on this topic as so many entities are aligned with SAP.
  • The problematic side of HANA from administration and licensing.
  • The TCO of HANA turns out to be so high.

Introduction to SAP HANA Costs

I was recently interacting with a person on LinkedIn, and I brought up the topic of SAP HANA’s costs. This person responded that they did not know why I was bringing up costs!

Wow, what a comment.

A Consistent Theme to Treat SAP HANA Costs as a Verboten Topic

This has been a consistent theme that I have noticed with regards to HANA, where lots of ink is given to discussing the benefits of HANA but so little time is spent discussing its costs. It is almost as if it is a taboo subject. On the other hand, HANA is often presented as reducing TCO. So if that is true, then obviously the first place to start is to figure out what it costs to buy and operate.

SAP HANA Costs

Here is the truth.

HANA is quite expensive. It is expensive in hardware, software as well as resources which bill at the top of the market and which are difficult to find. I have heard of big consulting companies charging roughly $350 per hour for them, and that adds up fast.

HANA hardware alone is typically going to come to $1 million.

SAP has provided some insight into these costs which are not part of the SAP price list (that is not kept private). They have provided total cost of ownership numbers, or TCOs for SaaS. However, these come to:

  • $2.7 million for 1TB for HANA Cloud Platform
  • $5.9 million for HANA Enterprise four years (these are 2014 numbers).

Now Amazon Web Services (AWS) which provides transparency regarding costs. They offer up to 2 TB of RAM per instance. This means that HANA on AWS can be priced, although the data volumes are necessary to have (AWS has Business All in One, Business One, Business Objects, among others).

SAP HANA’s Misleading Pricing

Now if we move to the applications that use HANA, a Finance purchase and implementation is going to be much more than an FI/CO implementation. I have found this myself, but this is the story I have repeatedly heard from sales reps that sell HANA.

Why SAP HANA’s Pricing is So Misleading

HANA’s price is at first blush straightforward. It is priced per GB and quite expensive. But the problem is SAP proposes ridiculous reductions in the database footprint that will not turn out to be correct (around a 98.5% reduction). Thus almost every HANA purchase is based upon false assumptions. Second, the associated costs make it tough to price entirely. This is particularly the case because it is so difficult for find use cases that can cover HANA’s high costs.

The expense of HANA is a primary reason why HANA has been so limited in its market acceptance.

Details of the Costs Associated with Moving to SAP HANA

SAP often presents HANA as sort of a “slam dunk” purchase.

According to SAP, HANA has a lower TCO than any other competition database.

  • It implements faster than any other competing database (even when a database is already installed).
  • It has more innovation than any different competing database.
  • It has better performance than any other database.
  • It has better performance in every dimension than any other competing database.

Is any of this true? 

While at Brightwork we hate bursting people’s bubbles, but the truth is quite a bit more complicated than what is commonly presented by SAP and SAP’s surrogates on HANA.

In this article, we will cover the complications of using HANA from the licensing and database administration.

How SAP HANA is Problematic from the Administration Side

SAP’s “new” ERP system called S/4HANA and which is not new, only runs on HANA. However, many large corporations have set Oracle or IBM DB as corporate DB standards, and this restriction of S/4 makes it difficult for companies to streamline administrations.

This is something that is entirely left of SAP’s marketing on HANA.

How SAP HANA is Problematic from the Licensing Side

And many companies have what we called unlimited Oracle license which allows them to use any number of Oracle DB for a predetermined price. Adding HANA will not reduce their DB cost but will, in fact, increases the overall DB costs. That is HANA becomes a “net increase” in license and therefore support cost.

Brightwork Research & Analysis recently performed the first independent study into HANA’s TCO. And this issue complicates the licensing estimations of HANA versus competitive databases.

And for those that purchased Oracle DB from SAP, they will have to continue to pay the same maintenance for Oracle DB throughout even if they want to move to HANA as long as there are any SAP systems still running on Oracle DB.

This translates into double the database maintenance fees during the period of migration which can take years if there are many large SAP systems running currently. However, the average we use is 1.25 years. That is we assume that HANA can be taken live in 1.25 years from when the HANA implementation begins.

The Overall Cost Implications

Long story short, this greatly increases the costs of moving to HANA. This also explains the multiple areas of costs and how HANA uniquely uses, which must be considered to come up with a representative TCO.

The Oracle database or IBM database that the customer is using today is considered sunk cost. Therefore if the customer is to move to HANA, they are the sunk costs that they have incurred previously and rebuying a new database all over again. Something that they could simply save just staying with the Oracle and IBM databases that they already have.

SAP HANA is the Highest Overhead Database

We won’t go into this much in this article, because we cover it in detail in our research A Study into SAP HANA’s TCO, but the amount of complexity that HANA exposes customers to is substantial. The reason for that overhead is predominantly the instability of HANA. This combines with a very high cost of resources as HANA resources charge at the top of the market. This is covered in part by the quotation from SAP Nation 2.0.

“Liz Herbert, an analyst at Forrester wrote about the diversity around the HANA product alone: “clients struggle to keep up with the rapidly evolving landscape of HANA — an ever growing list of solutions that includes HANA, HANA Cloud, HANA Enterprise Cloud, S/4HANA, Simple Finance and others.””

The TCO of SAP HANA

One could see something like the following representing the cost magnitude per cost area of using HANA:

  1. Costs of Hana DB ($$$$) $0 if staying put on existing anyDB.
  2. Costs of new hardware Infrastructure ($$$)
  3. Costs of reimplementation ($$$$$)
  4. Costs of retraining ($$$)
  5. Costs of higher downtime ($$$$$$)

We have estimated the TCO of HANA vis-a-vis competing databases in the article A Study into HANA’s TCO.

Conclusion

There is no point in putting off cost considerations and not discussing HANA costs. Yet, so many authors do this. They list the benefits of HANA without listing the costs.

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://www.amazon.com/SAP-Nation-2-0-empire-disarray-ebook/dp/B013F5BKJQ

Costs are of course quite important to IT decision making. I cover TCO in depth in the following book.

TCO Book

 

TCO3

Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
  • Understand why you need to look at TCO and not just ROI when making your purchasing decision.
  • Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
  • Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
  • Learn why ERP systems are not a significant investment, based on their TCO.
  • Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
  • Appreciate the importance and cost-effectiveness of a TCO audit.
  • Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
Chapters
  • Chapter 1:  Introduction
  • Chapter 2:  The Basics of TCO
  • Chapter 3:  The State of Enterprise TCO
  • Chapter 4:  ERP: The Multi-Billion Dollar TCO Analysis Failure
  • Chapter 5:  The TCO Method Used by Software Decisions
  • Chapter 6:  Using TCO for Better Decision Making

TCO Calculator

TCO Calculator

Brightwork Research & Analysis offers the following free TCO calculators. See by clicking the image below:

calculate_tco

https://www.oracle.com/us/corporate/license-management-services/unlimited-license-agreement-2613729.pdf

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 Nonesense

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.

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

What SAP Moving to the SAP HANA Cloud Means

Executive Summary

  • SAP has been trying to move HANA to the cloud.
  • We will explain the implications of this movement.

Introduction to the HANA Cloud

There is a lot of information of questionable accuracy given out on the topic of HANA. Some of the information is difficult to verify as one does not either have access to the HANA application in question. Or in other cases, one cannot test the HANA system. This is because of a lack of skills, bandwidth, etc.. However, other information is easy to observe as incorrect because it is simply not logical or conflicts with other information.

This article will describe this second type of information.

Conversation on HANA

I was recently interacting with someone on who was proposing HANA for a client. At one point I brought up the expense and complexity of HANA as factors to consider. The person I was speaking with had two very strange responses.

  • His first response was that I should not be focusing on cost because HANA was so much better than everything in the market.
  • His second response was that complexity should not be a focus because SAP is going to move to the cloud.

Eliminating the on Premises HANA Instance?

I don’t understand this second comment at all, and in fact, I find it quite disturbing, because while SAP talks up its SAP HANA Cloud plans, very few native SAP implementations are actually in the cloud – the exceptions being for products that were already cloud products as they were acquisitions like Success Factors.

If we look at Success Factors or Hybris 0r Concur or Ariba or ByDesign or BusinessOne — SAP applications that are sold in the cloud, HANA would not do much for these applications requests as they are naturally low in processing usage and memory overhead.

ByDesign no longer sees development. BusinessOne, often thought to be a native to SAP, was acquired a long time ago, as was Ariba (both of which would be a waste to put on HANA). Four of these (not Ariba or Hybris) are low priced products and are not the core of SAP in any shape or form.

And most of the HANA applications that are sold are still marketed as on-premise.

So given all of this, let us look at the logic here for a moment of not working about the extra complexity of HANA because SAP is moving to the cloud.

  • If SAP is eventually moving to the cloud, why is anyone buying on premises HANA servers? So they can be decommissioned within a few years?
  • The idea that you can buy applications in the cloud argues against buying on premises HANA solution now.

SAP HANA Cloud vs. HANA Battle for SAP Marketing Message Supremacy

There is an apparent disconnect between SAP’s twin strategies of pushing HANA combined with putting out the vision of the cloud. This is because SAP is both telling customers that the backend is critical to be emphasized while promoting the idea of moving to the cloud, where the backend disappears into the background — or more correctly becomes a service managed by the software vendor or some infrastructure partner like Amazon Web Services.

How Hosted Solutions Work

SaaS/cloud solution providers work fundamentally differently from on-premises vendors. The arrangements change, and the model is subscription based so that the upfront costs are far lower.

Let me provide an example. I use a web host for this website. Occasionally I run into a performance issue. I communicate this issue to my web hosting company, and then they respond that something is out of date or some new software can be installed on the server. I typically don’t know they are talking about, but I approve the change/update, etc… and the performance improves and…well that is the end of the story. The boring story I know. But for me, it is boring in the best way possible because I have no interest in worrying about the infrastructure behind my website. I know just about zero about the web hosting technologies and want to keep it that way.

In a managed environment like I just described, all the customer has to know is that they are unhappy with the performance, and they want a change to occur to improve the performance. This is the same way that SaaS/cloud vendors operate. They take care of the details, and the customer gets to focus on getting value out of the application.

The Productivity Advantage

SaaS/cloud vendors have a huge advantage because they control and tune the environments for all of their customers and the hardware that is used per customer is smaller because of this efficiency.

There are all types of productivity benefits that come from the labor specialization of having on group control application for so many customers, instead of the decentralized model, called on-premises, where the individuals in the client’s IT department maintain substantially a single implementation of many different applications.

This is not discussed much in enterprise software because of economists, by in large, tend not to study enterprise software.(1) However, here is the short version of the benefits of labor specialization, and its relationship to SaaS.

A Primary Ingredient to Productivity

Job specialization is a primary reason for improved productivity in all parts of the economy — from plumbers to web designers to hair stylists. The reason for this is that the more someone can focus on being good in one area, the higher their productivity and their quality.

The SaaS/cloud application model just allows for a greater degree of labor specialization. This is because a team that manages many customers for a single application are far more efficient than the same sized team managing multiple applications for a single client.

All of this is why training your customers on all the infrastructure of your application, how it is differentiated, how you need to have HANA is just a distraction when one moves to a SaaS/cloud application model. 

SAP HANA Cloud in the Background?

In the article titled Has SAP’s Relentless HANA Push Paid Off?, I proposed that HANA should simply become an inherent property of the application, and it is difficult to see why users, functional consultants, and VPs of buying firms should need to go through the litany of details on infrastructure. This is how Tableau and Teradata market their applications (with the support available for discussion, but as a background topic), which I covered in this in the article How SAP HANA vs. Teradata and Tableau Market Backend Technology.

Placing the infrastructure ahead of the application, particularly for a company that is focused on selling applications is…well I think quite strange, and really can’t be successful.

SAP HANA Cloud Costs?

So let us discuss the costs of moving to the SAP HANA Cloud. We can discuss all types of options, but once the costs are included, things become much more clear as to what is feasible.

SAP has declared the total cost of ownership (TCO) of cloud costs, which are TCOs for HANA in the cloud. BlueFin Solutions provided estimates which I think are directly from SAP (through John Appleby who writes extensively on HANA).

The TCO for four years are the following:

  • $1 million for 1TB HANA Cloud Base
  • $2.7 million for 1TB for HANA Cloud Platform
  • $4.8 million for HANA Platform
  • $5.9 million for 1TB for HANA Enterprise.

So, it turns out SAP HANA Cloud is quite expensive. I have not compared these costs to the TCO for on-premises HANA because I don’t have the numbers handy.

Moving to the Cloud

SAP wants to move to the cloud, but there are two different areas of SAP that must be considered when analyzing this statement:

  1. The native SAP applications
  2. The acquired cloud-based applications

SAP is not moving HANA customers to the cloud, in fact, SAP is not moving any significant number of clients to HANA in the cloud or on-premises.

SAP may be in for a shock, but cloud applications don’t sell for the same price as on premises, and the majority of SAP’s applications have not been subject to SaaS competition.

This is touched on in this quotation by Vinnie Mirchandani in the book SAP Nation:

“When you compare how nicely IT costs via SaaS application…have dropped in the last few years, you have to ask why those in the SAP economy have not followed that trend.”

I have an answer to Vinnie’s question, or at least I think I do. It is because SAP is protected from marketplace pressures for the majority of the applications that it sells. However, if SAP continues to acquire SaaS applications, and SaaS makes up more of the portfolio, this will change.

Conclusion

I hope this article has successfully made the case that it is not so simple to say that.

“SAP wants to move to the cloud,”

..when we are referring to the native SAP applications. In many cases moving to the cloud is expensive for clients when HANA is involved.

When we are talking about applications that were already in the cloud when SAP purchased them, the story is entirely different. But the two stories cannot be commingled because they are very different situations. What I consider to be “real SAP” are the internally developed applications. I am not sure what to make of these newly acquired cloud-based applications yet, and SAP’s actions seem to demonstrate that they often don’t either.

However, let us circle back to the main point, and that is that the complexity of SAP HANA is still very much an issue that must be considered and evaluated independently for each application because while many options are often discussed during sales pursuits, most HANA is sold as on-premises.

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

(1) Economists are very focused on financial features of the economy, but few of them investigate manufacturing history, technology, etc.. This is why, in my view, so many critical areas go without economic analysis.

Between Complex Licenses and the Cloud, Microsoft, Oracle, and SAP Have Lots of Ways to Hike up Prices. Here is How to Fight Back. Infor would. Robert Scheier, Jan 13, 2014

*https://www.amazon.com/SAP-Nation-runaway-software-economy-ebook/dp/B00Q5MW21C

*https://blogs.saphana.com/2014/03/06/a-no-brainer-the-tco-of-hana-cloud-platform-vs-on-premise/

https://www.infoworld.com/article/2608228/techology-business/update–sap-sees-cloud-revenue-soar–software-sales-drop-in-q2.htmlhttps://www.infoworld.com/article/2608228/techology-business/update–sap-sees-cloud-revenue-soar–software-sales-drop-in-q2.html

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 the HANA Cloud Platform Designed for HANA Washing?

Executive Summary

  • What is HANA Washing?
  • What is HANA Cloud Platform?
  • How Does SAP Use HANA Cloud Platform to Perform HANA Washing?
  • Our Work on HANA

Introduction

In this article, I wanted to cover a major strategy that seems to come from SAP marketing. This is what lead the HANA Cloud Platform to have the word “HANA” in the name and how SAP has been using this development environment to HANA washing its other applications.

What is HANA Washing?

The industry term for presenting one’s revenues as more cloud-based than they are is called “cloud washing.” This is something that SAP does quite frequently. In a previous article, I explained how the HCP is explicitly designed for cloud washing. However, HCP is also intended for HANA washing. HANA washing is not a commonly used term, but it seems like a natural extension of cloud washing. So I am introducing it in this article and hope it catches on. This is because SAP is constantly trying to make its installations seem more “HANA” than they are. HCP is a big part of this HANA washing. In fact, its naming seems specifically designed for both cloud washing and HANA washing.

What is HANA Cloud Platform?

Some people incorrectly state that HANA is a both a database/development environment and application. This is not correct, and one of the reasons for this confusion is because HANA was, for marketing purposes, added to the name of SAP’s connective development environment.

  • HANA is a database
  • HCP is a development environment
  • Neither is an application
  • Neither is it a platform

The HANA Cloud Platform is a development environment, but one which is tied to SAP’s hosting and the use of SAP HANA Infrastructure Services (HIS). HIS is something else, so let us tackle one topic at a time. This article is about the HCP, not the HIS. If we follow SAP’s logic, we will only smush everything together and say everything is a database or a platform or a PaaS or an IaaS depending upon the flexible needs of SAP marketing and sales. This article is about the HCP, not the HIS.

Now a development environment allows you to code to create custom programs. Development environment needs to connect to things like databases. There are many development environments out there, and this is not something that SAP has historically offered.

And this tethering of the HCP to the HIS is a problem because it restricts what you can do with the development environment. The problem with using a development environment from SAP is that SAP wants to use the HCP to redirect the customer to make more SAP purchases and to cut down the options for the developer and the customer overall. SAP seeks to tether the application to the database, and then the development environment to the application provider. This constant tethering is designed to cut down the freedom of their customers and is textbook account control.

A development environment allows you to code to create custom programs. Development environment needs to connect to things like databases. There are many development environments out there, and this is not something that SAP has historically offered.

How Does SAP Use HANA Cloud Platform to Perform HANA Washing?

  1. There is absolutely no reason to put the term “HANA” in the HCP.
  2. HCP has absolutely nothing to do with HANA. HANA is a database, and HCP is a development environment that can connect to HANA, or 12c or any database for that manner.

The reason for SAP to call place HANA in the product name is very simply to confuse people as to whether or not HANA is deployed. This is an example of merely a trick of HANA washing by SAP. Now for some time into the future, HCP will be used as the term to confuse customers and Wall Street as to how much HANA is being used. SAP routinely states that “with the HANA Cloud Platform companies can” fill in the blank. SAP knows that people will read the words HANA in HCP and mistakenly think that the HCP has something to do with HANA. But their documentation and statements about the HCP go on to further confuse the issue. Here is a perfect example:

“With flexible subscription models and optional services for apps, database, and infrastructure, it provides instant access to the full power of SAP HANA.”

No, that is not true. One can access any of these things with any development environment. That is you can use the HCP or use another development environment and access all the same things. The “full power of SAP HANA” (which is no better and seems to perform worse than Oracle 12c) is available from any development environment that one decides to connect to SAP HANA.

Purposeful Confusion

This confusion will persist for quite some time. I am still speaking with people who are confusing S/4HANA with SAP HANA, which is easy to do because of SAP’s confusing naming.

Secondly, the HANA Cloud Platform is free, so there is no traceability possible as to how much SAP HANA is being used. When SAP HANA started performing very poorly in sales, SAP stopped breaking out SAP HANA as a revenue item under McDermott’s logic that “everything SAP does now connect to HANA.”

Conclusion

  • SAP’s naming of the HANA Cloud Platform and their discussion around HCP is deliberate and deceptive.
  • HANA Cloud Platform is an example of both cloud washing and HANA washing — all in one product.
  • Almost no one uses the HANA Cloud Platform, so SAP can say whatever they want to about it. They propose 20,000 “developers” using it, but I know several people who created and account and logged in and aren’t developing anything in it. Most of SAP’s numerical claims like the fact it has 3700 S/4 “customers” are always inflated.
  • The HANA Cloud Platform will be used in SAP’s marketing offensives to mislead companies. Both regarding how much SAP installations are cloud based and how much HANA is deployed.
  • If the HANA Cloud Platform never rises above even a tiny fraction of users, this will not stop SAP from telling customers and Wall Street that it is revolutionizing projects. And even better, its growth cannot be tracked because it is free and will not have any revenues to report. I see the HANA Cloud PlatformHCP being saddled up by SAP marketing to be ridden for a long time.

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://www.amazon.com/SAP-Nation-runaway-software-economy-ebook/dp/B00Q5MW21C

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

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 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.

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

When Articles Exaggerate SAP S/4HANA Benefits

Executive Summary

  • Most articles on S/4HANA exaggerate the benefits customers can expect to receive because of financial biases.
  • We review common exaggerated claims about S/4HANA to determine which are true.

Introduction

Recently I spent some time analyzing some articles on SAP S/4HANA. What I have noticed that SAP S/4HANA articles tend to have a high “aspirational content” ratio, and a significant number of them seem to propose benefits that are supposed to be uncritically accepted by the reader.

The Aspiration Quotient to SAP S/4HANA

In the article …….. I covered the issues related to the accuracy of some of the SAP S/4HANA marketing documentation.

For example, one of the common problems that I find is that while the benefits are listed, the costs are not. However, with something like HANA, which dramatically changes a company’s approach to SAP and has all types of associated extra costs, it makes little sense to only look at the benefits side of the equation. However, the benefits that are attributed to HANA, at least by many authors, are another problem.

Focusing on Declared SAP S/4HANA Benefits

To illuminate this point, I will provide a list of SAP S/4HANA benefits. This is a direct quotation from an article produced by a senior member of one of the major SAP consulting companies.

After reviewing this list, let us perform a little test to see how many of the items relate to SAP S/4HANA.

“Some focus on the details of the technology. But why should business leaders care? Those who have recognized that in-memory computing allows them to do things differently have realized these benefits:

  1. Ease of integrating data from multiple sources

  2. Increased speed to deployment and speed to value

  3. Flexibility to meet changing business needs

  4. Enhanced mobile analytics

  5. The power to turn data into action”

Now let us go through each item:

Integration Benefit of SAP S/4HANA?

I don’t recall in-memory computing being referenced before as improving integration. Readers can check the Wikipedia entry on In-Memory Computing and In-Memory Database, and the word integration does not appear a single time. So many HANA articles morph the benefits from area to another area. The reason that HANA does not provide any extra ease of integrating data from multiple sources as that it is not an ETL (extraction, transformation, and load) tool. SAP’s ETL tool is called SAP PI. HANA is the database.

Faster to Deploy?

In most cases, SAP HANA will not provide an “increased speed to deployment and value.” Quite the contrary, it takes longer to implement because it is more complex and less tested than previous SAP products. Aside from the speed of implementation question, it also means higher risk. There may be a higher payoff, but the risk and project duration should account for the relative newness of SAP HANA. The one case where this may not be the case is with a BI/BW implementation. When BW is implemented on top of SAP HANA, it means time saved through less time spent configuring the Data Workbench. However, most SAP applications would not receive this implementation benefit. So this quotation should be changed to “Maybe faster to deploy under certain circumstances.” 

Flexibility to Meet Changing Business Needs?

SAP HANA will not provide flexibility to meet changing business needs, unless that changing business need is processing something faster. SAP HANA is a database, its not application functionality. Application functionality is where addressing changing business needs is typically met. This issue has arisen from SAP itself when it tells clients that things like SAP HANA will replace APO, which again is like saying Oracle 11i will replace APO or replace CRM. It is both incorrect and confusing to say that a database replaces an application.

SAP HANA for Mobility?

You seriously don’t need SAP HANA for mobile analytics; check what the emphasis point are in mobility from any of the other analytics vendors. It’s hard to see why this would be claimed as a benefit for mobile computing. This is because the bottleneck on mobile computing has far more to do with the bandwidth than the database.  For instance, Tableau has snapshots for when you are not connected to the Internet.

Convert Data Into Action?

This is true, but it seems like someone’s catchphrase or something to be put on a bumper sticker. So it is not false, it is simply irrelevant as a differentiator. Any application converts data into action (or technically the potential for action), and if we think about it, data has been translated into action by devices since before computers were invented,  as the counting boards (the earliest known counting device) used by the Babylonians also had the ability to convert data into action.

One Example?

The one example from the list of something that sort of can be considered to apply to HANA can also apply to counting boards…and that can’t be a good thing.

Conclusion

These types of articles are all too common, and the information in them is unreliable and gives the reader nothing in return for their attention. What is possibly most interesting is that many of the supposed improvements that are listed in these types of articles are not improvements that can be traced back to HANA.

If a prospect reaches out to the member of this consulting company, does the member continue to propose that HANA with smooth integration and deploy faster, etc.? That would be a problem.

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.

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