The value of a Solution Standardization Board (SSB) as part of implementing SAP S/4HANA Cloud, extended edition.

[andremalan]

Implementing SAP S/4HANA Cloud, extended edition with the Solution Standardization Board

 

Implementing an ERP system can be stressful, and much of this stress is related to the management of new information. An example of this, is finalizing client scope or evaluating options in order to future-proof a solution. Prudent management of new information turns questions into answers and reduces stress levels by providing a level of secure knowledge, from which to lead the project team. This process of turning questions into answers is driven by the Systems Integration (SI) Project Manager (PM) and is contained within the delivery methodology and its related artefacts and accelerators.

In the case of the SAP S/4HANA Cloud, extended edition, the SAP Activate Methodology makes use of a specific accelerator that was specifically introduced for this cloud solution, namely the Solution Standardization Board (SSB). This artefact helps to reduce project stress, by assisting in the management of information related to the future-proofing of the client solution, which it does, by ensuring transparency of deviations from the standard (the fifth golden rule for implementing SAP S/4HANA with a cloud mindset.)

On an SAP S/4HANA Cloud, extended edition project, the focus is on implementing a (largely) standard version of SAP S/4HANA, using a pre-configured or template solution (e.g. enterprise management layer), that relates to the client industry. Within such a project, the SSB oversees compliance with the 5 Golden Rules for implementing SAP S/4HANA with a cloud mindset, by considering and approving developments and modifications that deviate from these rules.

On a recent project in South Africa, a pharmaceutical logistics company chose to implement SAP S/4HANA Cloud, extended edition alongside Cloud Process Integration (CPI), Service Cloud, Portal and SAP Analytics Cloud (SAC) /Data Warehouse Cloud (DWC), with key integration to third party logistics partners (3PL) and to a 3^rd party Warehouse Management System (WMS) that uses antiquated integration techniques. With SAP S/4HANA Cloud, extended edition at the heart of the solution, and frequent upgrades as part of the post go-live landscape, the SSB has the important role of overseeing compliance with the 5 Golden Rules and approving developments and modifications deviating from these rules. By setting up and running the SSB, the project team took a proactive step towards future-proofing the organization, by ensuring that regular upgrades of the client systems can be performed with minimal issues.

As the project manager for implementing SAP S/4HANA Cloud, extended edition in this diverse landscape, I would like to share my experience of setting up and managing an SSB for this South African pharmaceutical distributor.

Establishment of an SSB

Most of the SI and client project teams were in technology and process shock by the time we started investigating the use of an SSB. The SI team had not done a cloud-centric implementation before and the client had not ever implemented a cloud or ERP solution and had been using a legacy system maintained by on-site support for the last decade. The change to an agile and cloud mindset was slowing project progress down and the last thing we needed, was another device that could slow us down further.

After evaluation of SSB benefits with the SAP Cloud Customer Care team, it was agreed with the client PM, that the benefits were important enough for us to proceed with SSB establishment. As the SI PM, I took responsibility for establishing the SSB (with the support of the client PM and under oversight of the project Steering Committee.)

In order to get up to speed quickly we utilized the standard SAP Activate SSB artefacts (that had recently become available) and used the suggested process without major deviation. As a project team we had only become aware of an SSB towards the end of the Explore phase, so we unfortunately did not have the benefit of the SSB to guide decision making during Prepare and most of the Explore phase, which affected our Explore phase outcome in two major ways: (1) the project teams were not used to organized oversight of their implementation of the 5 Golden Rules and (2) the client had chosen to avoid Agile techniques up to that point, which led to delays in finalization of the Explore phase deliverables. The latter item required much management and persuasion and caused a knock-on effect, of placing the project team under time-pressure during the Realize phase.

The SSB’s weekly cadence of compliance review and discussion, facilitated the necessary change in thinking and behavior over a period of around 2 months, after which the project team had become more aligned with both cloud and agile thinking. Being co-chaired by the Client and SI PM’s, with standing and topic-related participants, allowed specific items to be discussed until alignment was achieved, after which both PM’s could drive the behavior out in their respective teams.

SSB Process

Other than alignment on cloud and agile thinking, our key achievement in terms of SSB, was to formalize alignment with the extensibility requirements for a SAP S/4HANA, extended edition  project. During the weekly meetings, the extensibility rating of each proposed development, enhancement, workflows, forms and integration item was reviewed and approved, after discussion. In the Extensibility Guide, for each scenario, the possible extension techniques are listed and classified as either green (possible in all SAP S/4HANA solutions), amber (allowed in SAP S/4 HANA Cloud, extended edition) or red (not allowed in SAP S/4HANA Cloud, extended edition.) Apart from taking the pain out of future upgrades, it also helps the customer replace deviations with standard capabilities if they are offered in the future.

On a weekly basis the SSB evaluated the various requests by project teams, discussing alternatives and risks associated with the various options, based on the approved list of functional deviations from the standard solution. On a monthly basis, the results of the SSB meeting were communicated to the Steering Committee.

At the time of writing this blog, 19 amber deviations had been approved, out of a total of 115 deviations. The project team had managed to avoid any red deviations, other than (1) not having followed an agile process during the Explore phase and (2) one functional deviation which is aligned with a specific SAP Note. The former was somewhat remedied by following an agile approach during the Realize phase, which translated into 7 sprints of two weeks duration each, followed by 2 rounds of Systems Integration Testing. The fact that there is only one red functional deviation, means that the client will only have one specific functional area to monitor during the frequent upgrades related to their chosen cloud solution.

Conclusion and lessons learnt

An SSB cannot be considered an optional artefact, when implementing SAP S/4HANA Cloud, extended edition. It increases project confidence and ensures client buy-in to the overall solution, by providing a means for managing information related to compliance with the 5 Golden Rules. It enables enforcement of a cloud mindset and ensures a defendable architectural and technical design position, by involving the correct stakeholders when making decisions relating to deviations from standard.

As an early implementer of SAP S/4HANA Cloud, extended edition, our main lesson learnt, is that we would have benefitted from implementing the SSB process earlier in the project life cycle.