How to Best Understand Bloor’s Research on S/4HANA
Executive Summary
- Bloor Research covered S/4HANA in a research publication.
- We review the accuracy of this publication.
Introduction
In June 2017, Bloor Research produced the white paper titled Exploding the Myths of SAP HANA. In this article, we will evaluate the accuracy of this Bloor Research article.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
Article Quotations
Like the other things we have discussed, this is not straightforward. You might think that S/4 HANA is simply the replacement for Business Suite: that it is SAP’s new ERP suite, but it is not that simple. This is because some of the applications that were previously in Business Suite are now only available as SaaS (software as a service) solutions running in the cloud. For example, SAP SuccessFactors is a human resources application, while SAP Concur is a SaaS application for managing business travel and expenses. Other such applications include SAP Ariba and SAP Fieldglass. All of these have been acquired because SAP saw a danger that competitive vendors such as Workday or Salesforce.com would eat into its customer base. However, as acquisitions these are not native SAP HANA applications, and in fact they run on the SAP HANA Cloud Platform, which, as we have seen, is not necessarily HANA-based at all!
These statements are true…however, they are a unique way of looking at the issue.
SAP offers several applications that provide superior functionality and usability to the standard functionality in ECC, or now S/4HANA. Previously these were called best of breed applications. Now, if these vendors were not owned by SAP, even though there is minimal integration benefit to SAP having acquired them (SAP is notoriously slow at developing adapters for acquisitions — having it take over five years in some cases), SAP would have told customers to absolutely stay away from these products when they were independent. Deloitte, Accenture, et al. would have said that same thing..bemoaning and pointing to the terrible thing that is application integration.
According to SAP and the passive repeaters of SAP’s reliable consulting partner network, all the required functionality is within ECC. As well as all best practices and are covered in the article How Valid is SAP’s Best Practice Claims?
However, as soon as an application is acquired, SAP’s story does a 180, and the customers should now purchase this “third party application.” What is curious is that the story changes the day after the acquisition is made, far before SAP does anything with the product from an integration perspective.
So while it is true that these applications are prescribed by SAP and true that they replace lagging functionality (mostly, HRM payroll has no real equivalent in SuccessFactors), Bloor’s perspective here is quite interesting. And seemingly a new way of looking at SAP’s acquisitions concerning the pitch for S/4HANA.
The Story on Fiori and HANA
In this context, it should be noted that SAP Fiori, which is a framework for porting applications across mobile environments, is based on SAP NetWeaver and does not use or require SAP HANA for SAP transactional workloads.
I agree in one respect in that there is absolutely no technical reason for Fiori to be connected to HANA (although SAP tries to convince people that there is). However, SAP has connected Fiori to HANA to lure people into using HANA and to using S/4HANA. The evidence? Well, first, the presentation layer is not related to the database layer. But second, before customers pushed back on SAP through user groups to stop SAP from charging for Fiori, Fiori used to be developed for AnyDB. But when SAP decided not to charge for Fiori (due to resistance), they stopped making Fiori apps for AnyDB.
Technically there is also no reason that Fiori could not be used with ECC. However, SAP has no interest in providing something that may improve the user experience and does not drive companies down the pathway that SAP wants.
Fiori Based on Netweaver?
Now, as for Bloor’s contention on Fiori being based on Netweaver. Netweaver is a marketing term that describes things inside the construct or the box of Netweaver, as covered in the article Did Netweaver Ever Actually Exist? For this discussion, the topic is neither here nor there. Bloor’s central point regarding the lack of dependence between Fiori and HANA is 100% correct.
Improvements in S/4HANA?
The other – usually on-premises – parts of S/4 HANA are direct replacements for current Business Suite functionality (expect for SAP industry-specific solutions, where direct functional mapping into S/4 HANA industry solutions may not be currently available) and, at least at present, these application modules only run on SAP HANA as the underlying database. While we do not intend to dig into the particular features of these modules, we will make the comment that there are valuable new capabilities in these applications and there is an improved user interface.
I would have to see the list that Bloor is referring to. It becomes a lengthy and complicated discussion. Secondly, a lot of functionality is removed, and some of that functionality was relied upon. If some are better, there is enormous complexity in moving to it due to the analysis required and dropped functionality, etc..
Regarding Fiori, this would be true if Fiori were implemented, but Fiori has a lot of overhead in setting up, and most companies are using a far cut down number of apps, as some apps do not work.
However, these new capabilities are generally not core features but ancillary: useful but not essential, at least in most cases. We therefore return to the point made earlier: that you need a compelling business case before you consider the costs and trauma of migrating to S/4 HANA.
This is accurate, as I just pointed out. One can debate the potential benefits of changes, and SAP and Deloitte, and Accenture et al. will be pushing hard on a one-sided view of the benefits. But there is simply no debating that the costs of obtaining these benefits (even if they do exist) are very large.
Now SAP and Deloitte, and Accenture et al. do not care about the costs. Deloitte and Accenture et al. revenues are, in part, the mirror of these costs.
What Areas of Emphasize Over Others
Moreover, in our view, any such decision will typically be in competition with competing demands such as transitioning to a data-driven enterprise, meeting new compliance requirements such as general data protection regulation (GDPR) or implementing Internet of Things (IoT)-based technologies. We would argue that these are more likely to be priorities than upgrading your ledger systems. 60% of DSAG (German speaking user group) users see adopting to the digital economy as the first priority.
Bravo. Spot on. SAP is trying to emphasize ERP, but the fact is that ERP systems never provided the ROI that Gartner or SAP said that they did, which is covered in the book The Real Story Behind ERP: Separating Fact from Fiction.
The data is in, and the right answer is to reduce one’s investment in ERP (which should have been reduced by now given the decades of investment companies have already put into ERP) and move those funds into investments outside of ERP.
SAP & IoT
It is also worth commenting as an aside, and in the IoT context, that while SAP is certainly active in the IoT space (for example, SAP Leonardo), the company does not appear to be as committed to open source technology as some other vendors active in the IoT space.
Now here I have to disagree with Bloor. However, I’m afraid I have to disagree with Bloor in a way that strengthens Bloor’s overall case. Those interested in the details are covered in the article Why SAP’s Leonardo Seems so Fake.
Multiple Implementations of S/4HANA?
This is in contrast to IBM, for example, which has a long history of supporting both open software open standards (for example, Node.JS, Eclipse, Apache, Linux, Hyperledger, Node-RED, IoT, JAVA, Spark, Spark ML, JanusGraph, Open Data Platform).Despite all these comments, we recognise that for some organisations it may make sense to consider migration to S/4 HANA. However, even here, life is not simple.For example, the first module of S/4 HANA to be released was so-called “Simple Finance”. There were several drawbacks associated with the original release of this. For example, there was (and is) no integration with Business Suite processes. Moreover, there was (and is) no easy migration tool to allow you to move smoothly from Business Suite to Simple Finance. This remains the case for all S/4 HANA applications. Further, the latest version of Simple Finance (16.10) is not compatible with the earliest version of that product –– meaning that you cannot simply upgrade (you have to do a “system conversion”) from the latter to the former but will have to migrate (with, again, all the costs and risks that that implies) to the latest version. Frankly, we consider this to be remarkably short-sighted on the part of SAP. You could hardly design a process more likely to put people off moving away from Business Suite.
This is a devastating indictment of SAP’s strategy. Not only was there never a migration path to S/4HANA from ECC, but there is also no migration path from the earlier versions of Simple Finance (now Finance) to the more recent versions. How many times does SAP expect customers to reimplement its products?
Investing in Best of Breed
Finally, if you are seriously considering the move to S/4 HANA, bear in mind that there are third party competitors to Ariba, Concur, SuccessFactors et al. Indeed, the pressure that SAP has been applying to Business Suite users to migrate to S/4 HANA has backfired at a number of companies, where not only have they not migrated to HANA (with or without S/4) but they have started to use competitive SaaS products like Salesforce.com and Workday.
And this is the best strategy, outlined in the article How SAP is Now Strip Mining its Customers.
SAP’s Financial Innovation?
So, one obvious question is: what do you do if you don’t migrate away from Business Suite? The answer is that SAP has committed to maintaining support until 2025. So, we don’t think there is any rush. Moreover, things change. For example, SAP has relatively recently joined the Hyperledger consortium, which is developing Blockchain as a mechanism for supporting financial ledgers. This is likely to revolutionise the way we process account information in the future, but the applications to support this will be profoundly different from those we use today. So, do you really need Simple Finance today?
Great question/assertion. Are SAP customers really in need of replacing their FI/CO module currently, or are those needs met better with other finance applications that can be connected to FI/CO?
The Digital Boardroom
On a comparable note, SAP will suggest that migrating to SAP S/4 Enterprise Management is a critical component that contributes to digital/front-office IT enabled business innovation. However, our experience suggests that many enterprise clients do not consider one to be a pre-requisite for the other.
Correct. This assertion by SAP is merely marketing fiddle-faddle. SAP has been carrying on about the Digital Boardroom, but this is not a real thing.
Costs of Non SAP Databases
A second consideration is that SAP has been increasing the charges that it applies to using third party databases, in an obvious attempt to encourage users to
move to SAP HANA environments. This may need some explanation.Historically, there were benefits for licensing AnyDB choices from SAP SE. As a result, many companies previously opted to license AnyDB directly from SAP under OEM agreements. However, SAP is driving up the cost of these. Hence there is an increasing differential between the costs of licensing and maintaining these directly from IBM or Oracle as opposed to going through SAP. We would therefore advise looking at this as a possibility.
Well, even still, moving to HANA is more expensive on a TCO basis. SAP should also be conscious that IBM and Oracle know to drop the hammer on HANA if they saw fit. The only reason they have been so silent until this point is that they have played nice with SAP.
But SAP’s Achilles heel is that most of their statements about HANA are technically inaccurate.
The third major question is whether SAP will relent on its insistence that S/4 Enterprise Management applications can only run on the SAP HANA database.
As I wrote a while back now in the article Why SAP Will Have to Backtrack on HANA, I think they will.
Moving S/4 to AnyDB
Some time ago a spokesperson for SAP assured Bloor Research that if third party database vendors could demonstrate equivalent functionality with equal or better performance then SAP would certify those products to run with S/4 applications. Similar statements have recently been repeated in E-3 Magazine, that SAP may support Db2 BLU with S/4 HANA.
SAP should have to enter the Liar’s Annonymous for making this statement.
To date, no such certification has been forthcoming, despite pressure from SAP user groups such as the following statement from DSAG: “in terms of specific requirements, we want SAP to maintain a real freedom of choice for customers when it comes to databases, among other things.
Once again, DSAG is the only SAP user group with any independence from SAP.
Optimizing Sales of S/4
Alternatives to SAP’s HANA database must remain possible with no restrictions on functionality or performance.” From our point of view, it is fairly obvious that SAP would achieve significantly more S/4 sales if S/4 was allowed to run on third party database products. Moreover, Bernd Leukert (SAP executive board member) explicitly emphasised, during a press conference at the DSAG yearly congress, that it would be technically possible to convert Db2 with BLU for S/4. Thus, the question is, which is more important: S/4 or HANA?
At the moment, it would appear that the answer is the latter, which begs the question of how long this state of affairs will last. As we head into the next decade it may be a question of who blinks first.
Exactly
SAP cannot both optimize the sales of S/4 while also stipulating that all S/4 customers accept their database. And accepting a new database also means that SAP will nudge their customer to increasingly replace as much of their Oracle and DB2 infrastructure with SAP products.
We do not want to suggest that you should not consider implementing or migrating to S/4 HANA. However, we do suggest that you do this only if you have a compelling business case for doing so. And by business case we mean functionality rather than performance or scalability. Moreover, you should think carefully about whether this is where you want to invest, as opposed to transitioning to a data-driven enterprise (the Internet of Things, Industry 4.0 and so on). In addition, the truth is that if you have issues with anything other than features and capabilities you will probably be better off upgrading your existing AnyDB implementation. And finally, we strongly suggest that you support your user group in putting pressure on SAP to support S/4 running on AnyDB.
The problem is that what is the business case for using S/4HANA?
Conclusion
I love Philip Howard’s writing because he presents things and thinks about things in a way that is in stark contrast with how most people interpret an issue. Therefore he makes me think about things in a new way. There are several paragraphs in this paper that present things in a way that I had never thought of before. I knew the components, but I never thought of presenting ideas in that way.
Unlike a lot of material released as research, I consider Philip’s work to really attempt to get to the covered topic’s core truth. This article by Bloor Research receives a 10 out of 10 for accuracy. We have evaluated many articles on S/4HANA, and an article rarely scores higher than a 6 for accuracy.