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:
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.
