I found SAP's initial reactions unnecessarily defensive. Products have growing pains, and the IT/business divide that contributes to business case problems is not SAP's fault - though SAP has a big opportunity to help companies change that conversation.
The plot thickened last February, with an over-the-top S/4 HANA product launch event in New York City that was heavy on fanfare and short on product details. Still, when you announce "the most important product launch in 23 years," that alters the business case discussion.
I thought the Sapphire Now/ASUG annual conference might end up as another tone deaf S/4 HANA love fest, but that was not the case. This time around, SAP stuck the landing, placing customer voices at the center. ASUG also did its part with a far better keynote than in years' past, with a clearly articulated customer position.
Sapphire Now and ASUG - a business case gut check
On the HANA business case front, Sapphire Now + ASUG was good news/bad news. For SAP, the good news is that customers did vocalize their buy-in to SAP's real-time future. During the day two keynote, Walmart CIO KarenAnn Terrel spoke about her team's mission to reinvent Walmart as a technology company inside the world's largest retailer. Terrel takes disruption seriously, and speed is a big part of it:
A tech organization that is not thinking about speed is a company that is going to to be disrupted from its position. Digitization is not just a buzzword, it is incredibly real – if you want to lower overall cost, to get to real-time and to serve customers.
If SAP customers see speed as the lever to reshape their business before they are marginalized by disruption, that lines up well with SAP's S/4 HANA ambitions. If customers see SAP as more strategic to their customer-facing projects, rather than a back office processing engine, that also bodes well for buying into S/4 HANA. Terrel later endorsed the S/4 HANA approach - though not without joking that she wanted the implementation to be done in her life time.
I heard similar feedback off stage from ASUG members, though S/4 HANA is still too new to offer a definitive customer view.. But even if a healthy chunk of SAP customers buy into the S/4 HANA future, that doesn't mean the business case problem is solved. Customers still have to make the case for a major project that will change the IT/business relationship.
Since those user group announcements last fall, I've spent some time to researching the HANA business case challenge. Some of that work took the form of a client project (see disclosure).
The SAP S/4 HANA business case - my views
I flew to Orlando in May with a chance to test my own tentative conclusions. Existing SAP customers who want to build an effective SAP HANA business case should consider the following:
1. For customers that are not running on a recent Enhancement Pack (6 or 7), and who don't have an effective testing/patching/upgrade approach in place, moving to S/4 HANA can be seen as daunting from a budget and IT logistics angle. An effective testing/patching/automation plan is essential; customers on older releases are often struggling with this issue.
2. Many of the technical steps in moving to S/4 HANA are hard to justify from a pure business standpoint - though these steps can potentially be packaged into consolidation/standardization efforts that bring an attractive TCO.
3. It is a misconception that you can't build a good S/4 HANA business case on a IT-focused, TCO approach. It can be done, especially in cases where customers are simplifying and consolidating a messy architecture, and are somewhat up to date on Enhancement and support packs. One ERP on HANA customer I spoke with built a business case that combined database reduction benefits (1.5 TB to under 300 gigs in one case) with productivity improvement benefits based on report speeds (e.g. when you have a team of 25+ people, time saved running certain reports can be calculated across the team and across months to determine a productivity savings).
4. Surprisingly, the business potential of the HANA platform is rarely factored into the initial HANA use case. Whether this is a function of a disconnect between IT and business or simply a means to an end, most HANA business cases I studied involved a classic IT-based TCO approach, focused on reduced database infrastructures and sandboxing the impact of processing speed and incorporating that into the business case. As those customers went live, typically with Suite on HANA, add-on use cases focused on business growth emerged.
Other components of a TCO business case I came across during interviews:
- Use S/4 HANA as a chance to move CRM and other SAP systems onto the same database, trimming the the landscape substantially. Other systems, such as BW, may also be dramatically reduced in size.
- Get inside views of SAP's roadmap from relationships with product leads and experts. Use that info to sell executives on alignment with SAP's long term roadmap.
- Negotiate bundled SAP HANA deals that are timed with the quarterly close, when SAP sales teams are especially motivated to offer discounted terms.
- Consolidating disparate SAP instances, and/or moving systems to cloud or hosted options can also bolster a TCO case, though cloud and hosting costs are not necessarily cheaper when calculated over years.
- Take your CFO to Sapphire Now. Let her get the low down from Hasso Plattner directly and contemplate the business implications.
Needed: an S/4 HANA roadmap with clearer ROI language
During the Sapphire/ASUG event, I put these conclusions to the test. For the most part, they held up, though I did rethink some aspects, and added more details.
One issue I hadn't factored in was the need for a clearly delineated S/4 HANA roadmap. Forrester's Paul Hamerman, a master of cutting to the chase during keynote Q/A sessions, pursued this angle. He raised the issue on Twitter, where he was pointed to SAP's Service Marketplace (a log-in area for paying customers).During the day two press Q/A with Bernd Leukert and Steve Singh, SAP again pointed Hamerman to the Service Marketplace piece, but Hamerman had already read it: "It's 25 pages, I've seen it, and it's really not that clear on what's available cloud and on-prem." (SAP's Sven Denecken has put out some detailed S/4 HANA FAQs in the public domain - they aren't formal roadmaps, but they are an example of the transparency SAP is striving for. For the latest on S/4 HANA cloud I also suggest Dick Hirsch's Whiteboarding SAP S/4 HANA).
This led me to a new idea: SAP should create a roadmap document that not only delineates the steps to S/4 HANA for cloud and on-premise, but articulates a business benefit for each step. A business justification for each migration phase would be an excellent model for the type of IT/CFO conversations S/4 HANA should encompass. I brought this up during a blogger meeting with SAP executives. They agreed that some type of S/4 HANA "business roadmap" was needed. What form that takes, time will tell.
SAP still has trouble articulating the business benefits of S/4 HANA in practical ROI terms. Both Den Howlett and Brian Sommer posed pesky questions at Sapphire Now on this issue. Since that time, three diginomica team members have addressed this topic:
Den Howlett - Solving for S/4 HANA customers
Brian Sommer - Selling SAP’s Run Simple is not the same as achieving it
Charlie Bess - Is there more value in SAP S4/HANA than first appears?
All three have different angles and are worth a read. In the conclusion of this piece, to be published Wednesday, I'll take a deeper look at the S/4 HANA migration path, and revisit the business case issue with those technical challenges in mind.
Image credit: dream or reality © faithie - Fotolia.com. Day two Q/A photo by Jon Reed.
Disclosure: Some of the HANA business case research I did for this project came under the auspices of a client project with Bluefin Solutions. The end result, an SAP HANA business case book by John Appleby which I edited, will be released on ebook shortly. SAP paid for the bulk of my travel expenses to Sapphire Now, and is a diginomica premier partner as of this writing.