SAP's HCM strategy part 3 - the bits I missed

Since the stories I wrote last week on SAP's HCM strategy, I've had interesting conversations that add additional color to the over-arching story.

There was one issue that I didn't factor into my thinking that is important but doesn't change my overall position.

Several people contacted me to say that in my initial analysis, the worldview I expressed was too U.S. centric. That was never intentional although I understand why that looks the case for some readers.

Vinnie Mirchandani put it this way:

Even though its cloud acquisitions – SuccessFactors, Ariba, hybris, Concur etc – were not cheap, they have helped keep SAP competitive on this [U.S.] side of the pond. With what we have seen in the first couple of years of S/4HANA the ship is tilting back to the on-premise world. Oh sure it promises three options – public cloud, private cloud or on-premise but the public cloud option is a tiny portion of the deployments.

It’s still early in the S/4 journey. I think SAP should go talk to Mercedes and Toyota and Ford about how they deliver both right hand and left hand drive and a mix of automatic and stick-shift (and many hybrid gear configurations).

The US market has evolved very differently from the European market. Time to develop a clearer, two-tier strategy.

The car metaphor, while stretched is not without merit. As one consultant pointed out to me, the variety of working agreements across German companies is such that a rip and replace for a cloud-based system (regulatory restrictions aside), is mostly untenable.

I recently (Dec2017) bumped into compat issues at a huge intrnl company that is happily using nw7.0 pl 18. You must understand @sap has specific user base. To increase pathlevel would be like going to a war. Try imagine actual upgrade. Transition to cloud? Unthinkable :)

— Lukasz Sawicki (@lukaszsawickiwx) January 14, 2018

Another consultant talked about arcane working practices that require painful calculations to be made around pay based upon a precise interpretation of 'seniority' as an example of how customizations to a system can lead you down innumerable rabbit holes. It's a fair point.

These and other anecdotes reminded me of the employment practices I saw in France and Spain, which to the outsider have strange consequences. For example, many small businesses shut down fully when holiday period comes around because the cost and administrative hassle of employing people are too great to warrant staying open. The UK appears to be heading that way too.

On the other hand, I heard that much of the DSAG resistance came from concerns around payroll. That one I get although when pay ties to agreements that have to be codified...you can quickly see where this goes in terms of both Z-programs and the attendant maintenance upkeep that's in addition to license costs. Is it any wonder then that (some) payroll consultants are (relatively) happy to see SAP's turnabout.

Regardless and despite the fact I didn't take enough cognizance of these factors, my problem remains the same. To understand this, we need to rewind the clock to 1975 (or thereabouts.)

The customization conundrum

I recall Hasso Plattner, co-founder of SAP telling a group of us that one of the significant advantages of S/4 HANA applications was the ability to simplify landscapes. That was meant to be a largely technical offering but it is important to contextualize this concept with something else he said.

The way Plattner recalls the early days of SAP, the decision was made - sometime around 1975 - to cut a deal with Nestlé that allowed the customer to customize the code. It allowed SAP to snag a very important customer while also offering what has essentially become a toolkit of processes assembled whichever way the customer needs. While this was one of the keys to getting SAP to where it is today, Plattner said that in hindsight, he saw this as a mistake. Apart from anything else, it led to the creation of many 'pieces' of proprietary processes, a significant number of which eventually withered but were never killed off.

Move forward to 1992-93 and the dawn of the client-server era. Then, the SAP message was 'standardize on these processes, re-engineer your organization and you'll have a much more efficient business.' As a customer, you still needed to have consultants and the Big Four plus plenty of others got rich on that work. But, customization had become a feature of what SAP delivered to the point where, in my view, standardization was something of an illusion. Looking back, I believe that is why it took so long for customers to see value from their SAP investments. Now that value is being seen, it should not surprise that customers don't want to risk those investtments.

Move forward again to 2006-7 when SaaS started to emerge as a competitor to the client-server applications landscape. SaaS, or as we more generically call it these days, cloud, is predicated on the idea that you configure not customize. It's an essential part of the vendor's operating model. For a company like SAP, this is a wrecking ball proposition. Even so, SAP could legitimately argue that a variety of business processes are SO important to a business that they should never be considered as candidates for cloud operations. Paying people is one of those processes.

However, as competitors quickly discovered, if you build something from the ground up for cloud operations, you can start with a clean sheet of paper and design around the need for customizations. At least to some extent. In the cloud world, to achieve functional parity with on-premises client-server, and as needed in certain countries, you need a PaaS so that the white spaces and oddities seen in some territories can be taken into account without damaging the core. This is something that is only just starting to emerge in a meaningful way from cloud solutions that address important transactional system functionality in the SAP-centric world.

When viewed through that lens, it quickly becomes apparent that:

• The ability of SAP customers to (eventually) codify what they needed via a mixture of assembled processes plus supported Z-programs has served them well. Global customers need small armies of people to keep those on-premises systems running, but at least they work efficiently. Smaller companies have learned how to keep the lights on while automating processes too.
• Expecting SAP to develop a cloud-based system that can mimic Z-program customization is not something customers should plan for anytime soon. In my discussions with consultants, I argued that after 35 years, isn't it reasonable to expect that much of the development to support idiosyncratic working practices ought to be baked into the core HR? While that might be true for 90% of the time, it is the 10% that's problematic.
• In an unintended way, SAP has got itself out of alignment with a significant and vital proportion of its customer base, those in DACH. On the one hand, the company wants to talk 'simple' as articulated through a digital core and with cloud apps, but on the other hand, there just isn't enough in the core to meet the needs of those same customers. Couple that with a less than full-on commitment to cloud in the manner that Oracle (for example) has articulated, and it is easy to understand why the SuccessFactors alternative was seen as a forced march to something that isn't necessarily required or wanted and why, therefore, the current suggestion is in play.

Where are we now?

Hindsight is always a beautiful thing and, of course, everyone will have their spin on this story.

You can, for example, argue that expending so much time and effort in the 2008-14 period developing HANA was a mistake when there was so much activity elsewhere in cloud development. But then you have to see this through SAP's eyes to understand what they were endeavoring to achieve.

HANA - at least to my mind - was always about addressing the burgeoning need for robust, predictive analytics at a time when topics like IoT were in the front view mirror but not yet fully in view. The fact SAP subsequently saw an opportunity to use HANA as the means to consolidate its hold on customers through a performant database lockin while at the same time providing a simplified landscape makes logical sense.

But - in doing so, SAP didn't adequately factor in the need to be wholly committed to the cloud as a vendor such that it can present a convincing customer case. And, let's be fair, HANA wasn't exactly the most beautiful of rollouts. Even the most die-hard HANA fans will regale you with tales of woe in the 2012-15 timeframe. Does a stable customer base want to hear that? In those terms, it should not surprise that customers in the shape of DSAG are pushing back.

What next?

A good number of those I spoke with hope SAP will reconsider and do what Mirchandani implies; extend the existing portfolio from 2025 to 2030 but with a parallel project that brings the whole of SAP HCM to the cloud. That sounds fine in theory, but then how does SAP address the Z-program customizations that are needed today? There is no obvious pathway because otherwise, the issue would not have arisen.

The situation is made more complicated by the fact that there is a degree of wheel reinvention across customers. How is that solved?

And just to add a bit more pain to the problem, one consultant I spoke with doubted whether some customers could figure out what they'd done in the first place, let alone consider a replacement. That sounds dangerous to me.

If the consultants I spoke with are correct, then a combination of doubling down on core processes coupled to a robust PaaS makes (some) sense. But then it will need to be delivered in a multi-tenant environment in order to make the economics stack up.

An overall lack of trust featured in the conversations I had and you get a sense of that from the tenor of the DSAG announcement. That does not bode well.

The good news is that things in the SAP world don't move as quickly as they do elsewhere. SAP has time to solve the problem in a graceful manner. In the meantime, I still believe competitors will enjoy an unexpected bonus.