Skip to Content

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…

SF_Person.jpg

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.

SP_Position.jpg

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.

SF_Job.jpg

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).

SF_Department.jpg

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.

SF_Role.jpg

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).

SF_JobFamily.jpg

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. 

To report this post you need to login first.

20 Comments

You must be Logged on to comment or reply to a post.

  1. Chiara Bersano

    Chris, this is an excellent and very practical blog that I can only recommend highly. It does a great job of highlighting the differences between EmployeeCentral and the Talent Suite, while eloquently answering the questions about OM on the on premise side, asked by all customers. THANK YOU for writing it.

    (0) 
    1. Chris McNarney Post author

      Hi Chiara:

      Thank you for the nice comment.  Do you see people mapping objects between the two systems differently than this?

      Thanks,
      Chris

      (0) 
  2. Brandon Toombs

    This is a great blog!  Thank you for sharing your project-based insights.  Going to be very valuable to the community.  

    I hope to have more time to engage in a discussion later when I have more time but for now I thought I’d at least tell you ‘thanks’.

    Brandon

    (0) 
    1. Chris McNarney Post author

      Hey Brandon:

      Thanks much.  Hopefully it helps some folks as the first time I tried matching the data models up it was a little bit like feeling around in the dark.

      (0) 
  3. Luke Marson

    Hey Chris,

    Another great blog and extremely informative – it’s no wonder when you and Jarret combined that your Q&A blog blew up the hit counter.

    You make a great point about EC as a foundation if customers really want to use position and department objects fully. Interestingly a lot of customers are beginning to run with EC in the US before Talent, which is something I don’t think SAP or the community expected. This will of course offer a lot of value to those customers over the long-term.

    Keep up the great work!

    Luke

    (0) 
    1. Chris McNarney Post author

      Thanks Luke:

      I’d love to take credit for the traffic on that Q&A, but Jarret could post a meatloaf recipe on SCN and it’d get a couple thousand hits.

      I found your remark interesting about EC in the US. I will confess I hadn’t seen that thus far, but I obviously don’t have my finger on the pulse of every project.

      Really appreciate the comment.  See you around the interwebs.

      (0) 
    2. Sylvia Chaudoir

      Definitely agree on the point about EC. I was surprised to learn that customers not using EC had to choose between job and position to map to SF for stand alone components. Seems a bit limiting and puts a much heavier burden on integration having to figure out what really to send to SF to be most useful. Looking forward to seeing your new book Luke.

      Great article Chris!  Thanks for sharing the info. 

      (0) 
    1. Chris McNarney Post author

      Thanks Chris, I appreciate the note.

      Random aside – I downloaded Google Keep on my phone last night after reading about it on your Twitter feed.  Thanks for the heads up.

      (0) 
  4. Jyoti Sharma

    Hi Chris,

    This is definitely a very good starting point. It is encouraging for me to see that the mappings you suggest are aligned with what I have been working on to prep for a SAP-SFSF hybrid implementation.

    As Luke mentioned, the theme in US seems to be EC before Talent and something like this that you have already implemented definitely gives a headstart to folks.

    Thanks for sharing as it does take some of us to create light for others. I am heavily working on custom FOs and generic objects, will post a blog soon, but if you have questions in that regard, do not hesitate to reach out.

    Here in US the role of EC for Successions Management has been a great driver for customers to re-think their options and actually opt to implement EC.

    Warm Regards,

    Jyoti

    (0) 
  5. Ameen Syed

    This is really good Chris…..But those using with out EC will have limits.

    Great blog…. thank you very much.

    Regards

    Moosa

    (0) 
  6. Paul Hopkins

    excellent blog!

    > I don’t think you can create any SuccessFactors document without including a picture of Carla Grant

    yes, that (she) is quite noticeable!!! 😉

    (0) 
  7. Sirisha Kanchi

    Hi Chris

    Thank you for this great blog  and give all the beginners in SFSF a great start to consider while integration.

    Regards

    Sirisha

    (0) 
  8. Katsia Barshchynskaya

    Hi Chris,

    I’ll add my voice to the chorus of those who have already thanked you for this informative blog. Would be interested to hear if you or others following this post have seen any alternative mappings being used by customers?

    I would also like to ask whether it is possible to maintain additional attributes for the job architecture objects in SF such as career stream/path and job levels – can these be maintained on the job/role/job family as custom fields?

    Noticing that in your inheritance model for SF you have linked Job directly to the Person. Is this the standard setup in SF or is it possible like in SAP to assign Job to Position (and whether there would be any (dis-)advantages of doing so).

    In our organisation we have introduced an additional job architecture level as the top-level object due to the conglomerate nature of the business, for reporting purposes. Would it be possible to translate this object to the SF set-up and later add upwards relationships from job families, which otherwise would be the root object in SF?

    These are quite a few questions from my end, but I’d greatly appreciate if you could point me into the direction of more relevant information on the subject. Thanks once again for sharing the valuable information.

    Kind regards,

    Katsia

    (0) 
  9. Andreia Mendes

    Hi, thank you for your blog post, do you have any information about the OM relationships between objects and mapping to Successfactors? Thank you and regards, Andreia

    (0) 
  10. Elio DAmore

    Thanks Chris, very valuable material and clear explanation.

    I’m supporting a deal where customer opted for Hybrid scenario (SAP HR as the hr transactional System of Records and PM-GM-SM-CDP-360 and Calibration modules configured in SuccessFactors). They need to have OM objects in SFSF even if they are not going to implement EC for this phase. What you have explained is what we will implement.

    (0) 
  11. Veera Prathap

    Dear Chris,

    Thank you for the nicely articulated information. Is the workaround for Job Code to Job mapping to resolve the challenge for inheritance of competencies using custom object competency attachment still possible with SF V12 Acceleration udpate?

    (0) 

Leave a Reply