In past years, I would have got the skinny from former GM/SVP of SAP Collaboration Software Sameer Patel, but he recently took a CEO role at Kahuna. However, Steve Hamrick and Daisy Hernandez, two seasoned SAP Jam leaders, were on-site and game for my pesky questions.
One thing to understand about SAP Jam: the point behind SAP Jam is purposeful collaboration on select use cases - not creating a ubiquitous chat tool across applications. That decision was made years ago, and SAP is sticking with it. You can argue it's served them well; SAP Jam now claims 34 million active users. (Forrester recently did an economic impact study of SAP Jam). But does SAP Jam feel threatened by the Slack announcement, and by surge of messaging-style communications?
The Jam social gateway approach
Before we answer that question, there's another twist: the demo in question didn't involve humans - it involved a Slack bot, which has been integrated into SAP's new "continuous performance management" functionality, also announced at SuccessConnect. But the Twitterati missed something: the Slack integration was made possible through SAP Jam's "social gateway." Hamrick:
The continuous performance management team wanted to do an integration with Slack. They also wanted to work with us, because you have to kind of make Slack enterprise-grade. That was what why we built this enterprise gateway.
The approach behind the social gateway is two-fold: provide a platform for the integration of a range of social tools, not just Slack, while ensuring the tools are compliant, secure, and storing information properly (something Slack does not excel at). Slack might be the messenger-du-jour, but Hamrick knows this is just the beginning:
We don't see think that it ends with just Slack. We may need to integrate SAP with Slack, HipChat, Skype for Business, Facebook for Work.
Hernandez added: "In APJ, it's WeChat." So this integration could be described as Slack-as-a-Jam service, with Jam providing enterprise-grade aspects such as auditing, SSO permissions, security and asset settlements. Yes, machine learning also plays a role:
We're also seeing an evolution across the board in software, building more machine intelligence into the system. That means automated software needs to be able to interact with Jam.
Hamrick sees the potential for two-way information sharing:
You may need to shuttle business contacts between Slack and Facebook at Work, or Slack and Jam. Or you may need to grab on onboarding document from Jam and pull it into Slack.
I wasn't crazy about the Slack - continuous performance management use case, so I asked Hamrick for other possibilities. He brought up a hypothetical sales scenario:
Let's say you're using Slack because your sales reps are in the field. They're sitting there next to a customer or client, and they're like, "What's the latest on this account?" Somebody else should be able to go into that chat and say, "Let me grab it from Jam." Boom, it's in Slack now. I could even query Jam from Slack, get that business context, and bring it in.
Jam could also pull information from Slack to make sure it's tied to the account:
Let's say you wanted to go a step further and say, "Okay. I need to record this as some kind of an activity I did with a customer." That activity will be recorded simultaneously from Slack to CRM and to Jam, where the account management would be happening for a longer term.
The UX pressure comes from business users
But isn't the jugular intuitiveness of a platform like Slack threatening to Jam? Hamrick gives a nuanced yes and no answer. The "no" comes in three parts. First, the Jam-as-gateway approach:
The broader theme we're looking at is that applications are going to become more conversational in nature. But at the enterprise level, these applications need to have some kind of common layer, and that's why we're offering the social gateway solution.
Second is the aforementioned need to add enterprise-grade components to Slack, or as we joked, "IT managers hate Slack." The third aspect is that the Jam team is not going to pursue a generic chat layer; that's a violation of their use case principle:
We think that there's a necessary set of capabilities that we're building Slack into, and those need to be tied to direct use cases. Obviously I want to live in both worlds. I want to be hip, and cool, and develop cool technology, but I definitely want to make sure that in the end, it's doing something that's going to help a business run better.
Hamrick did acknowledge Slack applies pressure to from a UX standpoint:
You're absolutely right, and for that reason we've done a lot of ecosystem integrations... It's not just the API's - we're going direct to these partners based on customer requests. The goal is: let's make this as easy as point and click, and turn it on... I would say that we feel that pressure even independent of Slack.
That pressure is coming from business users:
The line of business doesn't have an army of developers ready to go work on this stuff. They're saying "Look, I'm just marketing, or I'm just sales, or I'm just HR. I just want to click a button, because I've already got this other app." Consumer software definitely always drives some of the expectations.
S/4HANA and Jam - a (very) quick preview
I wasn't letting these folks go without the S/4HANA question. How does Jam fit in? Hamrick:
Professional services is one, because you're talking about project coordination and timelines, so that was an obvious use case.
They are also looking at S/4HANA finance, and asking the same questions: is there a use case around exceptions? And how will the Jam platform have to evolve to handle those issues? The Jam team is looking harder at real-time, and the different communications that factor in:
Software is shrinking. Slack is a sign of where things are going, and you don't have to look far to see voice activation, and text-based interfaces getting smarter. We can imagine being able to - from whatever your preferred real time chat interface is - to interface intelligently with the SAP portfolio, and be able to ask it questions and get answers back from it, and do that across a variety of products. You're no longer worrying about a web interface, or mobile screens.
Machine learning could make these scenarios smarter, for example, a real-time alert from a semi-automated agent that pulls in a relevant (human) expert.
I can understand why even seasoned analysts were confused by this announcement. During the keynote, Jam's role as the social gateway wasn't spelled out. Plus, anytime you mention "Slack partnership" someone is going to run with it.
One reason for my lack of Slackbot demo thrill: I find interactive bots underwhelming due to the current limitations of the machine learning that powers them (see my recent piece, Assessing the business impact of chatbots).
I've always liked Jam's resolve to avoid being a general chat lathered onto software, and assuming value. Hernandez noted that customers are doing things with Jam they couldn't with Slack, such as SunPower, which has engaged employees via a compelling, next-gen Jam portal.
It's easy to make irresponsible assumptions about Slack's enterprise penetration. Yes, Slack is becoming entrenched in some technical communities. When Thomas Otter polled the SuccessConnect HR audience for how many are using Slack, only a few hands shot up.
But - Slack does have a jugular immediacy and ease of use. Slack's ability to ramp diverse constituents up quickly, combining chats and bots, is not Jam's strength. Though you can use Jam for this, it's not ideal. Jam's choice to provide Slack as a service is the right one, but it doesn't excuse Jam from pushing its UX to a new level also. I think the Jam team gets that. As always, it's about execution.