Aug 24, 2022

From customization to standardization in SAP, how to avoid falling again into traps from the past

The world of large ERP implementations where we were starting from a blank page and doing several months of blueprinting sessions are far gone. Organizations do not have that luxury and those types of budgets anymore. Now we need to focus on Rapid deployment, lean and standard processes.


How were we used to do SAP implementations in the past?


We used to do large implementation projects with 7, 8 or 10 Consultants for Finance, another similar number for Materials, Sales and so on. At the end all adding up close to 100 hundred SAP Consultants easily. And we were not implementing SAP at Walmart, just at a normal company …

We would do 4 to 6 months of Blueprint sessions where we would look into every single thing out there in a process and configure SAP accordingly and mimicking the legacy process into SAP configuration. We would configure even the smallest things that SAP allows us to configure (Ex. Optional or required fields on Finance Posting Keys, changeable fields on a posted Finance document, just to name a few of those ones out there, but the list could be big). All because we had the time and budget to do it and an “open bar” policy for these type of things. And these were the standard things that SAP configuration allowed us to do.

Then we would look into all sort of business requirements that were not standard SAP and we would do custom developments for them. Tons and tons of lines of Abap code for custom reports, custom Transactions, customize SAP standard delivered screens and even customize and append Standard SAP Tables because the business had a requirement.

(Before you jump, I would never, ever recommend customizing an SAP screen or appending a standard SAP table …)

This would lead to months of development and testing and re-testing, many times even all the way up to the cut-over weekend because some of those developments were complex and intricate. In some cases putting more than one go-live at risk ( … I am sure you can relate to some of these examples and you are now remembering some cases in your mind …)

Then after go-live, you would continue doing new developments over the subsequent years whenever the business would come up with a new requirement. Instead of analyzing the situation, trying to find solutions within standard SAP and adapt the process; NO we would develop something new. A new “Z” Transaction and new “Z” field and new Z something.

You end up after a couple of years of following this approach in a complete ZAP environment (SAP with Z), where you do not recognize the system anymore. Everything that the users do starts with a Z, transactional or reports, all would start with a Z.

Several years ago, I remember working for a customer; where it took me a while to adapt to their SAP system. You would click SAVE and a bunch of things were happening in the past that would change the complete behavior of the system. Screens that had extra fields that you would not recognize because there were not part of SAP standard. And the worst thing is that most of this was not documented anywhere because it was done many years ago and they did not have a lot of discipline. It was in someone’s head that luckily could still be around or not. This client had been in SAP for 15 years at the time. Coming easily from SAP versions 3 or 4. The amount of custom at this client was insane. (And it is still that way because they are still using their old ECC).

Another client, in complete different industry…. We went to do an assessment to implement S/4. They too have been using SAP for ages … We were analyzing their processes and we asked them to provide us the list of Z Tcodes and Z reports to analyze them and see which ones we could replace with standard SAP. They came up with more than 150 just for Finance, Materials and Sales. 150 custom developments are a lot. Someone would say, I have seen more than that. Oh yes, I have seen more than that too. But it is still a lot …

Some of these clients they have even customized and created their own entries in the IMG, with custom IMG options to maintain all these extra customizing that they have created over the years. Customized the IMG !!! A bit too much.

And I have a couple of other similar examples too of big companies but not as big as a Boeing or Walmart.

How much does it cost to maintain all of that? A lot !!

What is the impact of having all of these undocumented solutions?  It cannot be measured

Then you bring outside people (like me at one of these clients) and for someone that knows SAP, all of a sudden, he needs to learn it all again. That has a cost for organizations too that have to pay for that long ramp-up period.

These has other consequences too. All of these clients cannot do upgrades anymore because it would cost them a fortune; more than doing a brand new implementation. Some are still stuck in versions 4.6 or 4.7 that are way out of maintenance from SAP. This client even ended-up hiring a company from India that provides support for SAP environments that are out of maintenance. Like a generic aftermarket auto-parts manufacturer but for SAP solutions.

These customers cannot comply with new legal requirements delivered by SAP via OSS Notes and for sure they cannot benefit from new developments or new technologies as well.

Now, what can we / you do to change that? 

Not easy and definitively it takes time …

Over the years, SAP has run out of opportunities to sell new implementations to the Walmarts, Boeings, Airbus of the world (just to name a few). All the big guys and not so big too they were already in SAP. Those big ones are the ones who, “to some point”, they can still afford to have big implementations. But the others, no. So, they started looking some levels down in the pyramid to sell projects. But those companies did not have the same budgets and luxury that the big guys had. They needed to find a new approach for that market.

That is when we started seeing more and more implementations in the market using the Best Practices packages from SAP, with pre-delivered configuration for different scenarios, with pre-built configuration guides, process flows and testing scripts. All this pre-built material helped reduce the costs and accelerate the delivery. Many of the Consulting companies had picked up these documents, added their own logo, fonts, colors, added some of their own flavor and would sell them to customers as “accelerators”. Many are still doing it with every version.


We were starting from a good base, and we did not need to configure everything from the ground up.

But this was fixing some part, but we were still doing a lot of custom developments.

 

Some companies started seeing and putting all these variables together:

  • high or impossible to upgrade costs,
  • high maintenance costs of their own customization developments and
  • lack of standardization

In the meantime, SAP launched SAP Simple Finance which later turned into S/4 HANA with their In-Memory Database. Promoting digital Transformation, Machine Learning technologies and a completely new UI like Fiori that would simplify the user experience making it in line with the type of intuitive user interfaces that we have today in our cell phones.

They also replaced their ASAP Methodology by their new “SAP Activate Methodology”. This new methodology got away from the traditional waterfall approach and got closer to Agile but still with certain reminiscences from waterfall.

 

For these clients something needed to be done, they wanted to be able to adopt new technologies. They were in outdated platforms too at risk with the OS and their Databases too.

As I mentioned before, some of these clients were (and a lot still are); in systems that are way beyond salvation, there is no “brownfield” option for an upgrade … So a new “greenfield” implementation was the only way out for them. Complete re-design from scratch.

This was the tipping point for them.

So they said, “… Let’s do a “greenfield” implementation … but how can we avoid falling into the same traps and making the same mistakes we did 20 years ago?. The industry has changed and those big & gigantic SAP programs where everything could be customized cannot be executed anymore. There is no more money and time for all of that.


As I mentioned, SAP Activate is Agile with a flavor of waterfall (a mix of the best of both worlds).



Within the methodology, as key part of this Standard vs. Custom approach is in the “Fit to Standard Analysis”.

We stopped doing detailed Blueprint workshops and started to do “Fit to standard” workshops.

The business users would explore the SAP best practices and standard business processes such as order-to-cash, procure-to-pay or hire-to-retire that are mapped for S/4HANA

We would show them the standard SAP delivered processes, show the fit on the client processes or see where their processes could fit in regards to standard and then question and challenge the parts that were not a fit.

In plain words we would ask “… Mr. Customer, tell us why you cannot use this standard process to do “xyz” and you need to customize it. Please justify it … ”

 

Out of those “Fit to standard” exercises a list of gaps would emerge. There are 2 possible solutions for them Adopt or Adapt.

·       Adopt the SAP process and become standard.

·       Adapt but using SAP standard configuration and still remain standard.

These last 2 would have some process reengineering and change management to do.

OR …

·       Adapt the system and customize / develop a tailor-made solution.

A complete fit-gap exercise ensures greater visibility of the gaps that the standard S/4HANA is unable to offer. In such cases, a fit-gap strategy decides if a system’s enhancement, a customized application, or activating a business add-in will address the identified gaps.

This is where companies should make a shift on their approach.

These companies implemented rigorous revision processes before approving any custom developments.

They created “design review committees” where they would scrutinize each and every single development asking Why is it needed? How will it be done? And most importantly, What happens if we don’t do it? What is the monetary impact? What is the business impact if not done? Is there a standard workaround that could be used instead?

Custom developments like some of the ones that used to be done in the past by some reckless consultants that would modify standard SAP code, are completely out of question. Even putting enhancement spots.

Some are going even further these days and the moment they hear something starting with Z, they shut it down right away. I personally faced this to address a business requirement where we would use a series of standard function modules and BAPIs but all wrapped up in a Z program. I was not even allowed to present it to the committee.

This process needs to have rigorousity and needs to be unbiassed for at least 2 main reasons.

1.       Keep your project budget under control, otherwise you end up with an endless list of custom developments that put you at risk to meet your go-live date. AND

2.       Avoid over customizing your system beyond the point of no return, like I described earlier where some systems become ZAP (SAP with a Z) and you cannot upgrade them anymore unless you are willing to invest a fortune on it.

These “design review or design authority committees” are made of different technical and non-technical people such as Solution Architects, Development Team Lead, System Integrator executives, Integration Managers, some line of Business executives and other individuals with many years of experience too. Another member of this committee is SAP itself. Clients would hire SAP Max Attention services to be part of this decision making process of reviewing these developments to add another level of scrutiny and legitimacy.

In some cases, during an S/4 HANA assessment project we had SAP Max Attention within this committee early on when we were doing the proposal for a future project, and we had to justify every custom development in front of them for them to provide an opinion to the customer if the development was justified or not.

In other cases, Max Attention was an integral part of the project on an ongoing basis and was a permanent member of this committee.

The committee will act as the guardian of your solution, protecting you from yourself, protecting you from falling into the old habits of deviating from standard SAP solutions and overly customizing your system.

In many cases, this will get a lot of business people upset and feeling that they are losing functionalities and information. This is where you will have to work redesigning your process and in change management with your people.

But this strategy will pay off in the long run as you will stay within standard SAP, and allow yourself the possibility of doing upgrades and adopting new technologies as they are released by SAP.

S/4 HANA on-premise is a system that has been constantly evolving since its launch in 2015, every year there is a new release with new features and functionalities. Staying standard will allow you to adopt them faster and reduce maintenance costs too.

 

Remember:

You have a decision to make …

Do you want to address every single business requirement not matter if it requires doing custom development, making you spend a fortune, increasing your maintenance costs and putting you at a disadvantage for an SAP upgrade? This should be part of the past way of doing business.

OR

You prefer to reduce implementation costs, reduce your maintenance costs while staying standard, invest in change management and process reengineering and allow you to adopt new functionalities and technologies faster whenever they are released? This should be your future vision and approach. Today this should be a no brainer decision for all organizations.


If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

No comments:

Post a Comment