Why is it difficult for SAP consultants to think about Agility?

After 16 years of working as a SAP consultant, participating in several implementations from scratch, upgrades, interfaces, improvements, support, having been part of an IT team in a corporation that worked mainly with SAP globally and embarked on a SAP Ariba implementation as part of the digital transformation program, I quitted this world and decided to get strongly involved in?agility and innovation world?and I immediately fell in love with it.

My intention with this article is to share my experience and try to bring?both worlds together to accompany IT teams that work with SAP and need to transition to agility and the agilists who are accompanying them in this process.

When I think of SAP, “Agility” is not exactly the first word that comes to my mind. SAP is a system used by thousands of companies and I would venture to say that it is because of its stability, reliability and because of its integration. All areas of the company in a single system and with the confidence German systems generate.

But I think that the main?attributes for which SAP was implemented in the first place, are currently generating additional difficulties for companies and teams that need to respond to the challenges of digital transformation.

Many companies today need to drive innovation, build effective new processes and get closer to their own customers while still staying at SAP.

What do we do then if we have had SAP for many years and want to transition to agility?

First we need to understand something that I think?is key to being able to understand and empathize with SAP teams.

• Historically, SAP R3 or ECC implementations were made with a methodology called ASAP whose main milestone is the creation of a Business Blueprint, which is like a document "signed in blood" which has to be done as soon as the project starts, where the client declares how its processes are and the SAP consultants?analyze how those processes can be replicated or improved using standard SAP. Everything that does not have a solution with the standard SAP, is presented to the client as a gap and attempts are made to avoid changes or negotiate a middle point so that it has the least amount of custom coding possible.?

Why is the Business Bluerprint so important in this methodology??

Because it is like a contract that everyone (company and supplier) signs. Exiting the agreements of this contract means renegotiating scope, time and money with the client.

• SAP consultants specialize in SAP modules that are aligned to the areas of a traditional?organization or in silos in the language of agility.
• SAP implementations, in my experience, were always in?Big Bang precisely because of the full integration that it has.

So, how can we transform so many years of working differently if the same system, created especially for the traditional business model, invites us to force the client to adapt to what exists based on a rigid document whose raison d'être is to prevent parties from not keeping their word, where the concept of early and frequent delivery does not exist and is also designed to work in silos?

Does this sound close to agility?

Another thing that we must also consider in our analysis is that SAP has different ERPs. The older R3 or ECC and the newer S4 HANA.

The minority of companies are migrating to S4 HANA, which is the new ERP that SAP released in response to digital transformation and to which companies will have to migrate sooner or later if they want to continue receiving support from SAP (as far as I know, SAP informed their support to ECCs ends in 2030).

Most big companies today have implemented R3 many years ago and what they are doing today, during the digital transformation, is:

• R3 interfaces with new systems, many created with the new mindset (third party solutions on cloud / on premise or own systems)
• Enhancement to existing processes on the same R3.
• Support of existing processes either because something is broken, by new small configurations to the standard or in one of the 1000 Z tables (non-standard) that were created during the implementation or later years.

For the S4 HANA implementation, SAP released a new methodology to replace ASAP called Activate.

From an agility point of view Activate removes the Business Blueprint as a mandatory deliverable and instead provides a SAP preconfiguration that users can access, test and where they can learn how standard SAP works. In agility it would be our prototype on which customers will give us feedback.

This is already a big difference with ASAP where the user did not see or touch the system until the integration testing starts, which was very close to the Go Live phase.

After the user explores the system, the consultant and the user/client can imagine how the process should be so that it can be done with standard SAP and this is where we, SAP consultants,?will again try to avoid deviations from standard.

In my experience implementing SAP Ariba, on cloud versions this negotiation becomes increasingly difficult since, although it was a multi-tenant version, providers such as SAP try to avoid customizations due to the cost of maintenance, that eventually is transferred to the customer, and each change if they are feasible,?can take a long time to be implemented.

In cases of single tenant solutions, customers are tied to the solution roadmap, so a change -although necessary for the customer- can take months or years -if it happens.

Returning to Activate for S4 HANA, the list of gaps generated would go to a gap backlog that can be worked on in different sprints using Scrum.

Now ... some questions that arise ...

How are agile teams formed for an S4 Hana deployment? Do they come out of silos and assemble multidisciplinary teams?

How is early and frequent delivery of value done? Are configurations and developments passed to the quality environment divided into functionalities for users to test partial deliveries?

How is it done to avoid conflicts between the client and the supplier or IT in case of being an internal team of the company if there is no document (BB) with agreements?

Unfortunately I do not have the answers and I would love to hear from those who have experiences implementing S4 HANA in an agile way so that we can improve this article together.

For SAP R3 projects, improvements and support, the situation is as follows:

• Today SAP consulting teams are still in silos
• Each silo has its own portfolio of projects (regional and global) with different business partners of Product Owners managing them on behalf of business clients.?
• Most likely, each project needs to put together a team of people who come from different silos, with which the resource manager must assign each person based on the hours that are necessary to one or more projects.
• Each silo has its own agreements with its customer as well as its own priorities.
• Each silo has its own fixed budget assigned to the project.
• Each silo in turn needs to “keep the lights on for the business” with which they have to automatically respond to the resolution of incidents.
• Most likely, each silo serves different regions, which may have a need to work on enhancement or other small projects, even if there are large projects in progress for another region.

I can share something about it because I had to lead a team in this situation.?

We had the request to transition to agility and decided to give it a try after an eternal waterfall implementation of SAP Ariba in LAO & APAC.

How did we manage it?

During the hypercare we appointed a Product owner who was the Business Partner representing the business and had been with us throughout the project, and three people from my team (a functional analyst as scrum master and a functional analyst and a programmer as development team).

Then,?Scrum Master?and?Product Owner put together a backlog in which, due to organization, availability and priorities, we decided to include the enhancements that had been pending from the project and incidents that arose during hypercare.

So far, everything seemed to work fine until extra tasks began to appear.

In these types of companies, IT teams generally cannot focus solely on a Scrum Team, but other types of requests arrive such as training, administrative performance tasks, requirements of other urgent projects (legal, audit or security) that require time from some of the people on the development team. This?obviously started generating tension between the Product Owner and the resource manager, which in this case was me.

The discussion was around that all those additional tasks that arose in the Sprint, had not been planned in the backlog and that was a great barrier to achieving the team's objectives.

There also started to be discussions between the Scrum Team and the external support team about who should take care of this or that incident. Because we had a single tool where we handled all post-implementation support tickets.

Another big problem or discussion occurred when the root cause of incidents were in the on-cloud solution, which, as I said before, is not easy to get modified and over which the company has no control at all.?The incidents were open for months and went from Sprint to Sprint without any progress, which generated a lot of frustration for the team and the client. I imagine the reader can get an idea of the impact this had on the relationship with our client.

Another scenario that I have seen is small projects, to which perhaps a person from the silo should dedicate 30% of his/her time and for that reason the resource manager assumes that he/she can be assigned to other projects with equal dedication.

Let's imagine that person was assigned to 3 small projects and all 3 are handled with scrum.

Let's think about that person going to all 3 project scrum events… How many hours per day should he/she work?

My conclusion is that there is no recipe and that is why it is so important that we share experiences and help each other.

I think the transition to agility will be more or less easy according to each organization. I am convinced that sustainable agile is not possible over time if true focus and commitment is not placed on BEING agile at all levels in the organization. Especially C Levels.

I also believe that IT people and especially SAP consultants would be delighted to work with the agile mindset, values, but as you probably noticed,?the situation does not look so easy and that is why I invite you to think together how to accompany them in this process in the best way.

Friends of the agile community… From an agility point of view and based on your experience, what other options do you see in these scenarios that I shared with you?

Thanks for getting here. Hopefully this article is filled with ideas and experiences from both worlds that I love so much!

Special thanks to:

Rod Aular who collaborated giving me feedback and making technical contributions to the article.

Andrés Calomeni with whom I had a great talk about Activate, a methodology in which he is certified.

Diego Sanchez Rivera who gave me the idea and encouraged me to write it.

See you soon!

Romi florentino