Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
Showing results for 
Search instead for 
Did you mean: 
On Mon 27 Jan 2020, my organisation (Newcastle University) went live with S/4HANA 1709. Completing the project, itself part of a much larger programme of work, has been the culmination of several years of planning and a massive, concerted team effort.  The University has been an SAP customer since 1999, incidentally the year I joined. This blog post outlines our S/4HANA project scope (the 'what'), the business case and motivation behind our implementation (the 'why'), and the approach taken to deliver this project (the 'how'). Given there are not that many accounts written from a customer perspective, this is my attempt to distil our experiences into a resource I hope readers may find of interest.

This is part 1 of a three-part blog post series, covering The What aspect of Newcastle University's journey to SAP S/4HANA, looking at the project scope.

This post is broken down into the following sections: Project Summary | The Starting Point | Greenfield, Brownfield or Bluefield? | On-Premise or Cloud? | S/4HANA Target Version | S/4HANA Project and Programme Scope

Project Summary

Conscious there are so many aspects to an S/4HANA implementation project, this section lists the key facts below if you're only after the headlines.

  • Customer: Newcastle University, United Kingdom

  • Industry: Higher Education

  • SAP customer since: 1999

  • Source release: SAP ERP 6.0 EHP8

  • Target release implemented: S/4HANA 1709 SPS04

  • SAP systems integrated with S/4HANA:

    • SAP Customer Relationship Management (CRM) 7.0 EHP4

    • SAP Supplier Relationship Management (SRM) 7.0 EHP4

    • SAP Business Warehouse (BW) 7.5

    • SAP Portal 7.5

    • SAP Process Integration (PI) 7.5

    • SAP Gateway 7.5 (hub deployment)

  • Number of users: 6603 staff (1054 SAP GUI for Windows); 25590 students (via integrated web portals)

  • Deployment approach: brownfield (system conversion)

  • Project duration: 8 months (plus extensive discovery work prior)

  • System integrator: internal IT team of SAP specialists; validation by SAP

  • Project team size: 35 (SAP specialists); 150 (business users)

  • Number of trial system conversions: x7 (x5 Sandbox; x1 Development & x1 QA)

  • Number of S/4-related tickets logged with SAP (before go-live): 26

  • S/4HANA functional scope (horizontal):

    • Finance

    • Logistics

    • Sales

    • Procurement

    • Travel Management

    • Human Resources

    • Payroll

  • S/4HANA industry scope (vertical):

    • Human Resources (regulatory)

    • Student Lifecycle Management

  • Additional scope items:

    • HANA Hardware Replacement

    • Annual Updates (all SAP systems)

    • Funds Management Deactivation

  • Dependent projects within programme (go live date in brackets):

    • Accounts Payable Third Party System (WNS) Upgrade (Feb 2018)

    • SAP Information Lifecycle Management (ILM) Implementation (Oct 2019)

    • Legacy SAP ERP Landscape Track Enablement (Oct 2019)

    • Data Sync Tool (EPI-USE) Upgrade (Nov 2019)

    • Customer Vendor Integration (CVI) Conversion (Nov 2019)

    • Document Management (Netcall Liberty) Upgrade (Dec 2019)

    • SAP GUI 7.6 Upgrade (Jan 2020)

    • HR Sync Pack & Country Legal Changes (Mar 2020 - planned)

The Starting Point

Let me start with some context. Newcastle University has been a longstanding SAP customer. We went live with SAP R/3 (3.1H) in Apr 1999 starting with the Human Resources, Payroll, Logistics (Materials Management and Sales & Distribution) and Accounting (Financial Accounting, Controlling and Project System) modules. In the early 2000s, the University opted to be a customer pilot of Campus Management (now known as Student Lifecycle Management) with several other universities. This joint venture saw participating universities collaborate with SAP and one another to co-create the product we see today, though we have significantly extended the product to meet our business requirements. We upgraded our SAP R/3 system to SAP ERP in 2004. Other notable milestones which added to our SAP portfolio include the ECC Travel Management module (expenses), SAP Customer Relationship Management (prospect/student enquiries), SAP Supplier Relationship Management (procure to pay), and quite recently SuccessFactors (recruiting). Underpinning the Business Suite are a multitude of integrations supported by the NetWeaver Hub systems between SAP, third party systems and business partners.

Newcastle University's SAP landscape prior to S/4HANA go live

Starting in 2011, we introduced an annual SAP maintenance strategy, which we continue to follow to this day. The cumulative effect of routine maintenance, Unicode conversion and system upgrades, meant we were bang up-to-date from a landscape perspective. We had also migrated all of our SAP systems from Oracle to HANA in 2016, together with the set up of SAP Gateway to support the implementation of our first Fiori apps (we currently have seven apps live). I can't stress how valuable this foundation work was in helping to ease the path to S/4HANA, as a lot of heavy lifting had already been done. A cynic may argue we've only reached the starting line, as all the functional improvements (indicated with question mark in image below) are yet to be delivered. But taking this approach means we can now prioritise and deliver these improvements incrementally, at a measured pace, without the technical burden of the system conversion, this having been accomplished.

Managing complexity by phasing the transformation

Greenfield, Brownfield or Bluefield?

It’s fair to say the greenfield approach was alluring, after all, we had over 20 years of organic system growth, including a high degree of custom development; this would have been an opportunity pay off a large sum of technical debt in one fell swoop. But, once budgetary, resource and change management factors were considered, a brownfield system conversion was the most logical path for us. Much to our relief, statistics from SAP show the vast majority of existing SAP customers, especially long-standing ones, are opting for brownfield (83% of projects since 2018, source: UK & Ireland SAP User Group S/4HANA event). My argument is that this decision doesn’t preclude the eventual target destination being reached. Bluefield, the selective transformation of components of our ERP system to S/4HANA, made no sense, as we only had one SAP ERP system instance and we're moving HCM to SuccessFactors. We opted to treat our S/4HANA as a phased implementation, with phase 1 being an IT-led technical platform upgrade, with limited business impact, largely contained to the mandatory changes brought about by the Simplification Items in scope.

S/4HANA phased approach adopted

During phase 2, we plan to focus our attention on harnessing the new capabilities of S/4HANA, tackling the business process transformation bit by bit. I like to think of the analogy that our ERP system is a like a large shopping complex, where the malls (Line of Business units) are overhauled in a piecemeal fashion during business as usual operations. I thank Vishal Sikka and his seminal article on Timeless Software for that thought. Another benefit of phasing is that it provides the opportunity for project teams to upskill and ensure we follow SAP best practices, which pays long term dividends.

A risk we must mitigate against having followed the brownfield approach is to avoid the extensive customisations of the past. Yes, there may be legitimate gaps between our business requirements and the SAP standard product, but we will need to ensure these are addressed using SAP's recommended new extensibility approach in S/4HANA (e.g. favouring in-app or side-by-side extensions and avoid modifying the core).

Fortuitously, in early 2017 SAP released the openSAP course Find Your Path to SAP S/4HANA, which (stlll) offers a deep dive into route paths to S/4 and decision criteria to help customers determine what best suits their needs. This really helped as a primer to S/4HANA and gear us up during the discovery phase. Together with the guidance offered in the SAP Press book Migrating to SAP S/4HANA, the lever was tipped towards system conversion.

S/4HANA migration path decision criteria (source: openSAP & SAP Press)

I recall attending a UK & Ireland SAP User Group (UKISUG) Enterprise Architecture Special Interest Group event titled 'SAP S/4HANA: Evolution not Revolution'. Much of the emphasis was on incremental change and enabling customers to move at their own pace. With the passage of time, SAP has updated their guidance, the latest of which I gleaned in the following presentation slide, reaffirming our decision.

Recent SAP guidance (source: UKISUG S/4HANA event)

On-Premise or Cloud?

We opted to remain on-premise with our S/4HANA system and this is likely to be the case for the foreseeable future. Having purchased new HANA hardware in 2016 to support our Suite on HANA implementation, there was plenty of life left in the kit. While a public cloud Software as a Service (SaaS) version of S/4HANA was available as an option, our Student Lifecycle Management industry solution has not yet been built as a SaaS offering, as is the case with many of the vertical industry solutions. I've read articles indicating that S/4HANA only contains a fraction of the functionality currently available in SAP Business Suite. We haven't found this to be the case for functionality we use. Yes, we're conscious that some technical functionality is now in Compatibility Scope, which we must track to ensure we find successor solutions before the 2025 deadline, but functionally, the only significant application we use that isn't part of the S/4HANA core is Travel Management. We're hoping this moves out of Compatibility Scope in the next year or two, though Concur may be considered too. If not, we may need to find an alternative solution to the Fiori My Travel & Expenses app we have extended.

We discussed private and managed cloud (e.g. HANA Enterprise Cloud) but there was no compelling argument to make this a priority for the first project phase. Personally, my prediction is we'll move S/4HANA to the private cloud well before we move to a SaaS variant. Though SaaS is compelling, this is only if the glove fits. I'm a huge believer in progressive change, especially in a complex organisation such as a University. Smaller, manageable steps are lower risk, easier to encapsulate and deal with from both a complexity and change management perspective. With the number of route paths available, and ever-changing picture, I can see how many organisations find themselves suffering from analysis paralysis and getting stuck in a rut, adopting the 'wait and see' approach, but my belief is that in an increasingly fast-paced world, why not deliver incremental value and reap the benefits of compound returns? owen.pettiford3 does a great job of covering the various S/4HANA deployment options in this blog post.

S/4HANA Target Version

One of the dilemmas with long-running implementations such as S/4HANA is how to handle new major releases during the project. When we first started discussing S/4HANA the product had only just morphed from Simple Finance, with rumour that Simple Logistics was next, to a complete ERP offering in the shape of S/4HANA Enterprise Management 1610. We performed trial conversions with the 1610, 1709 and 1809 releases, finally settling on 1709 SPS04.

To meet our project schedule, we needed to lock in our target release in the early summer of 2019. While a tentative trial conversion and exploration of 1809 had not highlighted any problems, it carried risk. We had been bitten by numerous time-consuming issues with 1709 relating to the employee business partner conversion that had taken many months to resolve, despite SAP's highest attention. The 1709 release was maturing as it had advanced into Support Package Stacks only, rather than 1809 which still had another Feature Package Stack (2) due for release. While there were some potentially welcome enhancements in 1809, we decided that 1709 was the pragmatic option; after all the target was a successful technical platform conversion, we could always uplift the release version during phase 2, in the business process re-engineering phase.

S/4HANA version and package level planning

S/4HANA Project and Programme Scope

In addition to our S/4HANA conversion, we also included a maintenance exercise on all other SAP systems in our landscape. This ensured we would be up-to-date at the point of go live. As there were no enhancement packages available for any of the other SAP systems (besides S/4HANA), this exercise amounted to a support package only update. The SAP Frontend (Gateway) Server, was uplifted from version 2.0 to 4.0 supporting the move from Fiori 1.0 to 2.0, that is obligatory with the move to S/4HANA.

Technical source vs target project scope

Given the simplifications in S/4HANA 1709 only impacted the finance and logistics database tables we use, the vast majority of the Simplification Items were finance-related, details of which are covered in more depth in part 3 of this blog post series. Consequently, the IT and business impact was weighted towards the teams supporting finance business processes.

While the end goal with a move to S/4HANA is to simplify and enhance business processes via the available Fiori apps, our strategy was to minimise business impact during phase 1 to mandatory changes only. Phase 2 would be our opportunity to holistically look at user needs and leverage new S/4HANA capabilities.

When we started planning our S/4HANA project, we didn't envisage having to track so many dependent projects, as per list below (go live date in brackets):

  • Accounts Payable Third Party System (WNS) Upgrade (Feb 2018)

    • This solution was installed an an add-on to our SAP ERP ABAP stack. An upgrade was needed to make it S/4HANA compliant and rectify a number of rendering issues with the SAP GUI Belize Theme.

  • Data Sync Tool (EPI-USE) Patching & Upgrade (May 2019)

    • We were advised to upgrade the Data Sync Manager tool we use for cloning employee personnel records from Production to Test systems, in readiness for S/4HANA. After impact assessment, EPI-USE were able to provide a patch to obtain S/4HANA compliance, which we opted for. The intention is still to upgrade the tool as soon as possible but deferring the upgrade avoided unnecessary project pressure.

  • SAP Information Lifecycle Management (ILM) Implementation (Oct 2019)

    • We had implemented and configured ILM against our SAP ERP system, with a large volume of transports sat in our QA environment at the start of our S/4HANA project. We needed to check the ILM functionality was S/4HANA compliant then accelerate the push of these changes to Production, as backing them out was not feasible given the complexity.

  • Legacy SAP ERP Landscape Track Enablement (Oct 2019)

    • For many years we had managed to deliver annual maintenance exercises using our four tier SAP landscape: Sandbox (known internally as Impact Analysis); Development, QA & Production. Sandbox was used to assess the impact before we committed to a project schedule for the phasing through to Production. Due to the significant nature of the data model changes in S/4HANA, we couldn't risk managing this move with a single track landscape.

  • Customer Vendor Integration (CVI) Conversion (Nov 2019)

    • As per SAP recommendations, CVI conversion can be tackled ahead of S/4HANA, which we decided to do.

  • Document Management (Netcall Liberty) Upgrade (Dec 2019)

    • While this upgrade was not essential from an S/4HANA compliance perspective, it was needed to remain within vendor support, hence needed to be delivered ahead of S/4HANA go live.

  • Solution Manager 7.2 Support Backbone Enablement (Dec 2019)

    • We had already upgraded to Solution Manager 7.2 some time before the S/4HANA project started, but in order to support the Connectivity to SAP's Support Backbone, we updated our Solution Manager system to SP09 and addressed all the requirements in the preparation checklist.

  • SAP GUI 7.6 Upgrade (Jan 2020)

    • We were running SAP GUI 7.5 with SAP ERP, but with maintenance ceasing after 31 Mar 2020, we upgraded all University PCs to SAP GUI 7.6 before S/4HANA go live. Upon SAP GUI 7.6 roll out, the default theme was set to Blue Crystal. At S/4HANA go live, this was switched to Belize Theme.

  • HR Sync Pack & Country Legal Changes (CLC) (Mar 2020)

    • We normally bind in the HR Sync Pack update with our annual SAP maintenance exercise. However, in the case of S/4HANA, user testing started much earlier so we confirmed there were no dependencies between the HR Sync Pack and S/4HANA software components, so we could defer the combined HR Sync Pack and CLC updates until post S/4HANA go live. We plan to implement these changes through our landscape in the next few months, going live in March ahead of the tax year end.

Just as I was finishing writing this blog post, I spotted the following tweet by appleby, which got me thinking, how big is the SAP resource squeeze going to be? This article - Wake up and smell the SAP roses before it's too late ... - paints a pretty bleak picture. And what are customers doing to mitigate the risk? Rimini Street claim from a recent survey they carried out (148 respondents in North America) that the majority of SAP customers are choosing to disconnect from SAP's maintenance support deadline. Please let me know your thoughts in the comments section below. It would also be great to hear what approach other customers are taking too.

This is part 1 of a three-part blog post series:

Thanks for reading!