Why positions and job info must match?

[adriangalisteo]

Hi,

This is a question regarding successfactors Employee Central:

Client is asking why is necessary to have an structure of positions and that the job info data has to match perfectly with what is in the position. There is the possibility of leaving the job info fields open to make the desired changes, but if the position is in command and the information in both Job Info and the employee's position must match, why does successfactors allow the Job Info fields to be edited?

What can fail if client has different information in the job info of the employee and the position?

Regards

[nlgro02343]

I personally think it's not a big issue if both do not match, but you have 2 potential problems to tackle:
1. Usually positions tend to sync data to job info. That means if you get 1 new update, it could be the case that the data that deviates from the position gets overwritten (even though it's not intentional).
2. Let's say you'd not use the sync, then you're losing a lot of automation as the data from the position usually helps to automate data entry and thereby increase accuracy.

The other practical element you may prefer having aligned data is that you could otherwise wonder what the point still is of a position having the data in the first place. If the position doesn't match the data of the job info, why maintain it in the first place (it would just be double data entry)?

[adriangalisteo]

That is the thing,why maintain the data of the position? Client thinks as you said, that it would be double entry to maintain the data in the position first and then in the job information, what happens if the data is different? What can affect or what will it make it a disaster? I need a solid argument. I can add here that recruiting module works in the position org chart and I think that then positions are necessary, then also succession module feeds of positions. I guess not using position is only recommended if you only use employee central but I need more arguments to defend this. Payroll and global benefits take the data from the employee right? It does not need the positions?

Regards

[nlgro02343]

Unless they use multiple incumbents on a position (as that would give some serious scaling advantages), apart from the FTE field (as on position it helps to distinguish headcount vs. fte on job info), they would have a valid point if they are ok with filling out their job requisitions more manually (but even that can be mitigated a bit by copy-ing older reqs). Payroll and benefits indeed generally don't care about positions (nor do the talent modules really apart from Succession). For succession attributes such as critical role etc. can be very relevant as you have to look at future incumbents (hence people that don't have the right job data yet) and having the right job grade etc. in there helps to see for whom it could be a logical next step.

The only thing that could strongly oppose their view is accuracy when it comes to self-service. Especially managers tend to be 'creative' when it comes to adding data to the system. Sometimes they for instance think a different structure, job code / grade should be used than should actually be the case and this could cause costs to get wired completely wrong and you as an admin end up doing a lot more manually/the manager gets annoyed by all the fields that need to be filled out. The benefit of positions is at least that (usually) and admin has thought things through a bit better and thereby makes the odds higher that an employee will in fact have the correct data (+ saves them from filling out a lot). But apart from that, if they are ok with maintaining data manually (and they really trust their employees and managers that much), In essence it doesn't have to be a bad thing to maintain less on a position (that will likely make your job easier as well to be honest).

Hence, if they are confident about accuracy, don't mind manual maintenance (and that that will annoy their employees/managers), don't mind working more manual with requisitions/onboarding 2.0 and are not interested in this extra position attributes within succession/the position org chart, it could be ok to maintain less on a position.

[Angie_Pullano]

Hi Adrian,

You've received some good responses so far, but I wanted to add to the "why does successfactors allow the Job Info fields to be edited?"

Indeed, as a customer, it doesn't make sense if the job info fields are left as editable on the employee profile if they should be inheriting that data from the position.

In configurations using position management, and only Position-to-Job Info sync direction, I strongly recommend reducing user error (or "creativity" as Jasper put it) and improve data integrity by using business rules to make all the position-related job info fields read-only and only allow them to change the position ID.

Here is a link to a blog post on using rules to set visibility attributes:

https://blogs.sap.com/2021/11/16/using-business-rules-to-set-field-visibility-required-attributes/

Best regards,

Angie

[JamesVu-DC]

Hi Andrea,

This is a very interesting question, and I'm sure that many client will ask the same in discovery session. I would like to share some of my personal observations: Standardization, Centralization, Automation

• EC provides Position Structure (PS) and Org Structure (Reporting Line) independently as two foundation pillars, and allow selection of leading hierarchy providing their own unique approach.
• PS enables organization to plan their future workforce. Vacant positions can be designed in long term advance and aligned to business plan by an easy access structure overview, drill to detail. This is also the leading practice, not just in SF but in HR management.
• PS allows more standardized and centralized data management. Dedicated HRBP or Org Designer can focus on defining positions with desired criteria, hence Recruiter and Local HRBP don't have to worry about inputting correct data anymore (also minimize the risk of incorrect HR data). This is a huge advantage when utilizing multiple incumbents for same position (sharing same attributions).
• Job Information is the actualization of Position, with much more personalized data to the frame. Those information can be automatically populated from or to Position, depend on the hierarchy settings. Job Info as leading hierarchy allows information to be updated from much lower and wider level, very suitable for dynamic or specialized independent local small structure, but high risk of data inconstancy.
• It is not a system requirement to have both data in sync, but functional business. Many clients actually only have the Job Title concept, hence the confusion of maintaining position data, and may see that is a redundancy.

Hope it can help!

James

[Alina]

Hello, agali,

One of my explanation is you can have an employee without a position, so you should be able to edit his/her data.

Secondly, two employees can have the same position simontineously (transition period, for example). So, you need to correct Weekly Hours for these employees on their profile, as an example.

If you have different information on employee profile and on a position, how can you recognise the correct information? Which data will be relevant for you in this case?

You can switch off your Synchronization in the Admin Center under Position Management Settings.

Kind regards,

Alina