Lessons Learned from an large-scale S/4HANA Transformation Project

In many recent customer conversations people asked me about the experiences and lessons Learned from my last S/4HANA project. A good indication that it is time to look back and that it’s worth to write an article about it.

Project Context

The customer, a large multi-national, has decided in 2016 to the transition to S/4HANA. His current environment with >150 partner systems (mainly upstream, but also downstream) was highly customized, but provided also high degree of automation.

The motivation for moving to S/4HANA were numerous:

• no harmonized finance process, which lead to challenges in consolidation
• project controlling was effort-intense and allowed only limited transparency on financial and operational real-time insights
• legacy system was seen as road blocker for the companies way to the cloud, but also to a new user experience (e.g. FIORI) and mobile device access
• S/4HANA was the only way to consume innovations like predictive accounting, Machine Learning & Artificial Intelligence, state-of-the-art-analytics

The project was launched with four objectives in mind:

• standardization – reads as: maximize the usage of built-in technology of S/4HANA
• simplification – reads as: leverage the benefits of the simplified S/4HANA data model
• acceleration – reads as: shortening process duration, due to obsolete reconciliation steps
• transparency – reads as: obtain central ownership of processes & holistic view on finance information

For decision making, planing and executing project activities the following principles were defined: Think new, think different, think lean, think global.

Approach to Move to S/4HANA

The project started with the idea to use SAP Central Finance, which is an S/4HANA side-car connecting to existing ERP systems and building the new world next to the current one. This approach was soon abandoned, due to considerable changes in the source systems, high complexity for interfacing & solution architecture. In a nutshell: the given context was not made for SAP Central Finance.

The decision was taken for new installation (greenfield) of an S/4HANA 1610 system, which was upgraded to 1709 (Support Pack 0) during the implementation face. Although officially supported by SAP, I do not recommend to define a fresh version (SP 00) as target release for productive use.

Next to S/4HANA

• a MDG system was build up, serving as the new central instance for master data
• a PI system as mandatory platform for all incoming and outgoing communication
• a GRC system for fraud management
• a FIORI Front End Server to deploy FIORI apps from all systems (more info)
• SAP Analytical Cloud for management reporting
• Solution Manager with Focused Build to support the agile implementation project

The project team was located centrally, which has been considered as a key success factor for the successful implementation.

As Project Methodology a tailored version of SAP Activate was chosen, which required also the change from the waterfall approach, which is well-known to the customer, towards an agile way of working. This transition was facilitated by agile coaches, which was of limited efficiency, due to lack of ERP (implementation) experience/knowledge on the coaches’ side.

The project phases were adopted from SAP Activate and were defined as preparation, exploration, realization, Deploy (Cut-Over) and Run. The realization phase itself was defined in 6 Waves each spanning over 8 weeks and containing 3 Sprints.

After a re-adjustment from Central Finance approach to a S/4HANA New Implementation the project duration from Preparation to Go-Live took 22 month.

Lessons Learned

Experiences were gathered from both aspects which went well and project elements, which are subject for reconsideration in future projects.

Lessons Learned on Strategic Level

• Sponsorship by senior management is indispensable to cope with project challenges
• Strong involvement of SAP has been key success factor a Take the time to define engagement model
• Commitment of stable joined core team more important than fine-tuning methodology
• Overall ERP-Strategy needs to be finished before starting the explore phase of an S/4HANA transformation and should not be subject to profound changes before Go-Live
• Program Management Office needs to be setup and equipped authority and C-Level sponsorship to align parallel ongoing projects and manage cross-project-resource

Lessons Learned on IT- & Project-Infrastructure

• Final landscape should be foreseen with project start (be it with partly virtual system)
• Upgrades during project should be carefully planned at project start with commitment to Go-Live release
• Although officially supported by SAP is is recommended to avoid Support Pack 0 of a product version as target release for productive use
• Concept of Best Practices and Model Companies should be understood and positioned correctly
• Project infrastructure (rooms, network capacity, system availability, cleaning staff) needs sufficient attentions to assure the efficiency of project team
• Creation of a Template needs to be subject to thorough management process, deciding what is part and part of the template, what can be adapted by template consumers, how should the template roll-out process should look like and how is the maintenance foreseen for the template

Lessons Learned on Project Management Level

• Signed Project Charter with Why, What, How, Who, When builds unquestionable basis for the project execution
• Setup of efficient Release Management and PMO is key for project success
• Open & honest communication (incl. early discussions of problems)
• Efficiently working Project Management Office is prerequisite for excellence in project communication and administrative project processes
• Managing of expectations is important in all areas, e.g. Methodology like Agile Way of, Working, Functional aspects of Solution, Technical aspects of Solution, Supporting Tools like Solution Manager with Focused Build, Scope of Premium Engagement Services
• New Technologies, Concepts & Development Paradigms have to be trained at project start to team members
• Escalated problems can be efficiently solved by defining a case manager driving the solution across project-sub-teams and organizational units
• Aim for strong commitment to project methodology based on intended added value for project execution & quality, instead of mixing two approaches, which possibly leads to dealing with challenges from both worlds.
• Transformation to Agile of Working is an evolutionary process, which might start by using agile terminology first
• Agile Coaches need to have experience with ERP-Implementations
• Agile Way of Working is not feasible w/o automatic testing (increasing efforts by Wave due to regression Testing)
• Agile Way of Working demands requires a solid concept of a Working Skeleton & incremental versions of Minimal Viable Products
• Prototyping (solutions, processes, Way of Working) allows early learnings & adjustment
• End to End Process definition key for Validation of completeness of scope, Test Management, Authorization concept
• Clear Development guidelines needed as from the start
• Maintain On-Boarding guide to allow project scalability also in late phases of the project
• Achievement of milestones should be celebrated together

Conclusions from this project

Team over Methodology

The project methodology has not been enhanced in all details, nor has it been executed rigidly. But the focus was on a strong&stable Collaboration/Teamwork at a central physical project location.

Sponsorship & Leadership over Rules

Rules were defined, communicated and frequently brought to attention, but were not enforced strictly. Instead a powerful Personal Leadership and Management Focus on Attention Points was applied.

Trust over Contractual Agreements

Most project partners were not monitored and managed in detail during. This was not due to lack of management, but of a developed trustful relationship and seeing that an advanced project needs degrees of freedom for project members

Commitment & Dedication over Role Descriptions

A Project Organization with roles has been put in place, but project members were not always strictly assigned to these roles, nor were these roles extensively defined. In turn (partly free-floating) key players developed and performed an extra degree of commitment and dedication.

Personal Contact over KPI

Nor the definition of project KPIs nor their measurement followed common project management standards. However even more attention has been invested in personal relationships and individual assessment & screening of critical project aspects.