- 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. If you are negotiating with SAP, neither SAP nor the SAP consulting firms will want you to read this article. They will say the information is not approved by SAP, that Brightwork is not an approved SAP analyst, that information must come from an SAP partner, anything to get you to not use the information in this article. However, one of the worst thing any customer can do is only rely upon information from SAP and a consulting partner when making a decision.
Even listening to Gartner does little to improve accuracy as SAP pays Gartner what we estimate as around $150 million per year as we cover in the article How Gartner Makes its Money.
*This article was written originally in March of 2017, however it was updated and is current as of September 2019.
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.
- HANA is SAP’s first serious foray into databases.
- S/4HANA, on the other hand, is the ERP system. S/4HANA only works with HANA, breaking with the previous tradition of SAP applications being open to different database vendors.
- HANA is not obligatory of any other SAP application other than S/4HANA, although SAP strongly leans on its customers, mostly through providing inaccurate information, to move to HANA for many other SAP applications.
SAP has had a few other databases that they owned through the years, like 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, and by trying to force HANA into historically Sybase accounts they damaged their relationships in the core Sybase financial sector and may of that customer switched to Microsoft SQL Server, which is based on Sybase. It is a feature of the controlled IT media, that the horrible outcome the Sybase acquisition has not essentially uncovered. We covered this topic in the article How Accurate is SAP on the Sybase Acquisition.
A Major Change in Strategy
It is difficult to overemphasize what a change in strategy HANA is for SAP. SAP used to be based around a system that, as with most applications vendors is open to a variety of different commercial databases (although not open source databases).
SAP has very strongly based its strategy around HANA. The pricing for HANA is quite unusual and is important to understanding how to best purchase HANA.
The HANA Based Strategy to Remove Oracle from Accounts
SAP has an integrated strategy regarding HANA and S/4 HANA which is related to removing the Oracle database 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 (see the explanation at the end of the article). 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. That is, it is not that they have not put forward reasons, but upon inspection, none of these reasons check out.
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. And Brightwork’s research into HANA in depth goes back to 2016.
Secondly, SAP refuses to release transaction processing benchmarks (that due to HANA’s 100% column-oriented design, likely are not very good) as we cover in the article The Hidden Issues with SD HANA Benchmarks and they needed to create an entirely new benchmark under the false premise that the old benchmark did not reflect how companies “use” S/4HANA as we cover in the article John Appleby on SAP BW EML Benchmark. Meanwhile, SAP is losing in benchmarking tests to other database vendors and in reports from many accounts globally. In fact, there is a question as to whether HANA can outperform the far less expensive SQL Server as we cover in the article Why it is Likely That HANA Underperforms SQL Server.
However, through both its own and its many partners, SAP has a very effective sales force and the willing army of compliant consulting partners. These partners effectively to prevent this information from being widely known or repeated.
The first thing to know, before understanding the technical details of HANA or its pricing is that the information provided by SAP and consulting companies is unreliable. The only thing the SAP sales rep and various consulting resources are measured on is sales of either software or consulting hours. Consulting companies are not independent checks on SAP, they repeat whatever SAP says. It is accepted that any lie that is necessary to gain that sales is appropriate. When we support companies in negotiations, we see the same lies told again and again. One of our previous clients even were lied to about why there was a price decrease.
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.
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 far fewer than the claimed number of S/4 implementations live, and almost all of these are for a single module – S/4 Finance. We monitor and analyze the S/4HANA case studies as we cover in The Brightwork Study on S/4HANA Implementations. (This article is the introduction. The actual research is paywalled)
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. We covered this in the article Why SAP S/4HANA Should be Free.
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. However, will your friendly neighborhood SAP consulting company explain this to their clients?
Of course not. If you ask a nice SAP consulting firm about whether these are in fact price increases they will dance around the topic.
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).
Getting into the Customer’s Business Regarding Archiving
In most cases when a database is sold, the database vendor sees the sizing as more of a customer determined item. Yet this is not the case with HANA.
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.
After HANA is Sold: SAP’s Next Steps for Follow on Sales
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. 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.
SAP sales reps are excellent at getting the nose into the tent. The nose is brought in normally through false statements. Curiously, very few SAP customers hold SAP accountable for things they said that turned out to be false and that the contracts are based upon these false pretenses. I am repeatedly told by procurement departments that they have no choice because SAP has them “over a barrel.”
SAP consulting companies are also intent on telling the customer to never hold SAP accountable, and that lying is not lying. Of course, the SAP consulting companies have far more allegiance to SAP than to their “clients.”
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 by SAP and SAP Consulting Firms
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, the 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.
Important Facts Related to HANA Pricing
- HANA is quite expensive for a database and SAP knows this. HANA also has a high implementation and maintenance cost.
- 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 deceiving and interferes with the correct pricing of HANA. The runtime license 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, as we have described in detail already, 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 gain the consulting experience 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. When Infosys communicates to the outside world, they tell companies they made a strategic decision to use S/4, however, in actual fact, they have no need for S/4.
How SAP HANA is Now Being Discounted
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, several years ago 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. We covered this in the article HANA Police Indirect Access Charges.
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?
Understanding the Logic for of Trading in Unused Licenses for S/4HANA
SAP often offers customers the ability to trade in unused licenses for a credit towards a HANA or S/4HANA purchase. The motivation by the sales rep is clear, as they are incentivized by SAP to push both of these products. And in fact, some entities that provide SAP licensing advice, advise their clients to do just this.
The logic for Snow Software’s proposal for trading in licenses for S/4HANA is laid out in their article Use S/4HANA to Get Rid of your SAP Shelfware?
In that article they layout the following logic for purchasing S/4HANA.
Let us get into their quotations.
“SAP Business Suite 4 SAP HANA. S/4HANA, for short, is SAP’s latest technology. But it’s also much more than that. S/4HANA represents a fundamental shift in how the mega vendor will generate long-term revenue streams. What is often less-discussed is what S/4HANA means for you, the customer. Not only in terms of technology; but in terms of an opportunity to reshape your relationship with SAP. Without over-dramatizing things, it’s a once-in-a-lifetime opportunity. Why? Because SAP needs S/4HANA to be a success. It needs to demonstrate to investors that it has a business model that is not stuck in the era of on-premise perpetual software licensing. And because it needs to sell S/4HANA licenses, it is offering excellent deals to existing SAP customers to move fast.”
So, what can be seen as left out is that S/4HANA has not been a success and it has had plenty of time to become one. It has a massive installed base (with ECC/Business All in One) on which to sell into, and out research into S/4HANA demonstrates that S/4HANA even in 2019 has little uptake. The details are covered in our research The S/4HANA Implementation Buyer Intelligence Highlights.
Now, while it is true that SAP has a strong desire to show that it’s business model is not suck in an on-premises state, SAP really has Wall Street fooled already on this topic. SAP has successfully adopted cloud speak, and is constantly cloud washing their products. The more you cloud wash, the more Wall Street rewards you. So we have yet another example of an industry that is driven by the opinions of people who don’t have any expertise in the area.
S/4HANA to be Delivered as SaaS?
Secondly, (and don’t tell Wall Street or they will be very very sad) S/4HANA is unlikely to be delivered by SaaS. In our research, it turns out that very few of the implementations have been in the cloud. And in the few that I can find that are stated to be in the cloud or SaaS, they are not cloud or SaaS at all. Instead, they are non-multi-tenant or simply hosted solutions. Customers can expect none of the traditional benefits of SaaS from S/4HANA when delivered this way.
Finally, S/4HANA has nothing to do with the cloud or SaaS.
The quoted paragraph from Snow Software continues:
“And therein lies a huge opportunity for those existing SAP customers, who have typically seen their investments in SAP license increase year-on-year over quite significant periods of time. This is an opportunity to reverse that trend and focus in driving deals with hungry SAP account managers on the licenses and technologies you really need, not the ones you’ve been force-fed over recent years. To understand the scale and opportunity of this shift, we must first look to the past.”
Customers Need S/4HANA?
It is very difficult to argue that anyone “needs” S/4HANA at this point. S4HANA comes with all types of implementation costs and maintenance costs. These costs are far higher than any potential license cost benefit from moving to S/4HANA. In fact, the majority of costs associated with SAP come in maintaining SAP systems, not purchasing SAP systems. I cover this topic in detail in my book on TCO, Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making.
The quoted paragraph from Snow Software continues:
“The fundamental change is that the open architecture of R/3, with the ability to employ third-party databases within the system, is giving way to a more specific database that you’ll require as part of the platform – SAP’s HANA. This is all being done with the promise of improved performance and scalability through in-memory databases.”
Well, the promise of the performance improvement is not analyzed by Snow Software’s article. But as HANA is an analytics database primarily, there is no evidence that an ERP system will run much faster on HANA due to software. Here it is important to draw a distinction between the software side and the hardware side of HANA.
HANA combines a changed database with SSD memory (instead of a spinning disk) so the performance will automatically increase because of the hardware change (SSD), but not necessarily due to the software.
The quoted paragraph from Snow Software continues:
“The faster it migrates everyone, the quicker it can stop focusing its investment in resourcing and maintaining R/3. So, in a perfect world, SAP would spend nothing on R/2 today and, 10 years from now, it won’t spend any money on R/3.
Moreover, S/4HANA revenue is heavily scrutinized by investors in SAP. The faster they see adoption of this new platform, the quicker that is reflected in the share price for SAP. SAP as a stock needs a growth leg to the story despite its strong position and cash flow.
The transition to S/4HANA requires the replacement of third-party database systems with HANA and there is a monetary uplift from doing this.”
Ok, so this is a strange way of saying that the cost will be higher. The cost of HANA is quite high, and the expensive software is just the beginning. The following quotation will focus on support costs, but the support costs are based upon the license cost. Let us continue with the quotation to see how this is a problem.
Lower Cost for HANA?
The quoted paragraph from Snow Software continues:
“SAP Enterprise support customers currently pay (by default) 22% of license costs in annual maintenance for the use of third-party databases within the architecture of their systems. SAP has steadily over the past few years increased this amount from the 15% level in advance of its migration mandate. In lieu of paying an annual 22% of license costs for your database (typically Oracle), you will pay 15% of license costs for HANA*. Additionally, as an incentive to move to S/4HANA, SAP’s extension policies may enable you to apply unused SAP licenses against a credit for the new purchase. A reduction in the software application value means reduction in overall maintenance to be paid on HANA. *Note that individual circumstances may vary.”
The problem is that Snow Software is making a case for the lower cost of the annual license cost for HANA. However, HANA is the most expensive database on the market. So if you decline from 22% to 15% maintenance, the maintenance is lower, but the base is much higher than the database that HANA replaces.
Secondly, HANA comes with other liabilities, such as indirect access liability, that impact the costs of other software, which are a whole other can of worms and which I have covered in part in other articles.
All of this leads back to a central problem with SAP procurement, it is too often focused on the price of the item, or getting a good deal on the item, and making decisions that seem to make sense in an initial cost of acquisition perspective, without working in enough product knowledge into the equation.
Hiding Pricing Information
The problem with hiding pricing information is that it is used as a control technique by software vendors in order to pry information from the buyers. It also greatly lengthens the process of finding out the pricing information and reduces the comparability of applications. In order to function efficiently, markets require published price information. There are some laws in the US on this topic for consumer products, but not for products purchased by corporations. On several occasions, vendors have sent me non-disclosure agreements (NDA) that covered pricing information. However, this is a misuse of the NDA legal concept, as NDAs are designed to protect proprietary information—technical information, software intellectual property—and not pricing information. The legal phraseology implied that I could be sued for sharing pricing information with a third party if it damaged the company’s business. However, wouldn’t any sharing of pricing information, unless the software vendors were the low-cost provider “damage their business?” Pricing information is part of what makes markets work and should be published. There is a very interesting story about the lack of quantification of fees in the mutual fund industry, which has important connections to TCO but in a different realm.
Hiding Price Information as a Control Technique
The problem with hiding pricing information is that it is used as a control technique by software vendors in order to pry information from the buyers. It also greatly lengthens the process of finding out the pricing information and reduces the comparability of applications. In order to function efficiently, markets require published price information. There are some laws in the US on this topic for consumer products, but not for products purchased by corporations. On several occasions, vendors have sent me non-disclosure agreements (NDA) that covered pricing information. However, this is a misuse of the NDA legal concept, as NDAs are designed to protect proprietary information technical information, software intellectual property and not pricing information. The legal phraseology implied that I could be sued for sharing pricing information with a third party if it damaged the company’s business. However, wouldn’t any sharing of pricing information, unless the software vendors were the low-cost provider damage their business? Pricing information is part of what makes markets work and should be published.
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.
The effect of having an SAP consulting firm into your company is like bringing in a fire hydrant that distributes lies instead of water. As soon as the consulting firm begins advising, it is like a jet stream of falsehoods.
The Problem: 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 the 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.
Being Part of the Solution: What to Do About HANA
SAP and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how companies end up paying for a database that is exorbitantly priced, exorbitantly expensive to implement and exorbitantly expensive to maintain.
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our HANA and S/4HANA Pricing and Costs Content
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