The Transition from doing SAP HCM Consulting to SuccessFactors ?
Somewhere back in what seems like a million years ago (2005) I was working at a global corporation when they purchased SAP. I joined the project team and spent the next several years learning most of the areas of the SAP HCM on-premise suit as well as managing the production support team. For the past three and a half years have been doing independent consulting, specializing in the Talent Management modules of SAP. Prior to getting into SuccessFactors, I have worked pretty extensively with the Talent/Succession module, Nakisa, LSO & Performance Management and my SAP origins come from OM, PA and HR interfaces, which gave me a really good base to consult in the Talent Management modules.
So obviously when your competitive differentiators in consulting are your skills within the SAP HCM Talent Management modules, you are going to be acutely aware of SAP purchasing SuccessFactors and adopting the SuccessFactors modules as the ‘go forward’ solution. These days I actually consult in both SAP HCM on premise and SuccessFactors and its very interesting to see the differences in the two solutions during implementations where you can appreciate the different strengths and weaknesses of the various software delivery types.
How do you go about learning to consult in SuccessFactors?
I was extremely fortunate to get connected to SuccessFactors partner Blue Ascent that was made up of a number of expert level SAP HCM consultants who had worked together on various projects in the past. They really committed to taking people that were experienced and knowledgeable in the on-premise SAP HCM world and giving them opportunities to ramp up in SuccessFactors in a way that was not reckless to their customers. What I mean by reckless is that it’s obviously no secret, and has been well documented on Twitter and SCN that every SAP HCM consultancy on the planet is trying to build a SuccessFactors practice and I’m no exception to this as prior to the acquisition; my SuccessFactors experience was not impressive. What’s reckless though is that it’s very easy as a consultancy to sell work, and then staff it with people whose only SuccessFactors experience is a 3 week crash course in SuccessFactors and let them try to learn on the job.
In my own case, I first attended the core SuccessFactors mastery course that provided exposure to the fundamentals of SuccessFactors (the instances, provisioning, Success Factory, etc.) and covered the Performance Management, Goal Management and Employee Profile modules. After that, I took Employee Central Mastery (this built on the first course and introduced the use of XML with SuccessFactors), Succession Mastery as well as Compensation Mastery and then soon I’ll be taking a Workforce Analytics course. So now I’ve got all this training, but I still didn’t have any real world implementation experience and formal training is good, but it never has the unique requirements that you’re going to get on a real project. For real world experience, Blue Ascent partnered with another group that was a SuccessFactors implementation partner prior to the acquisition and provided me with two excellent training opportunities. In each project I had a mentor consultant who led the design sessions, was the primary configurator and decision maker, but I was allowed to learn from them and execute tasks throughout the project. Obviously since these projects were training roles, the consulting rate reflected that, but it was more than balanced out by the experience and long term opportunity from getting real SuccessFactors project experience. From the customer perspective, I was still providing some value, but I was learning the module with the support of a lead consultant. This training has proven to be invaluable, as after those 2 projects, I’ve been able to take on SuccessFactors projects as the lead consultant with the experience and training needed to be successful.
How does SuccessFactors training work?
Well, I’m obviously speaking from my own experience here as SuccessFactors has several training delivery methods, but here is how it worked for me. I took all of my classes virtually with the introduction mastery course spanning three weeks though I’ve heard that since I took that first class, the introductory class has changed somewhat and Performance Management and Goal Management are not covered. The first two weeks of the mastery course were going through the lessons and the class would meet daily for an hour to ninety minutes online. In the class the instructor would have one or more students demo their system configuration for the group and after that the teacher would begin the next day’s lesson explanation and walkthrough. Then the students would read the lesson materials and complete the lesson configuration sometime before the next day’s class.
The other mastery courses were all only two weeks long, but those classes all had prework activities that had to be completed before the first day of training. What was constant among all classes was that the last week is a case study, which were always a round of configuration based on the customer’s requirements. The last day of the training is always the consultant’s demonstration to the client (the instructor). In one class I took it was a ‘live’ presentation over the phone, but usually they were screen recordings (with audio) that were posted on the class Jam group. I became a big fan of the screen recording features within Jam I predict it will completely revolutionize how clients can deliver training and issue resolution, hopefully spelling the end of the dreaded BPP. Regarding the actual training classes, I will confess that when I readied for the first course, I thought it’d be quite simple, but for that course and the others, the work effort is no joke and it was a noteworthy time commitment to do it right.
How do you compare learning SuccessFactors to SAP?
Well, the learning curve isn’t quite as steep with SuccessFactors, simply because SAP is built as part of ECC and requires so much peripheral knowledge to be an expert in the space. Since SuccessFactors is largely focused Talent Management, you don’t need knowledge of how to do things like, run a trace, deactivate a delivered BAdI to turn your own on, look through short dumps, etc. That doesn’t mean SuccessFactors is a piece of cake as like any software it has its nuances and is constantly evolving with its rapid release of four updates each year. Another challenge to picking up SuccessFactors is that it lacks the community that SCN provides in SAP and even though there is a community for SuccessFactors partners it’s not nearly as robust as SCN. On the plus side though, you’ll never see a SuccessFactors consultant get on and post that they need the entire configuration for module X to be sent to them by the next day like you might on SCN.
Even though it’s a new software tool and a new delivery method – at its core – SuccessFactors is still trying to accomplish the same goals that the SAP on-premise modules are. Since a big part of the consulting skillset is providing input and options on a company’s business processes that are being designed to work in concert with the software, good consultants will find themselves having the same conversations with a client regardless of the tool they’ve chosen to implement. Even with a competing product like Workday – every customer who’s using that for Talent Management is going to have a discussion about whether or not succession is a Manager Self-Service activity or not and SAP on-premise or SuccessFactors are no different. A good consultant will be able to counsel a customer on the pros and cons of whatever the design decision is and explain how the chosen software tool will (or could) interact with that decision. I have been through enough projects and seen enough Talent Management business processes that was just a matter of learning how SuccessFactors accounted for those processes and what the configuration choices were. Once I picked those things up, I can apply that information to customer design sessions, just like I do with on-premise SAP.
What are the some differences to being a SuccessFactors consultant as opposed to being an SAP consultant?
There are really a lot of interesting differences, too many for me to cover in one answer, but I’ll note some highlights. First – and especially for independent consultants – a major difference is that when you’re an SAP consultant you can be brought onto any client to work on any project and you don’t have to go through an SAP partner, nor does SAP need to be informed. With SuccessFactors, it’s not quite the same as when you work on a SuccessFactors project, you generally need to work through a SuccessFactors partner. Additionally, due to the nature of SuccessFactors configuration, a consultant is granted access to the customer’s provisioning environment (provisioning is the ‘backend’ of SuccessFactors configuration – stuff a client cannot do on their own) by SuccessFactors directly. It will be interesting to see how the consulting dynamic changes as SuccessFactors continues to grow. Will work always be moved through partners? Will there be avenues for independents (who are generally experts in their areas) like there are in SAP?
Another consulting difference I’ve discovered is that SuccessFactors projects are generally staffed without the support structure that you’d have in an on-premise project. There’s no portal person, no basis person, no security person or no developer. This is theoretically because those aspects are either handled by the client or by SuccessFactors, however there are still some technical components, which require attention such as various interfaces to and from SuccessFactors. Some integration can now be handled by SAP PI, but there are a lot of files you could be importing into SuccessFactors – depending on your implementation – and only a couple of the big ones are handed via PI. There’s also the FTP setup and coordination, and don’t forget the Single Sign On (SSO) setup. As a consultant you’re expected to be the point person for the SuccessFactors side of those items. Lastly, when a client purchases SuccessFactors they usually have internal IT staff who will have technical questions, and you will be the first point of contact for those questions whereas with an on-premise implementation those questions usually would go to another consultant.
On a similar line of thinking, what are some of the differences with SuccessFactors and SAP on-premise projects?
From a project perspective, there are obviously differences too. I sat through my very first SuccessFactors kickoff project and laughed to myself as I watched the lead consultant pull up the client’s SuccessFactors instance 10 minutes into the meeting and demonstrate how to execute Succession Planning. I compare that to an SAP project where the first number of weeks of a project are spent getting your environments setup, the portal running, setting up access and just generally ironing out those fundamental setup issues. The SaaS model creates such a smoother project experience without having to having to hassle with the usual project functional/security/basis/portal hassles and from a customer perspective, this is such a big win. SAP customers have to feel helpless sometimes as their consultants go around and around with the bowels of SAP setup (“hey, it’ll be three weeks before TREX is setup, here are some screenshots you can look at until then”).
Of course, that’s the cup half full and the cup half empty is that with SuccessFactors, discussions of customizations are basically non-starters. In SAP, you can change almost anything because the customer has the source code and SAP provides so many custom code opportunities with BAdIs. Since SuccessFactors has the source code, when your customer tells you that they don’t like how something works in SuccessFactors and it can’t be configured to work the way they want, their only recourse is to contact SuccessFactors and ask to have this feature included down the road. In the SAP on-premise world, getting customer requests turned into a reality is not a simple proposition. I can say from my own experience consulting in SuccessFactors that the requests for customizations are much fewer than they are when I consult in SAP (though they still happen!). It’s hard to speculate exactly why this is but I know that in SAP quite often we find ourselves customizing something simply because we customized something else earlier and these changes tend to build on each, like little white lies tend to build on each other to cover the earlier ones. Maybe in SuccessFactors, because we haven’t already customized we don’t have to hassle with trying to cover up for our earlier deviations. Maybe customers already know going in they can’t ask to customize to they just accept the out of the box solution whereas in SAP they can’t always resist the temptation to say “the process drives the software, not the other way around.”
When you look at the Talent Management offerings of SuccessFactors, you can tell that it has the advantages of being built more recently and exclusively for Talent Management, whereas SAP HCM Talent Management was built to fit into the mold of the rest of SAP. A great example of that is security as in SAP you spend quite a bit of time in this area and likely have at least one person dedicated exclusively to HCM security navigating the murky waters of structural authorization profiles where in SuccessFactors that work can all be done by a superuser. For those of us who have seen both sides to security (SAP and SuccessFactors), it is pretty amazing to see the differences. SuccessFactors security is administered through something known as Role Based Permissions (RBP) and a superuser (note – does NOT need to be a dedicated security expert or even a functional consultant) can go in and in a matter of about 90 seconds can say that everyone who is a manager should have access to function X, Y and Z with edit access to fields A, B and C for all direct reports and then one level down of indirect reports. There’s no authorization profile assignment to the job or to the position. There’s no “now that you’ve done this wait 12 hours for the job to pick up”. There’s no ‘you need to follow the security request process, check back in 15 business days’. It’s there, and it’s done, and it’s very impressive. My point of this is that because SuccessFactors was built more recently than was SAP HCM, it benefitted more naturally from advancements in technology.
Any words of wisdom for those looking to make the transition?
Purely my own perspective, right now there are so many customers out there who are legacy SAP HCM customers and are interested in the SuccessFactors modules going forward. Those customers are desperate for people who can help them appreciate the differences between the two systems, who can help integrate data from SAP to SuccessFactors (because that IS an effort) and help them use SuccessFactors in a way that will not eventually burn them should they ever end up being full cloud customers and not just hybrid customers. Seize the opportunity to be that source of information for your customers.
Additionally, I would say try your hardest to get connected to a couple SuccessFactors projects as a trainee like I was fortunate enough to be able to. People may think that SuccessFactors is straightforward to configure, but speaking from experience, there are a lot of nuances to configuration and (like any software) there are a lot of tricks of the trade that had I been the lead consultant on without any training with real clients, I would have made poor consulting decisions on behalf of my customers.
