The Document Is In My Jam Page

I had to step in for David Ludlow last week for an executive presentation on SAP and SuccessFactors solutions. I have done this multiple times in the past and I have used David's solution presentations. This time when he suggested that I present to this group of executives from a US chemical company, I asked David for his HR Insider 2014 Keynote presentation. Usually David sends it via email, puts it in a folder or sends it via an internal file transfer system called SAPMATs. This time however he replied and said that that presentation is in his Jam page. He did not have to say anything more. I knew where to find it.

This is an interesting turn of events. David and many other colleagues have started posting content such as our key presentations to our SAP Jam profile pages so that anyone in the company can access those assets. The key thing here is that content is attached to a person rather than the other way around. A nice example of people-centric design.

SAP Jam documents are associated with a person's profile.

Editing In SharePoint Vs Editing In SAP Jam

At SAP we use both SharePoint and SAP Jam. SharePoint is used by the SuccessFactors product marketing teams to post content for field colleagues and partners. SAP Jam is used for sharing and conversations. Editing is SharePoint is very different from editing a page on Jam. Jam editing is WYSIWYG where as editing in SharePoint, while very strctured and robust, is not WYSIWYG.

WYSIWSG matters a lot for user engagement. I noticed that many of my colleagues just do the essential in SharePoint because it feels a bit like configuring a system rather than editing a page. SAP Jam on the other hand makes editing more like editing a document and thus improves user engagement. In fact it is so easy to set up an SAP Jam group for a topic that Jam groups are proliferating like rabbits everywhere. Sometimes I think there should a limit on the number of Jam groups a person is allowed to create.

The Edit screen in Jam feels like editing a Word document

IT Teams Play An Important Role In Procurement Of Cloud Software

I had a chance to talk to a group of new sales hires at SAP yesterday. One of them was Jeffrey Hutchinson, the former CIO of Maple Leaf Foods. Jeffrey was kind enough to share the perspective of the CIO and his or her role while an organization moves to the cloud.

He pointed out that while it was easier for the business to buy single cloud applications without the help of IT teams, it is not so simple to buy a more crucial application such as employee administration without the help of the IT team. I was discussing this with David Ludlow, the head of HCM solutions at SAP today and he pointed out that IT teams are more experienced in evaluating and buying business software compared to the business. While business teams evaluate functionality , IT teams are experienced in evaluation many aspects of business software such as total cost, security, integration, data migration and analytics.

I found out there are SAP customers who went ahead and bought critical cloud solutions without involving the IT team and could not implement it due to the lack of support from the IT team. Without the support of the IT team, they could not secure an implementation budget from the CFO.

As business critical applications move to the cloud, procurement of cloud software is certainly starting to look a bit more like procurement of on-premise software.

Ingredients And The Chef Make a Good Entree. The Oven Just Helps

Yesterday while I was discussing a customer's Journey to the Cloud with their HR IT team.  That customer, who has integrated their HR systems with about 20 business systems, pointed this out to me that the design of the integration and the content mapping are far more important than the middleware technology that handles the integrations. Middleware technology for an integration designer is like an oven for a chef. It is required and has to do its job. But it is not the main reason an integration brings value or causes problems.

Integrations do not normally fail because of middleware technology
An integration between two systems, say system A and system B,  might fail when one of the following things happen. It could break when System A was updated and some integration points do not send or receive the necessary information. It could break because System B was updated and some integration points do not send or receive the necessary information. The integration between two systems rarely break because the middleware technology handling the integration went through some change.

Lack of attention from project team is the main cause for failure
Integration also becomes an issue when project teams do not pay attention to it or do not keep time and money aside to address it. Unfortunately, software vendors sometimes mislead customers by saying either integration is not necessary or is so simple that they do not have to worry about it. In some cases vendors show a tool and say that the tool will solve all the integration problems. It is a bit like showing an oven to a group of aspiring chefs and saying that the oven is all they need to make great food.

I have been pointing this out to customers and have been urging them to pay more attention to integration content and the business value it brings for them. I have also been urging customers to keep time, money and more importantly mind share aside for the topic of integration for over a year now.

This has started paying off. Those customers who planned to address integration early in their projects completed their projects will a lot less stress compared to the ones that did not.

Accenture Audit and Compliance for Employee Central