We know that an SAP S/4HANA project requires forethought as well as flexibility and patience. We also know that bumps in the road are inevitable, and the best way to handle them is to be prepared.
In this three-part series, we discuss common factors that lead to failed projects. We break down the steps an organization can take to avoid failures as well as how to plan for better decision-making. ASUG News sat down with John Belden, project execution audit practical lead at UpperEdge, an organization that helps customers negotiate their deals with SAP and systems integrators (SIs).
John has more than 30 years of experience implementing SAP systems. In the first part of this series, he identified common traits that can lead to a failed project and the early first steps organizations can take to avoid them. In the second part, he discusses the critical first steps an organization should take for the implementation phase. He also covers who should be at the table and how to plan for high-level decision-making and set budget expectations. In this final article in the series, we discuss how to partner with the right SI, what role the consultant should play, and considerations for change management.
Sharon: What should customers consider when partnering with a systems integrator?
John: The most important thing that an SI brings to the table is its talent. Usually, when an SI pitches to a client, the person pitching always says the company will provide the A-team. The A-team, however, tends to mean average and available. If you think about that SI and its business model, 90% of its resources typically are already engaged with other clients. So, you are getting the resources that are available at the time you need them.
You have to think about the talent and cautiously look at everyone’s resume. Make sure that the talent provided is aligned with the projects the firm says it worked on. Ask for examples, because oftentimes, an SI will present examples of successful projects the firm has worked on, but the talent being provided might not have been part of those projects.
Second, it’s critical to evaluate the tool sets SIs are now bringing to the table to help with an SAP S/4HANA implementation, especially if you’re already sitting on an SAP ECC 6.0 platform. There are so many advancements in this arena, you need to know what the SI can bring to the table and how that can help your project move along.
Look at what each vendor is offering—both in terms of talent and tools—and then, finally, look at the vendor’s willingness to accept risk. It is willing to do things on a fixed bid? Is it willing to share risk with your organization? How deep does it want to go into that space? That information will give you at least a certain level of confidence in the estimate the SI is providing.
These three considerations can help you make an educated determination to partnering with an SI.
Sharon: How much involvement should SAP have in determining which SI you partner with?
John: I think it’s important for SAP to be the independent evaluator of the talent that the SI recommends. This is especially true if you’re new to SAP and you’re implementing SAP S/4HANA. I would think about having SAP as an embedded resource that’s somewhat independent of the SI to help evaluate those final solutions.
Sharon: What can customers do to determine the best role for consultants to play both before and after implementation?
John: Regarding the implementation stage, we see more and more companies using application management services (AMS). We’re going to see this more over time. As implementations become more standard and there’s an adoption of those industry standards, the ability to leverage an AMS organization and the cost associated with working with these organizations will continue to go down. AMS teams will be able to develop more robotic process automation and more of the ability to test systems for clients because all their client configurations are going to be relatively the same.
It’s critical to think about bringing on a future-state AMS team as part of the implementation of SAP S/4HANA. Think about how that AMS organization can actually share some of the implementation responsibilities.
Sharon: What checks and balances can an organization integrate to keep a project on task and to preemptively identify challenges?
John: One of things we recommend is independent risk assessments and evaluations. You need someone who can come in, look at the program, and identify where the blind spots might be for teams to proactively address those areas. We recommend that teams track their issues and decision-making efficiency as a part of the project. You’ll hear a lot of project teams say, “we’re tracking deliverables,” or “we’re tracking the amount of code.” Then they end up getting behind because they’re tracking deliverables and not the process of getting there. The more that you focus on the efficiency of issue resolution and decision-making, and track that as a critical program indicator, the better chance you’re going to have of actually staying on schedule.
Sharon: Which teams within the organization should be identified as key players for each phase of the project?
John: Very early on in the project, as you’re in the exploration phase, you should include the general managers and the process owners. Those are, from my perspective, the key decision-makers. And as you get into build and test phases, I think it’s important to then bring in your superusers. The earlier that you can get them involved in the project, the faster you’re going to be able to know if you have a problem, especially during the testing phase. They’re going to know better than anybody else if something’s working or not.
Sharon: So, should your superusers be involved even earlier so that they’re familiar with why decisions have been made the way they’ve been made?
John: Well, that’s a really good question. It’s fascinating when you think about change management and how long it takes from when the C-suite decides it needs to make a change to how long it believes it should take the organization to adopt it. Change management takes a long time.
I don’t know if it’s necessary for the superusers to be involved from the very start. But, it’s certainly important to think about them as being ultimately the evangelists for change within the organization. And, the sooner that you bring them in to understand why the decisions were made—and that can happen during the build phase or test phase—the better chance you’re going to have when they’re delivering the training. They’re more likely then to support those decisions as a part of the training delivery.
So, earlier is much better than later. I don’t think it needs to be all the way up in the big decision-making phase, but certainly sooner is better than later.
Sharon: What should customers consider when thinking about change management and adoption?
John: I think lots of companies spend a lot of time just talking about what the end state is, and they don’t necessarily spend a lot of time thinking about where they’re at now. They’re not building a logic trail that helps the company understand the difference between where it is today versus where it wants to be tomorrow.
By the time the project team is on its eighth deployment, it is fundamentally speaking a different language than the individuals who are just being introduced to it. We recommend that as project teams roll out SAP in waves, they should always try to use the last people who received an SAP system as the ones who help the next wave go live. They’re able to bridge that gap of where we were to where we’re going. And they can speak both languages.
Sharon: What’s the one thing that you recommend that organizations work to change to avoid turning their projects into disasters?
John: Don’t think that there’s one thing that you can or need to do. It’s like asking what brand of car I should take off the road to avoid getting hit by a car. It’s not necessarily the right way to be thinking about it. But, if you need to think about one thing, think about what you need to do to make high-quality decisions. The senior leadership should always be asking that question.
Sharon: Instead of talking about avoiding SAP S/4HANA disasters, let’s end on a more positive note. What are the common traits of successful projects?
John: You always hear people suggest the need for executive involvement or end-user support. But in the end, all that matters is that you have high-quality decision-making in the room. That’s it.
Register for the ASUG on-demand webcast, “Top 10 Questions to Ask Before Migrating to SAP S/4HANA.”