- Bloor Research covered S/4HANA in a research publication.
- We review the accuracy of this publication.
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.
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 is offering 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 to the passive repeaters that are SAP’s reliable consulting partner network, all the required functionality is contained within ECC. As well as all best practices as well as is 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 for 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, while it may improve the user experience, 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 not there. The central point made by Bloor 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 the issue of 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 accurately 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 place the emphasis back on 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 disagree with Bloor in a way that strengthens Bloor’s overall case. For those interested in the details, they 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, which is 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 of the fact that IBM and Oracle know to drop the hammer on HANA if they saw fit. The only reason that they have been so silent up until this point is that they have been playing 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.
I think they will, as I wrote a while back now in the article Why SAP Will Have to Backtrack on HANA.
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.
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?
Advice on Enjoying the S/4HANA Quiz
To see the full screen, just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.
What I love about Philip Howard’s writing is that 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 core truth of the covered topic. This article by Bloor Research receives a 10 out of 10 for accuracy. We have evaluated many articles on S/4HANA, and it is very rare that an article scores higher than a 6 for accuracy.
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.
Getting the Most Accurate Information on SAP
Accessing Custom SAP Research
We provide custom research into SAP, as well as fact checking of the claims of multiple options. To find out more, contact us.
The Real Story on ERP Book
How This Book is Structured
This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.
ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.
Break the Bank for ERP?
Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.
By reading this book you will:
- Examine the high failure rates of ERP implementations.
- Demystify the convincing arguments ERP vendors use to sell ERP.
- See how ERP vendors take control of client accounts with ERP.
- Understand why single-instance ERP is not typically feasible.
- Calculate the total cost of ownership and return on investment for your ERP implementation.
- Understand the alternatives to ERP.
- Chapter 1: Introduction to ERP Software
- Chapter 2: The History of ERP
- Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
- Chapter 4: The Best Practice Logic for ERP
- Chapter 5: The Integration Benefits Logic for ERP
- Chapter 6: Analyzing The Logic Used to Sell ERP
- Chapter 7: The High TCO and Low ROI of ERP
- Chapter 8: ERP and the Problem with Institutional Decision Making
- Chapter 9: How ERP Creates Redundant Systems
- Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
- Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
- Chapter 12: Conclusion