With the SuccessConnect user conference a month away, now’s the chance to frame issues I’ll be digging into in Vegas. For the first piece, I’ll break down some of the bad practices Marson and Pazahanick warn customers about.
SuccessFactors "bad practices"
1. Assuming that SAP HCM practices that work on-premises will translate to the cloud. Marson:
For those customers that come from an SAP background, it's natural for them to always think, “Well, what did we do in SAP?” Although you can do some of that in the cloud, it just doesn't always translate, because that's not how SuccessFactors was designed... A lot of customers think that the technology's going to solve their problems for them, so they don't do all this HR work up front. Simple things like, “Let's look at our grade catalog, or our job catalog,” or “How we do salary gradings and leveling and what not?” Then they're trying to fit this very crazy way of doing something into the cloud. Yeah, you can [force] it in but it shouldn't really be how you're doing things.
2. Getting lured by a “cloud washed” services firm that isn’t an excellent partner.
At diginomica we’ve poked fun at software vendors for cloudwashing their product offerings. But as Pazahanick warns, services firms can also cloudwash their capabilities:
Some partners have put up a shingle to say, “We are a cloud consulting firm.” They have all the official cloud partnerships. They are not doing cloud implementations. It's a challenge for some companies to do cloud implementations. With cloud implementations, there's more business involvement. Some of the stuff Luke just talked about - you might not even need a consultant for that. You don't necessarily need a consultant to look at every one of your business processes and bring what they call a “best practice.”
3. Loading up on too many consultants. Pazahanick and Marson contend that SuccessFactors projects require not only a different type of HCM consultant, but less consultants, period. Pazahanick shared this update from a recent SuccessFactors analyst event:
There are plans to start holding partners more accountable… One thing SuccessFactors promised to do was - and they're just starting this - is to start to keep an eye on which partners are having more problems with their implementations. Which partners are maybe bringing too many resources for this project? You do not need as many consultants to implement cloud HR as you did in the on premise world.
Data migration and change management still matter
Ultimately, what Marson and Pazahanick recommend is a mix of new cloud consulting skills, and overlooked tactics that smart customers have always used. Some old favorites take on new flavors, such as data migration and change management. As Marson said on SAP HCM Insights:
Just because a cloud solution might be easier to use, it’s still not the most simple thing to use in every case. There are still certain complexities… I think customers shouldn't be underestimating the change management effort required, especially if they’re going to be pushing out more self-service capabilities to managers or to employees, or even to HR business partners.
Data migration isn’t easy either: ”Even if you're migrating from SAP to say Employee Central and you use the data migration package that SAP provide, there’s still a lot of effort around that, and there’s still certain elements that have to be manually done.”
Which brings us back to the consultant’s role in change management, helping customers to grasp the new system without overstepping:
Of course, there’s education that goes along with that, because the client knows their data best. They know their business best, so we have to work to constantly educate the customer as we go along, to help them be able to build a change management strategy to help with data migration.
"There's no competitive advantage in core transactional HR"
The bad practices outlined by Marson and Pazanahick are informed by the view that there’s no competitive advantage in core transactional HR. On the Bogner podcast, Pazahanick cited this example:
There are some big customers that are moving from SAP to Employee Central. There’s hundreds of Infotypes - it's a global company… There’s not always a corresponding place to put them in Employee Central. Of course, you can create custom fields and do all that, but you have to step back on some of these things and say, “There was a field for it. We put data in there fifteen years ago. We’re not running any reports on it. Even if it’s there, we’re not doing anything actionable with it. Do we really need it in our new system?”
With cloud projects done right, Pazahanick sees a welcome shift from exhaustive requirements gathering to an agile, collaborative approach:
Look at your business. Understand where you want to go. One thing I really like about cloud projects is the more agile methodology of getting requirements, building, getting requirements, building. That's the way you lead yourself down a road to easier success, rather than “Let's gather all the requirements and walk away and come back.”
Marson brought up Den Howlett’s warning about “legacy thinking”. One huge change from old to new: working on multiple, remote projects. Marson:
Just because someone was a great on-premise consultant, there is a different mindset [in cloud consulting]. One of the big things is being able to work on multiple projects. Being able to work remotely. Not every consulting firm is set up with that business model either, to be able to have their team working on two projects at the same time.
The wrap - changing consulting is a work in progress
A new cloud consulting model is emerging, one that works for SuccessFactors but applies to most projects that are agile, leaner in cost structure and business-focused. Some of the finer points are debatable, leaving customers to find the right mix. Example: the ideal combination of remote versus on-site consulting time.
Marson believes that time balance should vary based on the nature of the project. In the case of Performance Management, which is easy to configure, perhaps you could handle four or five projects at once. But for core HR projects, Marson cautions against that:
When it comes to a core HR implementation, you've got multiple processes. You've got lots of complexity. Even working on two projects at once can be challenging, depending on what the projects are.
That’s why Marson pushes back against a remote-heavy model:
I don't agree with the on-premises model of this 100% on site, but I don't think five or ten percent is good either.
He sees a project management complexity that would strain even the savviest project lead:
I've come across consultants doing six or seven projects, and I just think, “How can they do that? How can any project manager be able to manage the part of the project that involves them when they're doing so much else?”… I just find it remarkable that systems integrators are managing the people like that.
For now, Marson advocates 40-65 percent on-site/off-site:
40 to 65 percent seems to be the right level. Because ultimately you have to have a lot of interactions with the customer. You have to do a lot of problem-solving and process design and rework.
On our video chat, we also got into a passionate/detailed view of the state of SuccessFactors certification - a topic I’ll return to. If you don’t want to wait, check out the full audio, or play it below.
Get the HCM podcast on iTunes.
End note: some of the podcast quotes in this piece were tweaked slightly for reading clarity.