Discussion: With Cloud HCM we Should Buy Capabilities, not Processes
I’d like this post to be a discussion rather than another rant or lecture from me, so here is the statement for you to tear apart:
“With cloud HCM solutions we should focus on buying capabilities, not processes any more.”
And here just a little explanation what I mean without trying to defend the position too much already (I reserve the right to defend it in the discussion as it goes along):
- For buying decisions in the on-premise world, customers would usually define not only the scope the system should cover but map the processes to they want to be used to an often meticulous level of detail. If that hasn’t happened before buying the software, than it would usually happen, when buying the implementation service. So, relatively little time was spent on what the system should do now (and maybe more importantly in future) and a lot of time was spent on how it should be done.
- I believe that this doesn’t give you the best results in the fast-paced world of cloud HCM. Rather than spending up to a year on defining processes, I believe customers should focus much more on the current capabilities the solution would bring them as well as on its capability to innovate and then be open about the process to bring these capabilities alive. If this sounds a little bit vague, it’s because it actually is a little bit vague (the clue is in the name: cloud 😛 ). So, focus much more on what and much less on how. And therefore also getting much faster to actually doing something about it.
This is probably a bit provocative and it doesn’t mean I’m 100% signed up to it yet, but for the purpose of the argument, let’s assume I am, so feel free to attack 😡
Interesting topic, Sven!
It is similar to the concept of minimum viable product (MVP), but related to the processes.
And one of the benefits that SAP marketing is quick wins with easy deployment of standard functionality/Best Practices.
Actually I think, every consultant trying to implement SF has similar thoughts. But the established and linked to the strategy methodology is also very important is such processes like Performance or Succession Managment.
I expect some shift in the solution selection process, as details requirements on detail custom process cases haven't much value for cloud solutions. There will be more focus on concept, direction, roadmap, investments, UI, integration.
Oh Sven....why must it be an "argument"? How about a "lively discussion"? 😛
I see what you are saying...and somewhat agree as "everything old is new again". Buying "capabilities" piece mill or not with an eye towards stringing them together for an overall "best" process sounds very familiar. Back to the "old" days of when companies would purchase a bunch of "best of breed" products and cobble them all together. Companies would do this quite often. But the "smart" companies like SAP (and some competitors that survived the great ERP culling of the early 2000s) would either buy up and incorporate those other "best of breed" companies or develop/copy their own...with the BIG selling point after all this being "no longer do you need to cobble together these products...ours are all integrated!" hahaha
So yeh...from my point of view....it's just the natural cycle of things. 😉 However, it just seems now that it is even easier and these smaller, more niche specific "capability" companies are easier to spring up and address/fit a need ("there's an app for that!"). Sorry that I didn't get more argumentative with you. 😆
Hi Chris,
you know, Germans love a good argument (used to be wars, so I think we've come a long way 😛 )
I think I know what you mean. Looking at individual capabilities in an isolated way gets you to thenold best of breed view easily. But didn't the process view, too, if it wsn't going across solutions? One shiney tool did exactly the process HR wanted step by step and SAP could do the same only after 20 days of BAdI progemming, so the little goals management app was bought.
Is it too cheap a way out, if I say "Integration across all HCM processes" is also one of the capabilities we should be looking for?
I'm not at all arguing against a big picture view of HCM processes to see how they play together.
I'm moremthinking of these projects where processes where mapped to a very fine level of detail. These projects took a year and in SuccessFactors that would mean 4 releases have come while we were discussing the second step in the 3rd exception of the 4th process variant of goal setting as in "If the employee is a sales rep and the goal is a monetary one, they can challenge the goal until 2 weeks after the anual results have been published, if it turns out the overall corporate result was unrealistic (i.e. missed by more than 12.34%). He/she should complain to her direct line manager at the time of goal setting. If that line manager is long term absent, but not uet dead or likely to die, the period can be extended to 6 weeks. After that it's escalated to the next level manager (at the time of goal setting), unless..."
But be it as it may: good points. There probably is a risk of not getting these capabilities onto the road to work their magic together.
Hi Sven,
Completely agree with your statement!
The true challenge in here almost always comes from history and the way companies and people are used to look at their processes. Often companies have a large history in how they came to their current processes, which also took them a lot of time, effort and money.
With this in mind you see most companies are carefull off going trough that whole process again and are often a bit scared of missing something by setting up a new process.
Nevertheless the most successfull and happy companies are the ones that start the project with looking at the capabilities of the new system and are able to adopt changes. For this it is crucial to have strong commitment and decision power during the whole proces.
In my opinion the biggest trap is that companies can't adapt and end up copying the old processes in a new system. When doing this project costs increase significantly and the benefits of using new tooling are lost.
...and often those "old" processes were not only designed based on the actual business requirements but also on technological constraints at the time of inception. Bottlenecks, "waits", complex notifications, etc...might all have been needed only because the technology in use at the time was limited in its capabilities, speed, etc. Sadly, those "pieces" in a process often persist just because "that's the way we always have done it...so it must be needed still".
"In my opinion the biggest trap is that companies can't adapt and end up copying the old processes in a new system." AMEN!
Ultimately, software supports business processes. A good business process should not be defined by the system, the system should support the process. And good capabilities enable this to be possible.
Hi Luke,
it's probably mostly a matter of wording, but as "process requirements" have been used to carve non-value adding details in stone, I prefer to say "Software should support a business outcome", not necessarily a particular process.
I appreciate there are cases, where changing the process would be too expensive or not allowed, even when better ways to achieve the same outcome are available (particularly in regulated context), but imo we should always aspire to understand the business outcome and then find the best way to achieve it with the tools available.
While I agree in principle, the fact is that most businesses are not looking for business outcomes but are looking for process support. In a recent webinar for ASUG I discussed how HR organizations should be tying their strategy to business outcomes and this has downstream impacts within technology implementations, but sadly I still don't see many organizations doing this yet. The Utopian HR world is still far away from where it is, but selecting software with the right capabilities to get to where you want to be (process support or business outcome achievement) is still a critical factor either way.
You are right Luke,
I guess it's a question of which level we can realistically aim at.
Sure we can't expect to (and it wouldn't be very helpful either) to discuss everything on the level of the organisation's Mission statement or the shareholder value target.That would be far to generic.
On the other extreme, it's blocking some of the best options, if the requirement is carved in stone on field level.
Probably best to use an example:
I had a requirement in performance management recently saying: the average rating for all employees in a profit centre unit must be 100 (with <1% margin). Because that's almost impossible to achieve, if you have only one meeting with each individual, but allow for changes in the meetings, they said "ratings are defined and calibrated by managers before the meetings and can't be changed any more". What does this do to the meetings? They are changed from being a conversation to being an announcement, or verdict. Whatever the employee says, the rating stays the same. Very ugly in my book.
But then it turned out that the reason for the 100% rule was that they want it to make sure they stay in budget. So, 2 failures in the process requirement:
a) you can have a much better process, if you let the ratings float freely and then define the factor to turn ratings into money at the very end, so that you are exactly in budget.
b) the 100% rule doesn't even achieve the budget outcome, if, say, the higher paid employees have on average a higher rating. But in the old Excel based process it was the easiest way to get close.
That's what I mean with defining the outcome (stay in budget) rather than process (how do we achieve that step by step).
It's still not realistic to always get there every time - I have to agree with that. But we shouldn't give up trying.