- SAP Managed Tags:
An issue I ran into the first time I worked with a hybrid SAP & SuccessFactors situation was that although the integration is mostly already defined, it wasn’t explicitly clear to me how the objects in each system’s data models lined up. I thought that completing this activity was important so we would be making good design decisions for today as well as down the road if/when a customer is completely using SuccessFactors for HCM.
I decided to write this blog because I wish that something like this had been available to me when I first started working with hybrid model projects. Hopefully this will help some other folks out there understand how their two data models could/should work together. It should be noted though, that what I’m about to write assumes that while a customer is not immediately using Employee Central, they are considering it eventually. Onwards!
SAP object: Person
SuccessFactors equivalent: Incumbent
Explanation: Starting easy. This one is a no brainer. If you struggled with this one, it’s probably best to just give up now, right? The below screenshot illustrates the core SuccessFactors org chart which is based on Person/Incumbent. Honestly I’m sure you know this, but I don’t think you can create any SuccessFactors document without including a picture of Carla Grant, so here’s where I take my shot…
SAP object: Position
SuccessFactors equivalent: N/A
Explanation: This is why I made the caveat about not using Employee Central (EC). If you’re not using EC, then, there’s no position management within SuccessFactors. Succession, though, is an example of a module that is going to need positions in SuccessFactors. If you’re a hybrid customer doing Succession, it’s very likely you’re going to need to build a daily position integration from SAP over to SuccessFactors. SAP does not deliver this integration, so you’ll need to create it. However, like most of the SuccessFactors imports there’s a pretty easy to follow template available. Beyond that there’s a ‘title’ field on the employee interface (commonly referred to as the demographic file in SuccessFactors parlance) that’s a good spot for the position title for an employee. The SAP delivered program does not populate that on its own, you’d have to use their provided BAdI to drop in the position title. The overarching point is that if you’re not using EC or Succession; don’t expect to look things up by position in SuccessFactors.
SAP object: Job
SuccessFactors equivalent: Job
Explanation: There is a job in SuccessFactors and like position it’s more complete if you’re using EC. Before EC introduced Position Management recently, the SuccessFactors job was really the first direct connection of OM to an employee. The SuccessFactors job is used for a great many of the same purposes it is in SAP (ex: compensation pay ranges or security authorizations), but it also comingles with some functions SAP traditionally did at the position level. Most of SuccessFactors Recruiting keys off of the Job object. SAP passes the SAP job to the SuccessFactors job for an employee in the demographic file and in my opinion it’s important for hybrid customers to not tinker with that design concept as they potentially prepare themselves to move to EC one day. You’d hate to repurpose the SuccessFactors job code to be SAP position or something and ultimately regret that move when you went to EC and wished you had just done job for job.
SAP object: Org Unit
SuccessFactors equivalent: Department
Explanation: This one isn’t really so much an object in a hybrid situation as it is just an attribute of a person. You can’t assign any attributes to a department without EC, it’s essentially just to help filter employees within the tool and providing some options to limit authorizations by department within Role Based Permissions (RPBs).
SAP object: Job Family
SuccessFactors equivalent: Role
Explanation: So here we start getting a little bit nebulous. First – a disclaimer – when I say role, I’m not talking about security roles in SAP or Role Based Permissions (RBPs) in SuccessFactors. In my opinion, the right match for the Role object in SuccessFactors is the Job Family, but I can certainly see the temptation to use the SAP job for SuccessFactors Role. Role is used in a number of components; from Recruiting to identify competencies of the role you’re hiring, to creating Talent Pools (similar to Successor Pools in SAP) within Succession. You may have noticed in the Recruiting screenshot you had to drill down a few levels to get the job code for a requisition. In SuccessFactors jobs are subordinate objects to roles. In the screenshot below you can see the superior/subordinate relationship of Roles to Jobs. Billing Coordinator is the Role, which is the parent of a Job (also named Billing Coordinator) and 2 other jobs which you could find within the ‘edit properties’ link.
So this is a good point to indicate to you that in SuccessFactors, competencies (quals/skills/whatever you want to call them) are constructed to be stored against the role in SuccessFactors. This creates a bit of inflexibility in SuccessFactors that you may be used to enjoying in SAP. In SAP you could apply competencies at a number of OM objects. You could place them at Position, Job, Org Unit, Job Family and Functional Area . This created nice flexibility for a customer to do things like apply certain competencies for entire segments of the business at the highest Functional Area and then let it inherit down through SAP’s OM job architecture.
While SuccessFactors doesn’t offer that ‘trickle down’ inheritance, it does offer an interesting alternative. With a little bit of work on a client’s data model, you can apply competencies to any standard field in SuccessFactors. For instance, if you were sending over each employee’s career band as one of the custom fields on the employee interface, you could theoretically assign competencies to those career bands. Then that assignment could work in concert with the competency assignment pictured above to create a full skills profile for an employee. You could theoretically have an officer who inherited a number of job related skills through the assignment of competencies to the Role that his or her Job is tied to. Then you could additionally assign certain officer level organizational level skills to the officer career band. Then that officer would have a complete profile that could be measured against in a tool like performance management. How many SAP clients have struggled for an easy way to split up their competency models by career level without doing a whole lot of maintenance or fancy footwork with their job catalog?
Anyway, back to Role. Roles are the child object of the SuccessFactors Job Family (which we are getting to), but SuccessFactors also allows users to create additional filtering for their Families using a handy feature called Job Role Tags. There you could group your roles by various picklists to allow for easier searching. This is a valuable tool for something like SuccessFactors Recruiting where you don’t want candidates to have to suffer to find the right Job. So first a user would select (for example) a country, and then they could find all of the families and roles that had been mapped - via an import you've created and uploaded) – to that country. That would alleviate job seekers from having to potentially sift through openings for locations that they weren't interested in.
It’s my opinion that this SuccessFactors object translates most cleanly to SAP as the Job Family, but I could see a scenario where an SAP client converting did not have Job Family in SAP, and chose to duplicate the SAP job as the SuccessFactors Role, but that would require utilizing a separate import to import the SAP data over as the SuccessFactors Role data. If you didn't do that, then your list of Roles would be out of date with SAP and your list of Jobs in your two systems as soon as you went live.
SAP object: Functional Area
SuccessFactors equivalent: Job Family
Explanation: This is another somewhat nebulous one because like Job Family, the SAP Functional Area is not used by a tremendous number of customers, so there may be nothing to move over. But even if that’s the case, the purpose of the object is largely the same. Both SAP Functional Area and SuccessFactors Job Family are about grouping their children objects. You won’t see any real ‘functionality’ driven off of either of these objects, other than giving your object grouping a place to begin. Here’s a very low-tech illustration of how all of these objects we've discussed relate to each other:
SuccessFactors: Job Family -> Role -> Job -> Incumbent
SAP: Functional Area -> Job Family -> Job -> Position -> Person
In SAP you can create Functional Areas, Job Families, Jobs or Positions without relating them to each other as parent & child. In SuccessFactors, you cannot create Roles without first creating Job Families. The screenshot below basically shows the SuccessFactors Job Family administration, and this is more or less all there is to the Job Family (which is why it so closely matches Functional Area in SAP).
Honestly there’s a lot more to type here, but I don’t want to drone on forever. This is a pretty good starting point to offer one person’s take on how you’d line up your base OM objects within SAP to their corresponding destinations in SuccessFactors.
As you can see there’s nothing other than Person/Incumbent that really leaves you no choice in the matter – from a mapping perspective. I would be interested to see if there are any other opinions out there about how to line these up , or if any customers have SAP data models that would lend themselves to aligning to SuccessFactors differently. For instance, if a customer was never really planning on going to EC, would it be more beneficial to send SAP Position to SuccessFactors Job and then SAP Job to SuccessFactors Role? I haven’t seen that scenario, but I would be interested in hearing if anyone else has ended up with that design, or any other design of integrating these two data models.
20 Comments
