Expand +



Sven Ringling's Thoughts on Over Resourcing of Cloud HR Projects

by Ken Murphy, Editorial Director and Sven Ringling

September 26, 2013


Ken Murphy: Hi, this is Ken Murphy with SAPinsider. I recently had a chance to speak with Sven Ringling, the co-founder and senior partner of iProConLimited, a London-based HR consultancy. Mr. Ringling is an expert in SAP HCM, focused primarily on project management, HRIS strategy, and business benefits.

He recently wrote an interesting blog on the SAP Community Network, where he expressed more than a little dissatisfaction with the practice of service vendors and system integrators over-resourcing for cloud HR projects. Mr. Ringling talked about this and some other issues pertaining to cloud vs. on-premise HR installations during our interview.

Here, first, is what he had to say about over-resourcing:

Sven Ringling: I think that the reason for this is why I actually went into this ‘rant.’ Because sometimes it just makes me angry. It seems that most of the reasons for this have nothing to do with anything customers need or want, and that sometimes drives me a bit angry because it gives a bad name to our profession. So why is it? Well, I think that the reason is quite simple: vendors – not software vendors, but vendors of software services – and system integrators, agencies who provide resources, they just stick to the old models for two reasons. One is it’s always easier to stick to the old model. And the other is that they have the resources there, and they’re reluctant to reduce the number of resources they can sell. I think that’s one of the major reasons; it’s just not lucrative for the bigger players in the market to switch to the new model, which would require significantly less resources for comparable projects. So that’s the major reason.

"If I want to be a little bit sarcastic, I could say in the on-premise world change management was often done with the bank account."

- Sven Ringling

KM: Mr. Ringling also talked about some of the skill sets needed for SaaS implementations, as opposed to on-premise models, and what project teams should know before setting resources concerning personnel.

SR: Obviously, the first skill you need is you need to understand that particular cloud project that you are implementing as a consultant. It sounds really obvious, but if you look at how some of those products gain market share really rapidly like SuccessFactors which would be involved primarily coming from an SAP HCM background, it’s not that easy to actually find people who have good strong experience with that particular product. So you certainly need to be realistic; you can’t expect people with five-plus years of experience making up your whole project team. But still, you would need some people on your team who really understand that product and have implemented it before, not just gone through the training.

But that skill obviously needs to be complemented by skills you’ve needed on on-premise as well. So it’s technical as well as process skills, but I think the focus is different, it’s a different mix. You don’t really have to care a lot about the platform, so that whole Basis stuff, you would have to deal with in on-premise. And that’s what your cloud provider is dealing with for you. Although that’s almost going down to zero. Programming skills may not be required at all, or also on a very low level. It’s getting more if you go hybrid and if you talk about a lot of interfaces, there may be some more programming skills required, but still it’s a much, much softer emphasis than it would be in a traditional on-premise.

KM: I asked Mr. Ringling about change management in a cloud installation vs. on-premise, and how important it is to change the on-premise mindset when dealing with the issue of change management.

SR: If I want to be a little bit sarcastic, I could say in the on-premise world change management was often done with the bank account. Rather than talking with stakeholders and make them adopt best practices from HR inherent in the system, organizations would often just have taken money and paid it to some more programmers to change the system, even if it wouldn’t really make sense just to overcome resistance to change. And that’s no longer possible to that extent. If you are in the cloud, of course you cannot just change everything. So that’s why I think it’s a fundamental difference in change management where there really is the requirement to sit down with the stakeholders and say, “Look, this is what’s our old process. And we have to change it, because this product comes with a lot of best practices but it doesn’t cover what we’ve done in the past.” And that’s why it’s actually not a bad thing, it’s just different – it’s not worse. This conversation, it sounds really simple, but from my experience in the on-premise world it’s often avoided. Maybe to some extent because system integrators didn’t really benefit from having these conversations. They benefited more from big change requests, and getting a couple of programmers more into the project. So why invest a lot of time and nerves to convince customers that they shouldn’t pay you $50,000 more?

KM: Mr. Ringling shared with us his thoughts around the question of HR ownership between users and IT in a hybrid approach.

SR: There’s certainly the expectation that with the cloud product, HR would gain some independence from IT, which is sometimes seen as hoarding thing by making things more complicated than they have to be. To some extent, it’s right – that with a cloud product, there’s more an HR department could do in terms of configuration and then really own a bigger part of the system. However, this obviously needs the right training which usually your cloud vendor will provide. However, it’s important at the start of the project you discuss what’s the ideal model for your organization with your vendor. And then they provide the right training for the right people. For large organizations, it’s quite important that if there’s ownership in the HR department, there’s some units be it in IT or HR will make sure that some level of harmonization is achieved and it doesn’t all fall apart because each HR department does completely different things in the system.

In the hybrid world, it’s a bit more dangerous because if HR has the ownership in the cloud part, they don’t necessarily understand the implications of anything they change on interfaces to on-premise systems, or even to other cloud systems. So there’s still complexity which is not necessarily simple if you work just within SuccessFactors or any other cloud product. But there needs to be some awareness of what might have implications through interfaces, and that’s the point where IT has to be in the boat. So where HR can gain some independence, they really shouldn’t stop talking to IT. If anything, it’s getting more important that those two teams are in constant conversation.

KM: Finally, we asked Mr. Ringling the major factors to consider when rolling out a global hybrid project.

SR: Basically the challenge is in global projects are quite similar whether you talk about a cloud or on-premise. It’s about the global harmonization to make sure that it’s really one system with 50 variations rather than 50 completely independent sets of configuration. The global vs. local discussion, what needs to be controlled centrally, what’s local, and more than anything else are the cultural differences which lead to so many misunderstandings in the design stage, in the implementation stage and when the system is used. So that’s I say – if you know the typical challenges from on-premise, and you know the typical challenges from cloud in one country, there’s not that much that’s being added to that.

To some extent, a SaaS product would probably make the global rollout easier, because the higher degree of standardization is built into the concept, so you wouldn’t even have the temptation to hand out modification piece to local IT departments to change the coding of your product as you would have in an SAP on-premise implementation. You wouldn’t have all those custom developments per country, so that’s kind of taken care of by the system. But the same advantage also makes it really important that you make sure that you have the right fit for all relevant countries before you even start. Because if you say in your mother country, “That’s a beautiful product, let’s use this and then see how we roll it out,” there’s not too much you can change if halfway through your rollout you realize that it works perfectly for North America and Europe but it doesn’t work for South America and Asia. You would have more ways to deal with it in a typical SAP on-premise where you would have some extra custom developments which obviously cost a lot of money, but you could still somehow deal with it. So I think if you go cloud, you just need more advanced planning to make sure that you don’t end up in a dead end. But with that done, because as I said the harmonization is built into the whole cloud idea, you would probably have fewer problems along the way.

KM: This is Ken Murphy with SAPinsider. And you’ve been listening to an interview with Sven Ringling, who is a regular contributor to SAPinsider. Mr. Ringling is on Twitter at @svenringling.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.


10/3/2013 5:17:25 PM

Thanks for the nice chat, Ken!