SUMMARY: You can’t greenlight a SAP HANA project without a business case. That means anticipating the impact of HANA on the business. To do that, a closer look at S/4 HANA migrations is in order.
In part one of this piece (Pondering SAP S/4 HANA business case realities), I expressed surprise that HANA business cases don’t typically include the business benefits HANA can achieve once in place (e.g. new predictive scenarios, real-time inventory controls for startups and SMEs etc). To better understand why this is, a closer look at S/4 HANA migrations is needed.
To frame this issue, consider these views from HANA expert Kevin Reilly, who is now working closely with ASUG customers around S/4 HANA education. Prior to becoming independent, Reilly built a HANA business case as the CIO of a convenience store distribution firm. For Reilly, it makes sense to start the HANA business case from a technical/TCO angle:
You have to start from the place where you have strength. For most CIO’s, that’s aiming at the lower TCO number. If I can take my ECC environment, and all the hardware that runs it; and my CRM environment, and all the hardware that runs it; and my BW environment, and all the hardware that runs it; and migrate to one set of hardware that all three of them can run on, that’s a solid win. And you can build that into your normal hardware refresh cycle.
Once HANA is in place, Reilly advocates shifting to business-focused projects:
When the Controller says to the CFO, ‘Hey, you know, this report used to take three days. It’s now running in about 15 minutes. What did IT do?’ That’s the door to open a broader business conversation. Once you’re in HANA, you should be able to start looking at things that are related to speed. ‘What if I could close faster?’ ‘What if I could generate work orders faster?’ Those conversations always have value.
The TCO approach Reilly recommends for the initial HANA business case was not exactly the dreamy IT-business collaboration I had in mind, but in his experience, that’s the practical basis that gets these projects live. Once they are live, the predictive capabilities of HANA can be sandboxed and new scenarios tested. Winners then become add-on projects, with new business cases to support them.
Streamlining the chores of S/4 HANA migrations will help the business case
After the show, I had a phone debate with John Appleby of Bluefin Solutions to see how his views lined up. Appleby had just delivered a webinar on S/4 HANA migrations, and he posted the slides for us as well.
Appleby hates it when I do this, because it’s a gross simplification, but these are the basic migration steps to S/4 HANA for existing customers:
1. Move to ERP 6.0, Enhancement Pack 7 (if you’re not on EhP7)
2. Unicode (if not on Unicode already)
3. Move to Suite on HANA
4. Apply Exchange Extensions (similar tech to Enhancement Packs)
5. Activate S/4 HANA functionality
Appleby prefers to describe the migration this way:
1. Getting the house in order – prepping for the move, which includes housekeeping, data reduction, custom code management, and finalizing test management procedures (“housekeeping”, as Appleby defines it, can be pretty impactful: cleaning and/or removing old tables can save 100K in capex if, for example, 1TB of data is purged across multiple systems).
2. Move to Suite on HANA – in other words, move to EhP7 (which might entail a database upgrade also), then Unicode if you’re not already, then Suite on HANA migration. Appleby points out that in many cases, these three steps can be done together using the Database Migration Option of SAP HANA (DMO, reducing cost and testing overhead
3. Activate S/4 HANA – largely the activation of exchange extensions, which will affect table customizations, interfaces etc. Appleby predicts late this year there will be a way to move directly to S/4 HANA from prior SAP releases, effectively bundling steps 2 and 3.
What can be concluded from these steps?
- Clearly, the move to S/4 HANA is pretty intensive from an IT standpoint – depending on the complexity of your IT environment, your EhP and support pack level, etc. Speaking only about the move to Enhancement Pack 7, Appleby says, “This is a fairly significant upgrade and shouldn’t be underestimated.”
- Though these steps read like a technical project, business users are heavily implicatedthrough cycles of user acceptance/QA testing – one more reason why a strong test management plan must be implemented.
But I’ve taken these conclusions further:
For existing SAP customers, it’s much easier to move to S/4 HANA when:
- you’re already running a modern version of SAP ERP, and
- you have a strong test management plan in place
Therefore, SAP needs to:
- provide better test automation tools, and support/encourage third party testing solutions that many customers have found invaluable.
- get as many customers as possible onto the latest Enhancement Packs, even if it means subsidizing some of the costs of doing so. That could mean helping with test management strategy and/or building a case for modernization, whether it’s HANA, Fiori UIs, or easier web integrations.
For the most part, Appleby agreed with these conclusions. I asked him what his ideal prospect is – he reports the vast majority of Bluefin’s Suite on HANA and S/4 prospects are indeed running EhP 6 or EhP 7. That should be something of a wake-up call to SAP.
Customers on EhP 6 or EhP7 comprise a decent portion of the SAP ERP customer base, say 30 percent or so – but there’s plenty of customers not at that stage yet. If SAP wants those customers on board the HANA train, it needs to act.
Appleby points out that SAP upgrade and HANA tooling, including Solution Manager, has gotten much better (he has a slide in his deck entitled, “learn to love Solution Manager.”) However, he conceded SAP could be doing a lot more with test automation – an area where some third party solutions excel.
As he put it, “SAP’s tooling is not state of the art, and that’s a mistake. It’s workable, it moves things forward. But why haven’t they done more with test automation?”
Final conclusions (for now)
We’ve come a long way from BW on HANA as a parallel database. Running a business on the S/4 HANA platform, including HANA Cloud Platform extensions and startup applications, is a far more compelling proposition – one that will put IT and business executives in the same room, sooner or later, to rethink what IT is now capable of.
Just on the startup side alone, ASUG has now entered a partnership with the SAP Startup Forumto help in bringing more exposure to the growing number of validated HANA startup apps via the Customer Startup Network. These apps can bolster the business case with immediate industry solutions that don’t require extensive development.
But this opportunity to change the IT/business conversation will get bogged down if SAP doesn’t take further action to bolster the business case, from both a technical automation and ROI perspective:
- make it financially and technical easy for customers to get on EhP 6 or 7, as per the test automation recommendations I’ve made above.
- flesh out the S/4 HANA cloud and on-premises roadmaps, including a “business benefits” roadmap.
- help companies move beyond a TCO-focused business case by highlighting the growing number of projects that are extending into predictive and business growth scenarios.
- continue the transparent dialogue with customers/partners we saw onstage in Orlando, and that many of us experienced during the show itself.
I didn’t cover cloud scenarios for S/4 HANA here. SAP is continuing to refine how those scenarios might look, but it’s fair to say that a “managed cloud” or public cloud use case would change how the technical/ROI aspects of this are calculated. I’d welcome more content from SAP on these points. In the meantime, I refer you to Dick Hirsch’s Whiteboarding SAP S/4 HANA.
I also didn’t cover the “net new” S/4 HANA business case for new customers in this blog post, though I did interview an interesting net new at Sapphire Now, involving a customer that moved from Quickbooks to S/4 HANA. I’m not ready to comment on the “net new” aspects broadly yet, so let’s call it a wrap for now.
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. Thanks go to ASUG, in particular CEO Geoff Scott, for his support of the the HANA business case projects, and for providing relevant introductions, including Kevin Reilly, quoted in this installment