Connecting technology with business outcomes has always been imperative to the success of the intelligent enterprise, but as digitization and cloud migration accelerate the rate of change for SAP customers, today's technology leaders continue to seek insights into how best to pivot, adapt, and transform their operations.
Pierre-Francis Grillet is the global lead for SAP Services at SoftwareOne, a Swiss-based services provider that serves SAP customers in the US, Europe, and Asia/Pacific regions. A 30-year veteran of the SAP ecosystem, Grillet previously held roles as a global CIO, an SAP employee focused on consulting and value engineering in Asia/Pacific, and a longtime consultant and systems integrator.
EAC analyst Josh Greenbaum, a regular ASUG News + Views contributor, recently sat down with Grillet to discuss the state of the SAP ecosystem and how ASUG members can navigate the complex choices they face in digital transformation.
This conversation has been edited and condensed.
Q. What is your sense of the state of the SAP community? How are the customers?
A. The first reaction that comes to mind is "complexity." I don't think customers were previously exposed to the number of choices they have today. The transition from SAP R/3 4.6c and ECC, for example—previously the major generation challenge in terms of SAP software—was straightforward. Today, there are a multitude of choices.
The first choice pertains to infrastructure: Are we staying on-premises? Do we want to move to a public cloud? Do we want to go to a private cloud? Do we want to exit the private cloud that we have to go to another solution? Or do we go to RISE with SAP, which is a different type of private cloud? The second choice relates to how customers can consume the SAP S/4HANA license. Do you continue to use the traditional on-premises license with ongoing maintenance? Or do you subscribe to RISE? What contractual rights can you transfer to S/4? How do you negotiate the right licensing? These are complex problems.
The third choice that customers have to make is to justify the move to S/4: What do we want to get out of this? Is it a major transformation? Or we are looking more at modernizing the existing SAP assets and making sure that we are geared up for ongoing innovation? What is the pace of transformation that should be adopted? How do I get support from my organization, from business stakeholders? What is it going to cost, and can I justify that?
You also have more technical choices. Do I do this in two steps to minimize the risk, going to the cloud first and doing the S/4 conversion later? Do I want to do both steps in a single go, to lift and shift? Or do I focus on implementing some minimal changes upfront, because it's going to be difficult to make those changes later on? If you put these all together, the SAP customer’s roadmap to the cloud has never been as complex as it is today.
Q. Some customers justify S/4 migration to pursue technical transformation; others see it as a part of business transformation. The choice can be controversial. When a customer approaches you and says that they just want to lift and shift, that they don't care about business transformation and they don't even want to think about it, what's your advice?
A. It's always important to respect what the customer wants. Maybe they want to sell an entity, and it's important to go to S/4, but they don't want to make any changes. In general, I would at least ask the question, "Would you consider some of the changes that really make a difference in S/4HANA? Are you open to making some changes now that will benefit you later, and that will be more difficult to do after you go live?”
Q. It’s hard to upgrade, and then it’s hard to stay up-to-date and maintain a system after an upgrade. Talk to us about the continuous upgrade problem.
A. Ongoing innovation is fantastic. Who doesn't want ongoing innovation? The challenge is when you bring this to the level of complexity and integration of an SAP environment. There are a multitude of interfaces with external systems, and those external systems will not necessarily behave well relative to the changes you make in your core system. You also have people, and you have data, and you need to consider the impact of all these dimensions. Smaller organizations that typically would be the target for S/4HANA Cloud, public edition, where innovations are being shipped every quarter, are not likely to be the best equipped for [managing this change].
Q. If you're a smaller company pursuing a public cloud implementation, should it be wall-to-wall SAP, or as SAP-centric as possible to limit potential complexity?
A. The days of saying "we're just going to be wall-to-wall SAP, because that's the easiest way to ensure integration" are over. One of the reasons is that your system is no longer within the four walls of the organization. The system interoperates with the external world, and you can't expect everyone to apply that principle.
In addition, the business wants to be able to procure the SaaS solution that meets their requirements, and they're not interested in hearing about any restrictions. They will take integration as a given and insist that the IT organization provide a platform that ensures the smooth, seamless integration of whatever solution they need to buy because it meets their business requirements.
Q. I heard two interesting presentations at a recent ASUG Chemicals Industry conference. The presenters said that they believe in fit-to-standard and the use of standardized processes, but at the local level, localization makes fit-to-standard hard. What's your take on this?
A. All projects start with the principle that we will adapt to the software, not change it. But I haven't seen a single project where you don't end up with more customizations than anticipated. There will always be a need to do some. Should customers limit their customizations? Absolutely, yes. Can BTP magically solve that problem by keeping the core clean? Yes, you will have a clean core. But it doesn't necessarily mean that all the challenges you had before will disappear.
Q. The clock is ticking on S/4HANA migration. But for many customers, there's neither the time nor the money, nor enough support staff, to move everything off ECC by the 2027 deadline. On the other hand, customers have all kinds of competitive and regulatory pressures, and they just can't sit still. What do you say to customers that are trying to balance this?
A. There is no easy solution, and there is no silver bullet. What I will say is probably obvious and not groundbreaking, but it's all about planning. As I said, the decisions are complex. So, you need to plan, take the time to sit down and understand what choices you will have to make. The worst thing that can happen is that you make these choices as you go or you don't think them through, and then you realize too late that you made the wrong choice.
But don't wait. It's only going to get harder because there will be less time available to do things and fewer resources on the market, because everybody will be in a rush to do it at the same time.
Q. Let’s talk about people. We hear a lot about how partners providing services have to deploy skilled individuals rather than training new employees on the job. But what about the customer's requirement to put the right people on the right projects?
A. The type of journey that you undertake will dictate the skills and the demands that you place on the business community. Freeing up business people’s time is never an easy business. You need to bring the experts. You want the sharpest brains to inform the transformation, validate the best choice in terms of design, ensure you're building correctly, and encapsulate all the knowledge these people have.
The smarter organizations are those that plan in advance. They incubate talent before the project so that their people have the knowledge, then they dedicate them to the project. Those people are well-equipped to take responsibility to drive the benefits expected from the system, because they've been part of the transformation. And they're accountable for the work they do because they have to derive the benefits later on. But it's not easy. And, again, planning for that is important.
Q. Speaking of people, change management is essential, yet it's typically not done as well as it should be. How do you balance the need for change management in a project?
A. It's difficult because most business cases are driven by financial benefits. That's reality: you justify an investment by its financial benefits. You're going to have savings because you have less maverick procurement, because you consolidate your vendors, because you drive different behaviors.
At the same time, the best lever for success that organizations have is the level of engagement of their people. If you can increase engagement by 10%, that's going to be massive. This should be the number one objective of an organization: how do I drive the level of engagement higher? I think the smart organizations have managed to blend the two. They’ve managed to link change management with the whole benefits realization stream. For me, the two are meant to work together, because the business case and business benefits should form the "why" and the change management then articulates the next question: “What's in it for me?” If you don't have a “why,” it becomes a bit theoretical to try to look at that second question. "What’s in it for me” is harder to sell; people are afraid because of what they think is going to happen with their jobs.
What’s essential is how you bring the two together. I remember a survey from 20 years ago that listed the main causes of failure for ERP projects, and these were, in order, a lack of change management, lack of training, poor adoption, lack of respect of the rules, people finding shortcuts in the systems, and data quality. The infrastructure and the software were the least responsible for achieving benefits. The survey then asked, "Where do you plan to invest in the next five years?" The list of criteria was completely turned around, it was all about investing in technology and software. Change management and training were at the bottom. It's really hard to make the case for change management, even though it is such a powerful lever.
Q. Another big topic is heterogeneity. SAP is finally recognizing that customer landscapes are complex, and the SAP Business Technology Platform is part of that recognition. What do customers need to do to make sure that they're using BTP correctly?
A. BTP covers integration. It covers all the data and analytics requirements, and then it supports innovation with new technology, IoT, machine learning, and so on. It's used differently by customers depending on their demands. Customers need to understand, technically and commercially, what the respective benefits are in building innovation on the hyperscaler innovation platforms, as opposed to on BTP.
And it's not simple. The pricing logic for BTP is different depending on the use case. Customers need to educate themselves to understand what those pricing metrics are and do an evaluation to compare them from a technical standpoint and a commercial perspective. What does it look like in an SAP world, and what does it look like in a hyperscaler world? I think the answer will be that it depends. Some things will be better built on the hyperscaler world, some things will be better in BTP.
Q. What’s your final advice for customers and ASUG members?
A. Reflecting on our discussion today, on the complexity of the choices customers have to make, on the time remaining, and on the importance of planning and preparation to make full use of that time, my closing thought is that there’s not one minute to lose. Customers need to get started on the journey because it's coming. We see a lot of customers pushing this out because it's not a priority. I think they're just creating more pain for themselves in the future.
Joshua Greenbaum is principal at Enterprise Application Consulting.