In “SAP Success Secrets - An interview with the best of the best”, we sit down with one of the outliers from our SAP Success Report Survey.
Of course they have to remain anonymous… so we’ll just call them Bob.
In the last instalment we chatted about executive sponsorship, project management and PMO. If you haven’t seen it, you can check it out here.
In this instalment we’re going to be talking about systems integrators, vendor management and adoption focus.
Here we go.
SAP Systems Integrators and Third Party Vendors
Resulting Ltd: Here’s the next finding, when posed the statement “SAP programmers delivered successfully with the support of a suitable systems integrator with a strong cultural fit to the business”, 60% of respondents felt they weren’t supported by the Systems Integrator, and only 18% of executives felt that the systems integrator supported the project with a strong cultural fit. That’s less that 1 in 5.
Bob: So perhaps the benefit I saw on my project was that we had a very able systems integrator who was already experienced with the client, so they weren’t bringing in any new systems.
R: I think cultural fit is important too. If there’s not a cultural fit things just don’t get done. You see so many systems integrators where there isn’t a fit and they just throw anchors out of the boat all the time. They’re there to get their outcome, but they lose sight of the client’s outcome.
The next finding is 57% of respondents felt that they hadn’t secured the right balance of third party vendors. Within that, 63% of procurement people felt that they got the mix wrong.
B: So is that saying they brought too many consultants in or too many of the systems integrator do you think?
R: Well, I doubt it’s too many in house people. It’s either going to be too many contractors or too many third party consultants.
There’s this cliff edge thing which is you’re spending 10 million pound on an SAP implementation, but 90% of your workforce and 90% of the knowledge base resides in externals.
You hit go live and you go through the obligatory 6 weeks of warranty cover that most people will commercially build into their RFP and then you hit a cliff edge where they…
B: They walk away.
R: Yeah and knowledge vanishes. It’s really hard to transfer knowledge from a busy incumbent team who are trying to implement a solution and get it over the line.
B: Yes there’s no time for that knowledge transfer and the systems integrator’s probably not that interested in passing on that information either.
Knowledge Transfer on SAP Projects
R: What has your experience of knowledge transfer been?
B: So in here it was the systems integrator who would continue to support us after go live.
A lot of the people who had been doing the technical build or the technical development of the changes were going to be there supporting it, although in a much reduced team.
R: What about the business knowledge though? For example you can have somebody who logs a ticket because something’s wrong, but it can be wrong because it’s broken or it can be wrong because somebody doesn’t know whether to cancel an invoice and re-bill it or to credit it.
That business knowledge doesn’t transfer to a third party because it’s business knowledge.
B: I think because of the experience on the project they had picked up a lot of that business knowledge.
There’s also a problem seen at so many different organisations where those skills are just being released away and being outsourced which can be a great mistake.
If you let that business knowledge go how do you ever get it back?
R: That’s the worst of the worst isn’t it? You do a BPO and outsource your finance processing, apps management and your IT.
You end up with the users working for IBM, the IT support people working for Infosys, and your outsourced business process people are dependent on your outsourced IT people to do anything.
And you end up just sat watching from the sidelines.
B: And, you can’t do anything about it when things go wrong. As a business you can be left crying out for support desperate with lack of knowledge.
SAP Project Architecture
R: The next finding relates to the statement “architecture team had sufficient depth of knowledge to define a solution that was suitable". Of the general respondents this was roughly 50/50, but interesting only 60% of architects felt they had sufficient knowledge to do the job.
B: Well I can understand that because it’s so complicated. But, if you haven’t got the knowledge are you the right person for doing it?
Those architects have got to really understand the solution - the devil’s in the detail, and the devil’s in the detail for the data as well.
They’ve got to understand the architecture of the data, all the underlying systems, and all the different interface systems. Those architects have got to understand all the different interfaces that are coming in and out and be able to process and manage all that data behind it as well - it’s mightily scary and complicated.
R: Another interesting one for architects is this: “the SAP programme was an opportunity to standardise best practice rather than rebuild existing processes.”
Around half didn’t and half did agree, but interestingly 70% of executives thought they had standardised, so you’ve got this disparity where executives think they’ve standardised but on the ground they’ve not.
B: And then forever on you’re maintaining those customisations that you built. So the closer you can get to that standard solution the less you’re maintaining year on year and you know it’s going to work.
SAP Adoption Across the Business
R: Next one: “a high degree of emphasis was placed on adoption of the SAP solution throughout the programme”. 45% of our respondents said there was insufficient emphasis on business adoption.
B: So that’s kind of worrying as well because that’s surely all part of your change programme, your communications and your training, making sure that your business is ready to adopt your solution.
R: What kind of adoption strategies did you see on the programme you were on?
B: So, very clear communication from the executive of what the overall business goals were, a global training plan to embed those business goals, clear communication about what exactly was changing and when, and refresher training before and after the event.
R: What kind of training methods were used?
B: We had a very able training leader.
They used gamification during a lot of this training and then made sure people had learnt it and were tested on it. The training was also rewritten into local languages.
R: Which is key on a global role. You can’t assume just because you speak english…
B: Exactly. All the training had to be translated into local languages so that people could buy into it and support it, and it had to be delivered by local people as well.
R: So did they use the kind of training where its CBT (computer based training) and you’re forced to go through it in a process and click drop-downs or was it a little bit more snack at your own pace and understand?
B: So a proper training programme was run, and some of it was CBT but other parts were knowledge tested through fun on the way through the process. The whole thing was supported by real people; it wasn’t just CBT, it was real investment in real training and properly done.
R: Its interesting, a word i’ve not heard in the last 8 years or 9 years that I heard really early on in my careers was floor-walkers.
I’ve heard super-users, but you used to have floor-walkers, and i think as business has become more global floor-walkers are probably not a thing because collaboration tools have got in the way.
B: But having someone to support you on go live, hand-held support, you can’t beat it. And it’s only a small investment.
To view the third and final part of the interview where we discuss the levers with the biggest effect on SAP success, click the link below.