Reasons not to Move to S/4 HANA

As we know, SAP will not be happy until every one of their customers have moved to S/4 HANA, preferably in the cloud.

The PR people keep saying that S/4 HANA is being adopted faster than any other product in SAP’s history and that may be so, but the giant pink elephant in the room is that if (at TECHED for example) the presenter asks for a show of hands as to which organisation is on what release of SAP they are shocked and disappointed to find out just how many are still on older releases. Some are still on 4.6C.

If it is so good, why hasn’t everyone dropped every other project and moved to adopt S/4 HANA like they were buying a hot cake?

In this blog I will try and be as objective as I can and list the pros and cons of moving to S/4 HANA. I have not written a blog for over six months, as I have been working on the third edition of my ABAP book which comes out in the first quarter of 2019. I cannot plug it any more than that, as that would break SAP Community rules.

I will try and be as structured as I can, but most likely I will end up with a “stream of consciousness” approach where I just write whatever pops into my head at any given instant. I will also invite some celebrities who are experts in SAP technology to clear up various areas of confusion.

Barbara Streisand on “The Way We Were”

Hello, Barbara Streisand here. As you all know for a long time there was a new version of SAP out almost every year and most companies would run a given version for about five or six years before upgrading to a new version. I am woman in love with that concept because in those days when you upgraded all the new functionality was active automatically. Then one day SAP decided that, even though I said “Don’t Rain on My Parade” they did just that and stopped releasing new versions, instead they sent in the clowns who said “No more new versions (enough is enough) and introduced the “Enhancement Pack” concept.

You Don’t Turn Me On

With enhancement packs the new functionality did not get activated automatically. Instead you had to manually switch on what you wanted. The ABAP stuff got switched on at once, that had to be the case as everything else depended on it. So it could be argued that installing enhancement packs helped ABAP developers more than the functional people (and the business!) as they got an instant benefit with every EHP installation. In could be argued that ABAP developers help the business as well, so if you favour a “build” approach then installing an EHP was good thing, and if you favour a “buy” approach then installing an EHP was also a good thing (if you switched the new functions on).

Note that adding an EHP was not supposed to be an “upgrade” but in reality it was 100% as much effort as the former upgrades as you still had to test everything. The technical bit of an upgrade was never the hard bit, it was the regression testing. Also as far as my experience has shown, you ended up doing a technical upgrade (i.e. did not switch anything new on) and thus did just as much testing as for an old fashioned upgrade, but without getting any new features!

It was difficult enough getting companies to use the new features when they were on by default, let alone when they are dormant and you have to switch them on manually. Moreover the “let us do a technical upgrade we will switch on the new stuff later” runs into the “later means never” situation, the reason being that switching on a function could affect literally anything anywhere in the system (it was not supposed to, but in reality it could) so you ended up having to do a load of testing each time and people did not want to take the risk.

It could be argued it would have been easier to just have everything on by default as before, as that would not actually reduce the amount of testing needed as then in the unlikely event you DID want to use something new down the line, the risk would be a lot lower.

Tyrannosaurus Rex on “Being a Dinosaur”

Roar! Tyrannosaurus Rex here. At my organisation we do like to use all the latest features of any new SAP release, so we have been switching on the optional business functions as and when we need them. It’s worked really well. Hang on, I have just got to eat a Triceratops. Munch Munch! Yum, that was great. Anyway, just last year we upgraded to EHP8 and started switching on everything in sight. Trouble is that EHP8 was released in January 2016 and so will soon be three years old. Talk about being a dinosaur! Three years in IT is like an entire geological epoch. Oh look – here comes another Tyrannosaurus Rex – I think I’ll eat him as well!

You will never hear anyone who works for SAP say this out loud, but EHP8 is pretty much guaranteed to be the last EHP for ECC 6.0.So if you wait for ECC 6.0 to go out of life in 2025 you will be ten years behind (given that you actually make use of the new features you may so much maintenance money for). To put that in context – ten years ago I had not heard of Skype and the idea you could make a video call on your phone was science fiction.

If like the TREX above you had just done an upgrade to EHP8 in 2018, you might be forgiven for not wanting to do another upgrade the very next year. Historically it was often been quite difficult to justify the business case for an upgrade every five or six years, or indeed at all. This of course is part of the appeal of a cloud based system – the upgrades happen without you having to do “anything”. I would suggest you still have to test!

The deadline – when ECC 6.0 goes out of support – is the end of 2025. It could be argued that since if you log an OSS message you don’t get much of a coherent response anyway, so it doesn’t matter if you are in support or not, but that would be CYNICAL so let us just say for the sake of argument that being in support matters. A lot of companies have crossed their fingers and wished really hard that SAP will extend the deadline from 2025 to 2030 or some such. Other organisations have written to Father Christmas asking the same thing. Now, this extension might happen – Father Christmas can be quite influential – but you really cannot guarantee it, and with every organisation that does move to S/4 HANA the chances of such an extension become a little bit less.

Orange Juice on “Rip it Up and Start Again”

Hello you (word expunged) SAP types, Punk Band “Orange Juice” here. We presume all the swear words in our explanation will be edited out by the time you read this but just imagine they are there, in a ratio of two to three for every actual word.

To be brutal about this, moving from ECC 6.0 to S/4 HANA is not an upgrade at all, but a (word expunged) new ERP implementation. In addition if you go to the Cloud version you lose all your (word expunged) “Z” stuff. So we say tell (word expunged) SAP what you (word expunged) think of them for making you do this, and if you have to do a new ERP implementation anyway, go with (word expunged) Oracle or someone.

That was a bit harsh but Punk Rockers are not famous for being tactful. Now, as if the idea of doing a totally new ERP implementation was not bad enough, let us look at another problem you face with going to S/4 HANA….

The Kurgan on “There can be only one!”

Hello Mortals! The Kurgan here. The thing about living forever is you see the same sort of thing again and again. In this case SAP have found that in the current ERP system there are three or four solutions for each area e.g. credit control, shipment costs, finance and so on. They have decided to pick “the only one” solution to each problem and kill the solution owners of the other two solutions in each case by cutting their heads off with a sword, just what I would do. I mean who wouldn’t? So you only end up with one solution for, say, credit control, and it is not the SD one, so if you are using that currently you are right out of luck HA HA HA HA! I have to leave you now and start singing “New York, New York”.

The huge immortal monster has a point – in previous upgrades everything was downward compatible. This time as it is not an upgrade at all, huge chunks will be removed and if your configuration or Z code currently depend on one of the “deprecated” solutions you have some extra work to do i.e. start again in that area.

Miley Cyprus on the HANA Database

Hello, Miley Cyprus here. Most people know me for my work on children’s television, as opposed to my series of ground breaking research papers on computer technology and database design in general, which have netted me the Nobel Prize on no less than three occasions, and which were of course fundamental to Hasso Plattners design of the HANA database, which is why he gave it the name he did. It just goes to show how the media is always focusing on the wrong area. Anyway, on the subject at hand none of the components of the HANA database are truly new, but nonetheless the whole is more than the sum of its parts.

There is plenty of free information on the internet, but if you can have a look at the SAP Press book on ABAP development in SAP HANA it will explain to you in crystal clear (technical) terms just how good this database actually is. Once you get your head around why this is different/better it will literally blow your mind.

This time there is no Grey Area – the competition bagged out SAP when they decided to go with an in-memory database, and then a few years later, realised they were in the wrong have been frantically trying to catch up ever since. The analogy is that of electric cars – everyone laughed at Tesla but now every single traditional car making company is going hammer and tongs to try and make as many electric cars as they can. In both cases the world is a better place as a result.

Of course, moving to the HANA database can be done totally independently of making the move to S/4 HANA. Donna Summer sang that this was a good idea, but people at SAP suggest making the change in two steps is a waste of effort. What comes across in the book Miley mentioned and also from people I have talked to at SAP events is that changing the database is not a magic bullet – if you do not change your Z code as well it won’t help at all, it (performance) might even get worse. We will come back to this later.

Talking about Z code, if you move to the cloud version then – although S/4 HANA is stuffed with extension options – you cannot have your Z code in the core system so you either have to re-do it all again in another language, or in the new “ABAP in the Cloud” although the bulk of Z code out there (procedural, no separation of concerns) will have to be pretty much 100% re-written as well.

There are also half a hundred little things like output determination being replaced by BRF+ (do your developers or business analysts even know what BRF+ is?).

Victoria’s Secret on the S/4 HANA Data Model

Hello, Queen Victoria here. Our secret is that we are a huge fan of the simplified data model within S/4 HANA. We are most amused. All the redundancy has been removed and the number of database tables reduced by a huge proportion. If you take the time to research what has been done in the finance area alone you too will be most amused, just as we are. If this approach is expanded to the other areas (formerly “modules”) in S/4 HANA then the whole ERP system will become what our gamekeeper calls a “killer application”. One has to leave you now, one has to punish Doctor Who for the appalling way he dealt with ones Werewolf problem.

As can be seen there have been various pros and cons raised thus far about moving to S/4 HANA. Let us have a quick summary, starting with the negative, and then accentuating the positive, as someone somewhere once said. I am leaving aside the “you have to do it anyway” argument as that does not talk about whether the change is a good or bad thing.

CONS

• The change is not an upgrade, it is a new implementation (actually this could be a pro if your current implementation is stuffed)
• Many “modules” are missing and need to be approached from scratch
• If you go to the cloud you lose all your Z code (needs to be re-done from the cloud)
• If you go to the on-premise version you STILL have to re-do all your Z code due to missing modules and the database change and what have you

PROS

• You are up to date with new features – no new features in ECC 6.0 since Jan 2016
• If you take the cloud version the problem with upgrades go away
• The HANA database is really good
• The data model in S/4 HANA is really good.

However the key point is that whether you like it or not 2025 is going to come along sooner or later. I reckon it will arrive just after Christmas 2024, though you never know, the world might have ended by then. Let’s just say, for the sake of argument, that is has not. In that case you need a plan.

The A Team on “Having a Plan”

Hello John “Hannibal” Smith here. Hold on – I need to light a cigar before I start. As you may know I love it when a plan comes together. BA Baracus says he pities the fools who do not have an S/4 HANA migration plan. What I would do, if I had to move ERP systems, is go in disguise to the implementation partner to sound them out, and if they are any good send “Face” round to charm them into giving us a discount. Then, if they messed up I would arrange to have Mad Murdoch busted out of the lunatic asylum so he could pilot the helicopter (knocking BA out first) to take us to SAP headquarters where we could build an ERP system out of twigs and spare parts whilst music played. This is in fact how most new SAP technology is created, not that they want you to know that. Afterwards we would fire a machine gun at everyone in sight but strangely enough everybody would survive unharmed.

Who am I to argue with the A Team? So a plan is needed for the S/4 HANA change (re-implementation) and I would suggest the following:-

• Run UPL (or whatever has replaced it this month) in your live system for a year to identify the 80% of dead Z code that is never used and you can leave behind on your journey to S/4 HANA
• Switch on the HANA checks in the code inspector, and as long as your developers take note of this, all new code and code that gets fixed/enhanced should be HANA compliant. After a year the 20% of Z code actually in use should then be ready for the change (as any code in use gets changed all the time).
• Run the “simplification database” (or whatever it is called this month) check on your current system to see what is going to stop working due to missing modules and the like.
• If you are not on the “new” general ledger yet then factor in the time it will take you to convert to it – it is not trivial – bearing in mind you have to do the conversion at year end.
• For the missing modules start learning how to use the replacement module e.g. transportation management instead of shipment costs. That will not be trivial either. That sounds really obvious but I wonder how many people do the conversion and then say “Oh dear! SD credit control seems to have vanished. I wonder what we can use instead?”
• Start using unit tests. That has nothing to do with the conversion as such, it is just something I want you to do. I would say that testable code can be converted to ABAP in the Cloud a lot easier, due to the enforced separation of concerns that automated testing brings.

A gave a speech on that subject in Australia in 2016, and also at SAP TechEd in Las Vegas in 2017. In addition there is an enormous amount of material out there on the internet, as might be imagined given the importance of the subject.

Next month it is January 2019. On the first of that month you will have seven years before the ECC egg timer runs out. That sounds like ages does it not? What if I told you that if you start tomorrow it might take you eight years to be ready? Obviously that is a bit of an exaggeration but on the other hand maybe it is not, it really depends on the quality of your Z code and how many “to be discontinued” modules you are currently using. That would be a horrible thing to discover – bit at least you would know, so it’s best to check!

Cheersy Cheers

Paul