Let’s not forget integration
One of the most important characteristics of S/4HANA is a simplified / unified database that is used by a variety of applications which previously had separate databases. The idea of “one truth” provides a variety of advantages for customers – reduced data replication, reduced duplication, etc.
The idea of “one truth” for the entire S/4HANA offering, however, is not entirely true. S/4HANA is not a 1:1 copy of existing OnPremise applications that will be “simplified / evolved”. There will also be some replacements that enable SAP to take full advantage of its acquired cloud assets. The acquired cloud applications are separate SaaS entities that do not share a common database – thus, integration will be necessary.
In his excellent FAQ on S/4HANA, John Appleby suggests an initial set of S/4HANA offers that illustrates this mixture of old and new assets.
In the quarterly releases starting in Q1 2015, there are three initial options:
- Finance: Simple Finance
- Professional Services: Project Systems, Fieldglass, Employee Central
- Sales: Simple Finance, Hybris, Cloud for Customer
Note: Appleby’s list of options is pretty clean but I’ve seen other references regarding what is going to be offered in initial releases and these descriptions are much broader. For example, “The S/4Hana Public Cloud offering, including finance, logistics, inventory management, sales, distribution, procurement, materials management, and other simplified apps, will be available in February” [SOURCE].
Note: Even the recently-gained ability of SuccessFactors applications to run on HANA doesn’t help things since I assume that the data structures of such SF applications have yet to be simplified / optimized (a similar problem to that of ByDesign).
Despite its importance, there has been very little attention paid to this area besides a few cursory remarks. What might customers expect regarding this important topic? I assume that HANA Cloud Integration (HCI) (which runs on the HANA Cloud Platform (HCP)) will play a critical role here in bridging these applications. Perhaps, it will be possible to reuse the existing HCI content packages (for example, packages concerned with SuccessFactors Talent Management) for S/4HANA integration requirements.
Note: Since one future deployment option of S/4HANA will be OnPremise, integration will still play an important role in such scenarios since you will have pure SaaS applications like Employee Central that are part of S/4HANA integrating with OnPremise-based S/4HANA assets.
One advantage of maintaining the fundamental ABAP technological architecture from the OnPremise world is that existing Rapid Deployment Solutions (RDS) offers will probably be able to be reused to meet some integration activities. In the Public Cloud version of S/4HANA, the use of such RDS packages should be particularly efficient since SAP can install such “content” without having to worry about conflicts based on customers’ customization as is the case in many OnPremise environments.
Although the initial version of S/4HANA will be in the Public Cloud, the necessity of integrating with OnPremise assets isn’t going to disappear. The ability to run in a hybrid environment is critical for customers which haven’t moved all their ERP modules to the cloud. This requirement is also evident in first customer to use SimpleFinance (although it is unclear whether a deployment on SAP’s Managed Cloud or in the Public Cloud is planned):
Through integration with the existing SAP ERP Human Capital Management solution and other ERP applications from SAP, La Trobe staff now use a single source of the truth and no longer need to recreate data in disparate systems or dump validated data into spreadsheets for reporting. [SOURCE]
Since such hybrid integrations involve OnPremise assets from customers that may be highly customized, the involved efforts may be expensive based on their complexity.
The distant cousin – Business ByDesign
It appears that parts of S4/HANA offering are influenced by the ByDesign product. Here I am thinking in particular of the Guided Configuration demoed by Bernd Leukert at the launch.
Regardless of the degree of reuse concerning ByDesign technology/experience, a mildly derogatory attitude regarding Business ByDesign in some of the S/4HANA-related material/PR activities was a bit undeserved. For example, Hasso Plattner talking about ByDesign:
Business ByDesign, a product aimed at smaller companies, hasn’t gained significant traction. Plattner called it “either too ambitious or too conservative — probably both.”
One reason for Business ByDesign’s weak reception, he argues, is that “we should have simplified [its] database, and we didn’t.” That led to the development work that ultimately culminated in HANA and Tuesday’s launch.
The underlying data model behind the two offerings appears to be different but both ByDesign and S/4HANA share a variety of common characteristics / bonds (for example, HANA, ABAP, etc) – they are related to one another at various levels.
ByDesign just went through an extensive re-architecting based on HANA and this interview with Pradeep Nair (Director of ByDesign Development) describes familiar patterns seen in S/4HANA like leveraging HANA’s native capabilities, etc. Despite their differences, it would be unwise to ignore the experience / lessons learned from the ByDesign team.
Searching for S/4HANA extensions
One of the most important incentives for SAP to move customers to the Public Cloud version of S/4HANA is a return to more standardized environments. This characteristic allows SAP to provide customers with the typical benefits of SaaS deployments (rapid innovation, easier software upgrades, etc.) Customization, however, isn’t expected to disappear entirely but will shift to a different environment – the HANA Cloud Platform (HCP). Some customizations inherited from OnPremise applications may no longer necessary (legacy code that hasn’t used in years, etc) and shouldn’t be moved to the new S/4HANA environment but some customization will probably remain inasmuch as it may include process optimization that represents a company’s differentiator in their market. Fellow Diginomica blogger Brian Sommer includes a few questions related to migration in his list of S/4HANA-related questions but doesn’t really focus on how customizations will be migrated.
A recent blog from fellow SAP Mentor Owen Pettiford includes an excellent graphic representation of level of / characterization of customization in the different S/4HANA variations.
S4HANA Extensions running on HCP will replace the customizations / modifications present in the OnPremise world.
HCP is the defined platform for most extensions, yet the only extensions that I have ever seen are those for SuccessFactors (for example, Accenture’s Human Capital Management Audit and Compliance Software) and Jam. The SF-specific integration is relatively mature (it was released in Oct. 2013) and exploits a variety of technologies in HCP such as the HANA Cloud Portal. Furthermore, HCP recent releases have added functionality specifically to enhance this integration type (for example, using SuccessFactors as the role provider for extension applications).
S/4HANA extensions are more complex in scope than these SuccessFactors extensions and my expectation is that a similar level of maturity will require a few years to achieve. Not only is the required technological maturity in the platform not present (no S/4HANA-specific tools / methodologies) but also the experience of the SAP ecosystem in such HCP-associated transitions is still nascent.
Note: There are various generic tools (Cloud Connector, etc) in HCP that exist that could provide the foundation for such extensions but nothing S4/HANA-specific.
The migration of tightly-integrated ABAP-based customized business logic that currently resides in existing Business Suite environments to a platform where ABAP is not natively supported is also a non-trivial endeavor.
Considering that some form of the Public Cloud version of S/4HANA will be released soon (H1 2015), the absence of any detailed information about S/4HANA extensions doesn’t bode well for customers or SIs.
This lack of maturity threatens the smooth transition of existing OnPremise customers to the Public Cloud model. Since customers won’t be able to easily move their existing customizations to HCP, they may be forced to consider a move to a S/4HANA deployment in the HEC / private cloud (release planned for May) rather than the Public Cloud. This environment is probably associated with increased costs and isn’t the initial focus of SAP’s efforts in this area but does provide more flexibility regarding customization.
Note: S4Extensions must be distinguished from Fiori-related functionality since such extensions focus more on business logic than UI. The role of HCP regarding Fiori apps for S4HANA is still unknown but I assume that Fiori-as-a-Service will be used.
- As demonstrated though the use of Hybris, FieldGlass and other SAP cloud acquisitions, S/4HANA includes more than just traditional ERP/Business Suite modules.
- For many existing customers (as seen in the response from the DSAG ), the main questions concerning S/4HANA, however, revolve around the transition of these traditional ERP scenarios to the new platform and the financial impact of this evolution.
- The role of S/4HANA in future innovations (for example, IoT) is less prominent in such discussions. At a time where Cloud ERP may be moving towards becoming a commodity, SAP must avoid the “race to bottom” often associated with IaaS environments and present customers with a plausible long-term story that expands beyond the generic benefits of SaaS usage.
- SAP must depict what comes after the initial Public Cloud deployment with its lower costs and lightning-fast analytics.
- Exploiting the cloud acquisitions in S/4HANA in new and inventive ways is one way for SAP to show its broader potential but the associated ecosystem must provide more than just supportive quotes, it must also be enabled so that it adapts to the new environment providing customers with visionary applications (industry-specific, etc) that were previously thought impossible.