The last few weeks have been a steady stream of S/4 learning for me. TechEd in Barcelona was understandably heavy in S/4 content, but I also attended our sister company G3G’s Vibe event, where S/4 topics were brought to the fore, and then our own User Group events in Manchester and the Netherlands. This – combined with talking internally to various colleagues around our own S/4 capabilities, and where our IP and technology can help – also made me realise something which I suspect is replicated in SAP user organisations:
Project type is in the eye of the beholder
Through functional eyes
People from a functional background tend to focus on the required business process changes. Even for an organisation wanting to go through the simplest, quickest, cheapest S/4 project, there may be significant work to do as a result of changes to the supported functionality. Someone working in that functional space, close to the business themselves, will focus on the work that needs to be done. There are several pre-steps to handle, including the Customer Vendor Integration (CVI) where Business Partner records have to be generated for any Customer or Vendor master in the system. The SAP readiness checks and the simplification list will also highlight business process changes required; an example from G3G’s own internal SAP system being the SD Revenue recognition functionality they use no longer being available on the latest S/4 versions. So as part of the project they would have to implement revenue recognition in Accounting instead. With GTS, EWM and some SRM, CRM and Analytics functionality being absorbed back into S/4, there will be other areas of functionality that are discontinued in favour of the absorbed processes. From the functional viewpoint, this is also the opportunity to improve the system by rolling out some of the new functionality. At the G3G session, the keynote by CEO Chris Gunther urged organisations to innovate and use this as an opportunity to drive their business forward in the ever more challenging markets in which they trade.
There will also be a fair amount of data quality work required; one partner mentioned to me that they had to help an organisation resolve issues with documents referencing cost centres that weren’t in the system. Again, for a functional eye, this could be the opportunity to go beyond just the required and actually cleanse and improve the data, and even introduce more data governance.
And then of course there is the UI. Long derided as a big drawback of SAP, the SAP GUI is being pushed to the back in favour of Fiori. So however the project goes ahead, there will need to be changes to business processes and documentation since the users will now be going through smaller role-based Fiori apps, rather than the large multi-faceted SAP GUI transactions. I learned from Andrew Borressen, CTO at G3G, that there are now ‘Lighthouse Fiori Apps’ which are the ones SAP are seeing as the most useful and important to adopt, thus helping customers see the wood from the trees, with so many Fiori apps available to install.
Through the technical eye
A good many of my senior colleagues within EPI-USE Labs came from a Basis/Platform background. EPI-USE Labs has already provided the technical work on several S/4 brownfield projects. When discussing S/4 with the aforementioned people, their view is that S/4, like many upgrades before, is a mandatory technical project. For 99% of customers, the current system is not running on Linux and the HANA Database. So an OS/DB replatforming exercise is essential. Also, for almost all customers, the current hardware they have is unlikely to be powerful enough to run HANA, and even if it is, may not have the right configuration to be able to go through the TDI process of certifying hardware for HANA themselves (the alternative to buying prepackaged appliances). So this project becomes a question of cloud adoption – either completely or hybrid. And then there are the decisions around private cloud vs Hyperscaler. But of course this isn’t a simple replatforming or move from Oracle to MSSQL; there is a fundamental change in the architecture of the database, so the sizing becomes a much more complicated discussion.
In some of the SAP sessions at TechEd, they did seem to downplay or skip past the rather crucial hardware migration. This part, which is being underestimated by the functional part, is blinding the technical viewer from all else.
The truth? Somewhere in the middle
It is my assertion that this same differing view of what S/4 is may be holding customers back on their journey too. By the time the functional side has put together their business case, the IT team is already feeling excluded and confused as to why no-one has asked for their input on the hardware and replatforming activities. ‘Are they going to a hyperscaler or a fully managed system?’.
Or where the IT department has taken the lead and tried to build a business case, the functional teams block it because of the impact on the business. Such massive process changes have to be planned around other business events and disruptions.
In their excellent report, ‘Mapping Your Journey to SAP S/4HANA® A Practical Guide for Senior IT Leadership’, the DSAG and ASUG highlighted that typically a Greenfield S/4 project is driven by the business and a Brownfield project by IT, and anyone finding themselves swimming against that may have their work cut out. But actually I would argue that even the Brownfield project needs to get buy-in from the business/functional side from the outset. Perhaps even getting them involved as early as trying to decide whether to go Greenfield or Brownfield, because they will still be needed early in the project in either case.
Licensing options will also be an essential part of the business case, since S/4 is a new license. The exact licenses needed depends on both the functional changes that will form part of the proposed project and the hardware decisions made by the technical teams.
See it all clearly through PRISM
I’m laying the challenge down to my colleagues to see how we can help organisations get everyone at each of our customers together on the same page as quickly as possible. Our S/4 Assessment report will act as an early warning of major functional roadblocks for a particular system, while also bringing in the replatforming implications, and assist with the sizing options for different cloud or on-premise choices. This will give an organisation a single vantage point through our PRISM platform, so the whole organisation can work together openly, and understand each others’ likely levels of effort involved in the different journey options. This is not to replace the SAP readiness check, which with version 2.0 looks like a big improvement, but rather to know the relative size of the challenges and benchmark them against other SAP customers before spending a single cent.
And of course, we can help with technical shortcuts...watch this space on that topic.
GET INSTANT UPDATES...SUBSCRIBE TO THIS BLOG:
Get email updates as soon as a new blog post is published. Read more fascinating blog posts by subscribing to this blog on the right-hand panel of this page.
Leave a Comment: