What SAP Consulting OnDemand Onboarding Service Descriptions tell us about hybrid integration scenarios

In my last two blogs analyzing SAP’s OnDemand offerings, I focused on a new data source – “legal documents from SAP”. I started with Terms of Service and moved on to License Agreements, I’d like to end the series with an analysis of Consulting Onboarding Service Descriptions which describe all the available standard Cloud Consulting Services for various SAP OnDemand Services.

The goal of these services is always the same – here is an example from the Social Customer Engagement OnDemand solution:

With the “Standard Onboarding Service” SAP plans and executes the majority of activities required to provide a production-ready SAP Social Customer Engagement OnDemand solution. Customer supports SAP during the Project and is responsible for specific activities as outlined below. The Project includes the phases “Prepare” and “System Settings & Enablement”. Customer executes the phase “Go-Live” after the completion of the Standard Onboarding Service.

The overall structure of all the Descriptions is similar and reflects typical consulting offers – regardless of whether SAP implementation projects or SaaS. There is a definition of the deliverables, the respective project roles (from SAP and the customer) and the responsibilities of these roles.

Here is an example of the deliverables for one such project taken from the Travel OnDemand description.

Note: These documents are publically available despite their designation as “SAP Confidential”.

These descriptions are available for the following offerings:

• Carbon Impact
• Sales OnDemand
• SAP Social Customer Engagement
• SAP Social Media Analytics by NetBase
• Sourcing OnDemand
• Travel OnDemand

What is missing?

My first impression when viewing this list of consulting descriptions was: why were there so few? If customers find such agreements useful, I’d expect to find the descriptions associated with other OnDemand SAP offerings as well. What about Business ByDesign? What about SuccessFactors? What makes these offerings so different that they aren’t included in this list? There are obviously consulting efforts involved for these offerings as well. Are the consulting efforts involved for these offerings so customer-specific that a standardized offering isn’t possible?

On the site with the service descriptions, there are also no OnBoarding agreements for OnPremise implementation offers.  SAP Consulting and partners obviously participate in such offers. Why aren’t they listed here? Perhaps, this absence is based on the fact that such standardized offerings are impossible in OnPremise environments based on the high degree of customer customization that often takes place there. The fact that SAP’s OnDemand offerings are more limited in scope than its OnPremise offerings might also make such offers easier to define.

The importance of integration in hybrid environments

A recent blog by Larry Dignan describes the difficulty of integration involved in the hybrid environment (OnDemand/OnPremise) necessary for Oracle Fusion apps:

a blog post from Oracle’s development team indicates that this on-premise-cloud nirvana could be complicated. I’m not going to pretend to understand what Oracle has outlined, but the integration caveats indicate that there’s real integration work ahead. Perhaps the post is designed for early adopters, but you’d think there would be connections embedded by Oracle between the on-premise and cloud worlds.

This ZDNet blog demonstrates that hybrid environments don’t necessarily work out-of-the-box and usually require some degree of consulting effort to get working.

A recent analysis of the Workday S1 for its IPO suggests that Oracle isn’t alone in requiring integration services for such offerings

Interestingly almost 1/3 of Workday’s revenue is coming from professional services, showing how Workday’s “Apple Strategy” (delivering a very tightly integrated, somewhat closed system) is forcing the company to spend a lot of money on integration services. These systems are very complex to implement (the clients I talked with told me it often takes a few years to fully implement) and they must interconnect with many other enterprise systems. Workday is working closely with Deloitte, Accenture, and others to build a strong ecosystem of implementation partners. [SOURCE]

In the OnBoarding descriptions from SAP, the necessity of integration efforts is depicted openly.  For example for Sales OnDemand, there are three types of consulting services offered:

Sales OnDemand has two possible integration points and both are included in the list of deliverables:

• Point to point Integration of SAP Cloud solution with SAP ERP or CRM On Premise system
• Integration of SAP Cloud solution with PI OnDemand or PI OnPremise

This integration is only possible with the “Extended Integration” service.

One important difference between the Oracle integration efforts described by Dignan and those described by SAP is the fact that SAP doesn’t try and hide the necessary integration steps. Indeed, there are Integration Guides (such as the SAP Sourcing OnDemand Solution integration guide) available for many of these solutions.

It is also important to note that some of the OnDemand solutions with OnBoarding services don’t require integration efforts (such as “Social Media Analytics by NetBase OnDemand” or “Carbon Impact”).

Customer role in integration in hybrid environments

As Dignan’s blog suggests, Oracle pushes most of the responsibility on to the customer to assure that this integration works correctly.

I was curious to see how SAP regarded the role of the customer in such efforts. The language regarding the integration work in such descriptions are interesting in that the services include the “planning and coordination” of integration activities but not the actual implementation of these changes.  For example, the detailed description of tasks for the Extended Integration Service for Sales OnDemand shows this division of labor:

SAP Tasks:

• Perform the configuration marked as relevant to SAP Sales OnDemand Solution
• Assist customer in configuration of master data integration and standard process integration on the Customer on-premise SAP system
• Assist customer in configuration of SAP NetWeaver Process Integration (if required as documented in SAP
• Sales OnDemand Solution integration guide)
• Assist customer in configuration of File Transfer Protocol (FTP) (if required as documented in the SAP SalesOnDemand Solution integration guide)
• Assist customer in Master Data Integration as documented in SAP Sales OnDemand Solution integrationguide
• Provide pre-defined test scenarios

Customer Tasks:

• Specify in detail the integration requirements in the Service Specification Document (SSD) or questionnaire provided
• Install required system add-ons and required SAP correction notes in the Customer on-premise SAP system
• Perform tasks listed in the SAP Sales OnDemand Solution integration guide with assistance from SAP;  these are all sections marked as relevant to “Customer on-premise SAP system”, “FTP”, “SAP NetWeaver Process Integration” (SAP NetWeaver PI) and “Master Data Integration” in the SAP Sales OnDemand Solution integration guide
• Set up connectivity and security settings in the Customer on-premise SAP system and provide SAP authorization to perform relevant tasks for the service delivery
• Provide master data for data import, ensure correctness and suitable format of the data, and perform the data upload into SAP Sales OnDemand Solution with assistance from SAP
• Address/verify/confirm all aspects of Customer on-premise network and system security
• Test and approve the end-to-end integration scenarios

The SAP consultants “assist” and the customer “performs” and “installs”.  

Memories of RDS

In a recent blog about RDS and its impact on consulting, Mark Chalfen makes an interesting statement:

The biggest concern I have with the new methodology is how changes are managed. The RDS is fixed price, scope and time. Any change to the scope will impact the price and time of the project. Customers will be used to Partners allowing them to make changes, prior to the Blueprint, and squeezing in changes by keeping the timeframe. Customers and consultants need to learn the scope of the RDS as this is the legal requirement. It is similar to a consultant sticking to the scope defined in the Blueprint, but the biggest challenge will be the customer not asking for additional changes.

In OnDemand environments where standardization is also a key to assure low costs and increased efficiency (for example, during software updates), customers must also learn that additional changes beyond the existing offered services are not possible / difficult to implement.

Both RDS and SaaS lead to new interpretations of the roles and responsibilities for consultants in such projects. Based on this connection, Jon Reed’s analysis of the changes necessary for SaaS consultants might be interesting for those consultants wishing to move into RDS.

Conclusion

There has been a great deal of attention paid to Business ByDesign partners and, indeed, SAP is active getting this ecosystem up and running (via certification, etc). The presence of the OnBoarding Consulting agreements described in this blog demonstrate that there are consulting opportunities for other SAP OnDemand offerings as well.  Currently, however, it appears as if SAP has dominated this market.

If you look at SuccessFactors with its longer track record, there is already a flourishing partner ecosystem. I’m optimistic that over time other SIs will also be able and willing to provide such OnBoarding services for other OnDemand offerings besides SuccessFactors and ByDesign.  This decision necessitates a degree of stability in SAP’s OnDemand strategy in order for such SIs to be able to justify the investment in training, marketing, etc.  The recent changes and resulting uncertainty in SAP’s Cloud strategy might be one reason that more companies haven’t been more active in such consulting areas.