- Despite making the code of S/4HANA 93% identical to ECC, SAP attorneys have deemed S/4 the “logical successor” to ECC instead of the “legal successor.” This means SAP ECC customers paying for support contracts with free software updates are unable to upgrade from ECC to S/4 without purchasing the software.
- Find out about the issues with HANA and S/4HANA pricing before you negotiate with SAP.
In this article, we will review the implications for HANA pricing and S/4HANA pricing.
What is SAP’s Integrated Strategy for HANA and S/4HANA and How it Purges Oracle?
Because of SAP’s confusing naming it is still necessary to differentiate between S/4HANA and HANA.
So HANA is SAP’s first serious foray into databases. S/4HANA is the ERP system. S/4HANA only works with HANA, breaking with the previous tradition of SAP applications being open to different database vendors.
SAP has had a few other databases that it owned through the years, like SAP DP or Max DB, but these were very lightly sold. SAP purchased Sybase several years ago. However it has not been able to sell many Sybase databases, and the Sybase acquisition has been a washout, with the Sybase product seen as quite dated. SAP doing very little to keep the Sybase database line up to date.
SAP has very strongly based its strategy around HANA, but the HANA pricing is quite unusual.
SAP has an integrated strategy regarding HANA and S/4 HANA which is related to removing the Oracle DB from accounts. Brightwork Research & Analysis receives no income from any vendor outside of competitive intelligence work. And we have no conflicts regarding Oracle or SAP and do not care if either win or lose business. But on its merits, SAP has put forward no reasonable technology reason for any of the other major database vendors to be excluded from supporting S/4HANA.
SAP’s Refusal to Certify Any DB but HANA
SAP has simply refused to certify any other database for use with S/4. SAP has made many statements regarding HANA’s “unique” performance characteristics, I have carefully evaluated each of these statements and found them to be without merit.
Secondly, SAP refuses to release transaction processing benchmarks (that due to HANA’s 100% column-oriented design, likely are not very good). Meanwhile, SAP is losing in benchmarking tests to other database vendors. However, through both its own and its many partners, SAP has a very effective sales force and willing army of compliant consulting partners. These partners effectively to prevent this information from being widely known or repeated.
Understanding SAP’s Strategy with S/4HANA and HANA Pricing
Understanding SAP’s strategy with S/4 and HANA is critical to understanding how SAP prices these products. SAP’s strategy is to use its dominant ERP system to dictate the database that is used to run this ERP system. In addition to proposed performance benefits over other databases, SAP has used the argument that as they are putting stored procedures into HANA (which is code pushdown in order to make it seem as if something novel is going on). This is, ironically, the same argument used by Oracle to prevent companies that could migrate away from Oracle to lower cost open source alternatives.
Interestingly, there are quite a few questions as to whether stored procedures are actually a good idea or should I say, worth the trade-off and the overhead. We are currently having an application developed and want no stored procedures so we can have the flexibility of choosing the database at a later date. It depends upon the application of course, but stored procedures are an established tactic by software vendors to reduce portability. One thing that is undisputed, the more stored procedures or as SAP calls it, “code pushdown” which is used, the less flexibility the customer has in moving away from the database in the future to other options. This is why Oracle and SAP are so insistent on putting as much mode as possible into the DB.
Customer Input Not Required
SAP never asked its customers if they were interested in the very large trade-off of losing database portability by placing stored procedures. Furthermore, there is also nothing to stop SAP from removing those stored procedures and putting them back into the application layer, which is something we predict SAP will do in the future. That is after all the development approach they followed to good effect since SAP began as a company.
What SAP is doing, although it does not seem to realize it fully, is sacrificing S/4 adoption to build its database business. This strategy has been unsuccessful in moving many companies to S/4.
Getting Real with the S/4HANA Implementation Numbers
Currently, we estimate less than 100 S/4 implementations in some state between kicked off and live, and almost all of these are for a single module – S/4 Finance. (This article was updated as of August 2018 and the number currently is 1500 reported live S/4 implementations with the number truly live far lower than that. S/4’s live case studies are filled with companies that are not actually live as is covered in the Brightwork Study on S/4HANA Implementations)
SAP will not continue, as they have, to sacrifice S/4 adoption forever. Something else SAP has been doing is sacrificing revenues on S/4 to sell HANA. This topic gets a bit convoluted because there is a strong argument that S/4 should be free to current customers who are current on their support. Many customers are paying 22% or more on support contracts and were supposed to receive free updates for all the applications they have purchased. This certainly includes ECC.
How SAP Changed the Rules and Put Itself in the Position to Charge Existing Customers for an Upgrade
SAP changed the game, and declared that S/4 was a “logical successor” to ECC, but not a “legal successor.”
SAP’s attorneys had to twist themselves into a pretzel to come up with the phrase that S/4HANA is the “logical successor” but not the “legal successor” to ECC. SAP covered up the deception by stating that S/4HANA was so different from ECC that it was a new product.
But an analysis by Paul Coetser or through a related party found that S/4HANA was somewhere around 93% code identical to ECC.
Why is S/4HANA (According to SAP) Not the Legal Successor to ECC?
The real reason S/4HANA is not the legal successor to ECC?
SAP wanted to charge for S/4HANA, hence giving them the ability to double bill its customers. This is just another change in the rules which violated the support agreement that states if the customer keeps up with their maintenance, they are owed all upgrades for the products you purchased.
This phrasing meant that ECC was from a support perspective sunsetted. With support extending to 2025 and S/4 was positioned as entirely new applications that existing customers would have to pay for.
All of this translates into the price for SAP increasing for customers.
Is S/4HANA a Good Value for Existing ECC Customers They Get it For Free?
How many companies that purchased ECC five years ago thought that after five years of paying more than 22% in annual support that they would also have to repurchase their ERP license, or stay on the last version of ECC?
- Given this background, the idea that SAP is offering, as it has, promotions on S/4 for “free” is misleading because it makes little sense for current support customers to pay anything for S/4.
- After all, customers did not ask SAP to introduce S/4. SAP made this decision based on their internal incentives which branch into an overall strategy to remove Oracle from their customers.
Nevertheless, SAP has repeatedly offered S/4 for “free.” but has refused to discount HANA (except for the runtime license, which is not a real license). Therefore, SAP can “recoup” the costs of “free” S/4, by getting customers to pay for and get onto HANA.
Getting customers on HANA is a huge win for SAP because as will be described in this paper very few companies will be able to run for very long on the amount of HANA license that they initially purchase. And this leads directly into the question of database sizing and its importance in HANA pricing, which we will get into now.
The Importance of Database Sizing in HANA Pricing
Of primary importance in HANA pricing is that before any pricing numbers begin to be applied, database sizing must be performed. This is because HANA is sold per GB. This is quite an unusual pricing for a database.
What this means is the HANA pricing is based on the size or footprint of the SAP database. And SAP has released information that will cause customers to substantially undersize the footprint so that SAP can get their foot in the door with HANA. Customers routinely have to go back to SAP and request more GB, which blows their budget.
Without an accurate footprint estimate, HANA cannot be priced correctly. However, all the sources of information on sizing the footprint either come from SAP or come from a SAP partner. Companies that are partners with SAP lose control over the information that they provide to customers. They must not provide information that contradicts the SAP information (read our analysis of the SAP partnership agreement). This of course, includes companies that are the largest advisors in the space (your Deloittes, Accenture, etc..) to the smallest.
How do we know this?
SAP partners contact me and tell me stories of how SAP threatens to take their partnership away if they don’t follow the SAP rules. No SAP partner can provide accurate information on SAP pricing, SAP HANA pricing or any other SAP pricing for that matter.
Therefore, companies are boxed out of accessing accurate information on this topic. Brightwork Research and Analysis is one of the few entities which will publish or provide consulting on this topic. Unsurprisingly, we have no partnership with SAP, and unlike someone like Gartner or Forrester, we take no money from SAP (or any other vendor for anything else than competitive intelligence).
When a Database is Sold
In most cases when a database is sold, the database vendor sees the sizing as more of a customer determined item. Companies have database administration groups that have their own views as to how frequently and how extensively they want to perform archiving. How much they want to rely upon compression, etc.. However, because of SAP’s pricing of HANA, SAP is now front and center on the topic of the database size, and has become quite prescriptive of how they think database administration departments should be managing their databases. Furthermore, it is now clear that HANA is just a first step for SAP sales in penetrating the database layer. The first salvo was to lead with HANA. The argument being that no other database can keep up with the performance provided by HANA.
But SAP not only intends to get the application database business from its customers which its applications reside upon but also is positioning other database products, such as those it acquired from Sybase in its accounts as well. Sybase has been unsuccessful against Oracle, but this time Sybase’s products are commingled with SAP’s sales force and positioning.
All SAP Applications Work Better with HANA?
SAP’s marketing positioning is that these databases work much better with HANA than with any other database. So it is a two-step process.
- The first step is convincing clients to use HANA. SAP is doing this with a combination of selling the purported performance benefits of HANA, along with blocking all other vendors from applications like S/4 so that they are the monopoly database provider for their ERP system.
- The second step is marketing the compatibility aspects of HANA with all other database products. That is HANA is simply the nose of the camel into the tent. There is an ancient Arabic proverb about what happens after you let the nose of a camel into the tent. At first, it may seem innocuous, but bad things follow if you don’t put a stop to it. Bedouin know you do not allow the camel’s head into the tent. If you let it in, pretty soon your tent is lying on its side, and your belongings are strewn across the desert.
Archiving “Down” HANA’s Footprint?
The chart that SAP likes to show is with almost all data archived on to a separate database. SAP is pushing customers to use Sybase IQ to archive old data from ERP. Sybase IQ, a column based database like HANA which SAP picked up from its Sybase acquisition, which they have had a tough time leveraging (interestingly, HANA, while being column oriented like Sybase IQ is not based upon Sybase IQ, but has a different design heritage.
However, the problem with this is that this is now different databases with different skill sets that SAP is proposing that its customers acquire.
The undersizing of HANA is both obvious from the logic that SAP presents on HANA and from the real world feedback where multiple SAP customers that bought into SAP’s undersized model are now coming back to purchase more HANA license so that they can cover the database size. The degree to which HANA is undersized at the point of initial purchase is becoming obvious as come customers come back to SAP within six months to acquire more HANA GB. As I have written previously, HANA is very expensive per GB.
The Deliberate Undersizing
As a synopsis, there are four distinct areas where SAP relies upon to drive footprint reduction, and of these four areas, two are very significantly overestimated by SAP. To see how these areas are overestimated, please see the paper that has been referenced.
Of all the areas where the footprint can be reduced, it is the indexes where most the space-saving occur. This is normally between 33% and 25% of the database. Archival can reduce the size of a footprint also, but SAP makes it sound like customers aren’t already archiving, and there is nothing in HANA that makes archival more effective than in any other database.
Secondly, archival is not free.
What Archival Entails
Archival means increased costs in labor to perform the archiving. Therefore what SAP is saying is that while HANA will do nothing for archival, if the company desires, they can spend more resources on archival. This will suit SAP, as SAP can make the initial purchase price lower, increasing the potential demand for HANA. Therefore, according to SAP, customers should perform more archival so that SAP can sell more HANA. However, what happens if the customer is not able to follow through on the level of archival that they initially commit to?
Well, then the database will grow, and SAP will have its hand out for more HANA license(s). And the problem with this is that while SAP is making greatly exaggerated proposals regarding footprint reduction, if they are wrong, there is nothing that the customer can do about it, except buy more HANA license.
After the initial HANA purchase is made, and once the system begins being used for production (at which point the database will grow), then the company has narrowed its options. And of course, software vendors love narrowing the options of their customers.
That is called lock-in.
You put the customer in a position where they have to buy more from you, or they can’t operate properly.
SAP’s Un-natural Focus on Footprint Reduction
Getting back to the point about total realistic footprint reduction. In our estimate, roughly another 20% reduction from all other sources is attainable, although not without cost.
This enormous focus on footprint reduction is so important because unlike most other database vendors, SAP prices HANA per GB. No other vendor has such a focus on database size, because no other vendor that competes in this space prices their database per GB. Therefore, the maximum ordinarily attainable footprint reduction should be roughly 50%. This is the number that we have applied to our cost calculations in this paper. Some customers will reduce their footprint a bit more, some a bit less, but we believe 50% is a reasonable assumption to use for footprint compression.
HANA Pricing with Realistic Assumptions
A mid-size ERP instance is about 2-4TB depending on modules implemented, years of operations, archiving, and self-developed tables. If we assume a 50% reduction in the database footprint due to the use of HANA, this becomes about 1-2 TB. As we stated earlier, HANA is priced per GB. 1 TB is 1000 GB. So a typical mid-sized ERP instance on HANA would be between 1000 GB to 2000 GB. SAP also has a well known non-discount policy on HANA, and this makes the pricing easier.
The range of pricing for a 1000 to 2000 GB instance of HANA would be a one time cost of roughly $6.2 million. At 20% per year, this will add a support charge of $1.24 million. Then hiring HANA skills into the database administration function will have to be added to that figure. And HANA skills are still very difficult to find (This article was updated in August 2018, and this statement is still true. HANA has so many components that there are multiple HANA skill sets necessary).
Important Facts Related to HANA Pricing
- This is quite expensive for a database and SAP knows this.
- However, SAP is doing everything it can to make the initial purchase price of HANA low to obscure its actual cost. Interestingly, in the only well known published study on the TCO of HANA that has been published by Forrester, the runtime license was used to price HANA. HANA’s runtime license is another bit of trickery. It is designed to get customers to be able to test HANA at a very reduced price of 8% of the cost of “full” HANA. We created our own proportional TCO calculation of HANA which you can read at A Study into SAP HANA’s TCO.
Customer sometimes think that this is the actual price of HANA. SAP knows how to time software audits so that they can extract the most revenue from accounts.
- The HANA runtime license is a bear trap designed to lull companies into thinking the price of HANA is far lower than it is.
- And unsurprisingly, as SAP paid for the Forrester study on HANA TCO, Forrester used the runtime license to reduce the TCO of HANA. Forrester does note that it used the runtime license, but somehow turned it around so that the use of what is obviously a temporary license was considered more, not less accurate than using the standard HANA pricing.
Once HANA has been priced, the next step is to price S/4.
S/4 is more straightforward to price in one respect as it is not based on a database sizing effort. The confusing aspect of S/4 is that it has routinely been offered for free, and the vast majority of S/4 “customers” did not pay anything for S/4. S/4 is a gateway application to HANA, which is the real motivation for SAP. SAP wants desperately to get into the database layer. This is not only because HANA is so expensive, but also because SAP sees HANA as a Trojan Horse to eventually take over the database layer and kick the current database vendor, or database vendors out of their customers.
- Therefore the pricing of S/4 could be nothing or can be something depending on the promotion that is run at the time of purchase.
Secondly, there is no policy against discounting S/4, and we have observed S/4 being quite heavily discounted. SAP has been offering S/4 at a very low price to consulting companies so they can install S/4. These consulting companies don’t care about using S/4 for their internal operations, but they want to the consulting exposure to S/4 so they can advertise this fact and get S/4 business. This is precisely what Infosys did, and it is quite unlikely that Infosys paid very much at all for S/4.
How SAP HANA is Now Being Discounted (Maybe)
One of the constants with SAP’s policies is change. In this article, we will cover SAP’s change in pricing policy regarding HANA pricing.
At One Time the Only Non-Discounted Product on SAP’s Price List
For years after HANA was first introduced it was the only product SAP offered that was not to be discounted by any account executive. However, recently, this policy was changed so that HANA could be discounted. And the discounts seem actually to be high. As high as 65% of the list price. Interestingly this was predicted by UpperEdge in an article in January 2014.
“SAP has been very aggressive in pushing and hyping the growth attributed to HANA on all of its prior earnings calls. UpperEdge has consistently observed interest from our client base in HANA but such interest has been limited to specific use cases and pilots as opposed to broad, wide spread adoption. In addition, now that HANA has had enough soak time in various customers for various use cases, feedback is now available regarding the benefits achieved relative to the cost. From what we are hearing, customers like the technology but have concerns regarding the cost. This type of feedback will likely spread within the user groups prompting SAP customers to seriously consider comparable, lower cost solutions. Could this be enough to finally drive SAP to discount HANA? We believe it is something SAP is seriously considering.”
However, the discounting that is now occurring with HANA is not the end of the issue. HANA has more indirect access liability than any other database, because SAP brings indirect access claims against its customers, while no other software vendor (outside of an attempt by Software AG to copy SAP) does. Therefore, the price on HANA can be discounted until the customer is found to be out of compliance. And SAP can use indirect access to charge more for HANA after it is installed, and after the company can do anything about it.
Therefore, what is the actual value of the HANA discount?
How Does SAP HANA’s Value Compare?
We have performed the most and the most extensive analysis on HANA of any independent entity that publishes on HANA. And we have concluded that HANA, with or without discounting, is one of the weakest values available in the database market. It lacks the performance advantage that it says it has, as is covered in the article What is the Actual SAP HANA Performance?, is unable to compete with its major competitor in benchmarking or in real life performance as is covered in Which is Faster, HANA or Oracle 12c?, has issues when paired with S/4HANA as HANA is primarily an analytics database that is not well designed for an ERP system.
HANA Pricing and Applications
On the topic of HANA pricing, HANA is ready to use, but only for a limited number of applications. The most common of these is the BW. However, no matter what application HANA is used for, SAP’s footprint reduction numbers are not reliable guides and have a very high likelihood of causing the customer to go back and have to buy more HANA license than was originally expected.
We have proposed a much more realistic footprint reduction value, and unlike SAP, we do not have a financial bias to make the database footprint seem as small as possible. What should be remembered is that HANA is not unique database technology, and the reasonably achievable database footprint reduction are known throughout the industry. SAP’s estimations are completely discordant with other estimates from other database vendors that have the same technology as SAP uses in HANA. The major difference is that SAP is the only database vendor that charges per GB for their database.
See our The S/4HANA Implementation Study for updated details on actual S/4HANA implementations.
HANA’s Lower TCO?
The following is a quote from Hasso Plattner.
“On the other hand, net new customers, who are attracted by the technical superiority of the product and the lower cost of ownership, but they might not be members of the user groups yet.”
Lets review each of Hasso Plattner’s claims.
New Customers Are Attracted to S/4HANA
S/4HANA has sold very poorly and is primarily either given away to companies, so it ‘s hard to see what Hasso is referring to here, as S/4HANA is known to have extremely few go-lives. S/4HANA has been a great disappointment commercially. So a better explanation might be why companies are not attracted to S/4HANA.
Does S/4 HANA Have a Lower TCO than ECC?
Does SAP have independent studies that back up the lower TCO of S/4HANA? Also, how many samples does SAP have to back up this lower TCO claim? It’s interesting that I repeatedly see software vendors claim low TCO, but when I review the scant evidence they present — if they offer any, I find all types of costs left out.
That is why explaining the method of the TCO performed is so important. As of this time I have seen no TCO estimations from SAP on S/4HANA. Secondly, I see many problems with this claim. These are known higher expenses for S/4HANA.
- More expensive hardware
- More expensive resources
- Far longer implementation
- Far lower chance of going live
- Much higher bugs in the software and associated costs with new and untested software.
SAP’s General TCO
I calculated that SAP has the highest cost of ownership in each of the software categories that are covered at TCO calculators. (all at this link). There are very simple reasons for this which range from license costs to implementation costs to maintenance costs all being higher than average.
Now, this says nothing about value, but merely about costs. So this article by Hasso is already getting off to a bad start because Hasso has claimed two fundamental virtues that I know to be untrue.
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 pricing templates provided on HANA are not reliable and will not result in a correct SAP HANA cost or SAP HANA price. They will result in the database being undersized. The customer will then need to go back to SAP to purchase more HANA GB licenses. However, if the customer had known the actual cost when they purchase the initial HANA licenses, it very may well have changed their initial purchase decision.
Secondly, the price per GB declines as the size of the database increases. We do not have the information on whether SAP charges an incremental cost for the new HANA licenses or if the customer starts off buying the new HANA GB at “zero.”
However, once data has been migrated and the HANA database has been brought up, there is little in the way of options to move away at that point. The logical decision will be to purchase more incremental GB licenses of HANA. This is only one of the compound features around HANA that most customers have no idea about when the sign the contract.
In our estimate, many IT directors will be hiding the actual results of HANA purchases for years to come.
Who Sanctioned Deliberate Undersizing?
It should also be recognized that this is sanctioned from the very top of SAP. One of the primary proponents of the faulty and undersized footprint estimation of the SAP database has been none other than Hasso Plattner.
- HANA and S/4 (HANA) are tricky items to price. S/4 HANA has frequently been offered on promotion for free.
- However, S/4 HANA is not actually fully released as a suite. SAP is adding functionality on what is called a “birthing schedule, ” but by the normal standard applied to applications, S/4 HANA Enterprise Management (EM) (that is the entire suite) is simply not released. SAP was more honest about this in the past, but it has now changed its messaging to pretend that S/4 HANA EM is released. SAP has an on-premises version called 1151 and a cloud version called 1603.
Furthermore, notice the unusual numbering conventions that are not typical of SAP products.
HANA Pricing and Discounting and S/4HANA EM
Customers should consider HANA discounting to continue into the future. HANA was significantly overpriced, to begin with, and the reality of HANA is nowhere close to the marketing hype. However, HANA also comes with indirect access issues, and due to the lower price, is now being pitched to do things by SAP that it is not the right database type to do.
Therefore, even at a reduced price, there is still an open question regarding value and appropriateness of applications of HANA.
We have been in these systems, and they are not complete. After declaring that S/4 HANA EM is complete, in the next breath that state that every three months S/4 HANA EM will be “more complete,” which is a bit of misdirection on the topic. S/4 HANA EM is not complete, and this truth should be used by customers to argue for either a steep discount on S/4 HANA EM or for the customer to simply wait until the promotion resurfaces. There is very little reason to implement S/4 HANA currently, and it does, in fact, make the most sense to simply wait.
How Consulting Firms Coordinate with SAP to Mislead Clients
SAP consulting partners have been hiding everything covered in this article from their clients. Their objective is to cooperate with SAP to extract as much out of the account as possible. It is bizarre that SAP customers look for advice from companies like Deloitte or Infosys that is entirely driven by aggressive sales quotas. Any S/4HANA or HANA purchase and implementation will result in significant amounts of income for the consulting firms. The long-term relationship between SAP and its consulting ecosystem is that SAP proposes what is often false information, and the consulting companies go about agreeing with SAP. We analyze presentations from many SAP, and consulting firm sent to us from clients from around the world as part of our fact-checking services. The information presented by SAP consulting firms to their clients is primarily of low quality, and we think known to be false (at least to some degree) by the consulting firms submitting this to their clients.
Search Our Other HANA Content
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.
I cover how to interpret risk for IT projects in the following book.
The Risk Estimation Book
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.
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