SAP Goes to SAPPHIRE 2017, Part II

(We’re back, discoursing on the challenges SAP will face as platform proliferation and the shifting of the edge app issue into the hands of the LOB developer influences what vendor’s tools and platform will be used to power its customers’ digital transformations. Where we last left off, I was about to illustrate SAP’s dilemma with a true-to-life story.)

I recently had an experience that, in a nutshell, summarizes the gist of the SAP challenge. I was speaking with an LOB manager working at long-standing SAP customer with a field maintenance problem it needed to solve. The problem was a classic digital transformation story: transform how field maintenance is prioritized by trying to understand what the cost of having a particular asset offline for a particular period of time would actually be. If it turned out that there was no impact, maintenance could be delayed, saving a ton of unnecessary expense and resources. And if maintenance was needed online immediately, the decision to spend the extra time and effort in overtime or other costs could be well-justified.

This meant understanding everything about the asset as well as the demand side of the market in which the company operated. As you can imagine, in its ultimate form this is the ultimate edge app: take existing on-premise data about the asset (ERP data), add real-time operations data about the asset (IoT data), marry it to external market data (unstructured web data), get information about the availability of maintenance people (talent management data) and parts (warehouse management), and plug it into a model (based on AI/machine learning algorithms), and, voilà, you’ve digitally transformed asset maintenance.

Sounds like a Bill McDermott/Bernd Leukert/Rob Enslin dream come true. Except for one little sticking point: this customer isn’t building this on SAP’s platform, nor is it using SAP’s tools. There’s a small license to be paid for accessing SAP’s APIs (because who wants the audit police to show up and ruin everyone’s day), but that’s it. The customer went with another vendor’s dev tools, which meant using that vendor’s platform, and, when the time is right, that vendor’s ML and IoT interfaces.

Ouch.

This is why the elevation of Rob Enslin to the title of Mr. Cloud is so important. Rob’s new title is effectively an asset maintenance transformation at the executive level in its own right. The new role is an acknowledgement that SAP’s manifold assets may be in wide use across many medium and large-size enterprises, such as the one I just mentioned, but that doesn’t mean they’re ubiquitous or even well-known by the SAP crowd. In too many cases the SAP ‘crowd’ consists of the SAP ERP people at the company – full stop – while the customers using SAP’s non-ERP assets don’t think of themselves as SAP customers, a position encouraged by other non-SAP user constituencies who still think that SAP is synonymous with “poured in concrete.”  Rob’s job #1 will be to convert the SuccessFactors, Ariba, Concur, Fieldglass customer base into seeing themselves as SAP influencers, and help convert the non-SAP non-believers to the one true religion.

If he doesn’t, then there will be more and more cases where individuals like the one above, with no particular connection to SAP and a connection to another platform vendor, opts to choose something other than SAP for the next digital transformation project: The more disconnected a user is from SAP the more likely that user is to not opt for SAP technology when the time comes to step up to something transformative.

Among Enslin’s many challenges is to undo this disassociation and build SAP brand loyalty inside these non-ERP and non-SAP assets. And then use that loyalty as the jumping off point for making sure SAP has a seat at the table when digital transformation projects get the green light from LOB management. This won’t necessarily be easy. There’s a lot of incumbency in the non-SAP world too, and SAP’s competitors – Salesforce.com and Microsoft in particular – are doing a good job on maintaining their respective cozy positions with their respective line of business users. And I was reminded at the recent SuccessFactors analyst summit that, for many non-SAP ERP users, the SAP brand is seen as anathema: it’s not just that the positives as too low, it’s that the negatives are also too high.

This is why Salesforce.com’s Trailhead and Microsoft’s PowerApps are so dangerous for SAP. If the LOB is looking to build a transformative app, Trailhead and PowerApps provides a way to at least get started. And, considering how well both companies are doing marketing these tools, getting a similar reflex motion towards SAP and Build will be problematic.

Which of course is where Bernd Leukert and newly appointed CTO Bjoern Goerke come in. SAP has to not just build great platforms and middleware and apps, it also has to offer great development experiences that are both accessible and known to be accessible. The emphasis on known to be is essential: SAP has been pretty stealthy making its developer outreach programs as well-known to the market as those of Salesforce.com and Microsoft. Build’s market awareness is pretty low too – ask most developers what build is and they will tell you it’s Microsoft’s developer conference, currently taking place in Seattle.

In contrast to the massive Microsoft Build event, and must-have, oversold, three day orgy of Microsoft tech products and direction, to date SAP’s developer efforts have been pretty stealthy. I was surprised to find out recently that SAP ran 140 developer events last year, and that one third of the attendance at those events was by developers new to the SAP ecosystem. In fact, to its credit, SAP’s approach has been quite global. But they seem to have missed a few important places where they might be better seen, such as Silicon Valley. 

I mention this not because I believe that Silicon Valley is the center of the tech universe, which it isn’t, but because of its perception as the center of the tech universe. While SAP’s rest-of-world efforts are laudable, the PR value of being in the Valley as a means to capture developer mindshare is significant: capturing developer and VC mindshare is essential to being a platform player in search of an army of developers and ISV partners, and the Valley is a key place to go hunting for that mindshare. So job number one, IMO, is to be much more public and visible in the competitive landscape with what developers can do with SAP.

(To its credit, SAP has been touting is new relationship with Apple, and I’ve heard more than one SAP exec talk glowingly about unleashing an army of IoS developers to develop on the SAP Cloud Platform and Fiori. If only such an army existed. I think a regiment might be a better characterization – I think it’s safe to say the percent of IoS developers capable of building enterprise apps is directly proportional to the number of enterprise-class apps in the Apple Store. But early indications are that there is a critical mass of IoS developers building mission critical apps.)

SAP also has to be more out in front of the commerce side of being a platform vendor, and that means more presence for its digital store assets, such SAP’s Digital Store, its AppSource store (which is a showcase store, not a place to actually buy apps the way the Digital Store is) , and, unfortunately, the other stores that constitute platforms for selling partner wares to the SAP ecosytem. A digital store experience is an essential part of the overall transformation of SAP: if SAP is going to be a platform vendor, and attract waves of developers and internal LOB users, and make its mark as the go-to company for digital transformation, then it needs a place to market partners’ assets that is easy for partners to tap into and is intended for a more public commercial audience.

This is a key capability that could help SAP capture LOB users might otherwise go elsewhere. If they find what they’re looking for – or close to it –  in an SAP store they may not be tempted to go running off building new edge apps with other vendors’ tools. Likewise, newly recruited IoS developers will find a familiar commercial outlet for their creativity. In other words, SAP would begin to be seen as a big-tent vendor with broad appeal and not just another ERP vendor gone cloud.

All of which brings us back to the story of the SAP customer who digitally transformed without SAP. Each of these touchpoints – better synergy between SAP assets, better identification with SAP outside the traditional SAP ERP customer base, better developer experiences, more reflexive moves to Build and Cloud Platform – needs to be shored up in order to stop the bleeding of edge apps development from SAP to the competition.

This is what I’m looking for at SAPPHIRE this year, much more than more demos of IoT proofs of concept and machine learning whiz-bang predictive analytics apps. Don’t just show me that you can build great next-gen edge apps, show me why building them with SAP’s platform, dev tools, and Cloud Platform APIs makes them better. Because without the uniqueness of SAP’s advantages leading the message, SAP’s ability to capture the attention of that next non-SAP LOB manager with an IoT or ML problem to solve will continue to… what’s the technical term? Suck.

Messrs. McDermott, Leukert and Enslin have an enormous pallet of assets to assemble into a coherent message worthy of SAP’s total value to its customers. The challenge reminds me of William Gibson’s famous admonition: The future is already here, it’s just unevenly distributed. SAP’s future is already here, but the understanding and use of that future isn’t well-enough distributed, both inside and outside SAP.

The time for that to change is now.