Employee Central Contingent Workforce Management

The Employee Central Contingent Workforce Management (CW) functionality is a step in the right direction for SAP SuccessFactors. Companies rely more heavily on contingent workers than ever before.   As of May 2017, there were 5.9 million contingent workers in the US, which represents approximately 4% of the  workforce. (https://www.bls.gov/spotlight/2018/contingent-workers/home.htm).  This percentage has only grown since the survey was conducted.
Traditional HRIS systems were not focused on contingent workers, it was a task mainly handled through accounting or procurement departments,  but as the numbers of contingent workers have grown as a significant percentage of an employers headcount, so has the need for a HRIS system to track these workers.   However, it does pose a dilemma – if by definition the contingent worker is  not an employee- how are they best represented in a system designed around the concept of traditional employment, yet remain  identifiable for  reporting, budgeting, headcount, training and other purposes?
With this in mind, the middle road approach SAP has taken  with Employee Central’s Contingent Workforce Management  “works out of box” but does have some limitations when looking beyond standard configuration.  To SAP’s credit, there have been many improvements to the Contingent Worker functionality.
What works:
  • Reduces data entry significantly  for HR teams.
  • Lowers licensing costs.
  • “One touch entry”  – HR or  3rd parties enter both the hire date and termination date upon entry- negating the need to follow up to  terminate a contractor.
  • Potential to offload can offload some data management to the Contingent Workers Manager rather than the HR team.
  • Enhanced visibility in org charts.
  • Better reporting on CW headcount and pay.
  • Plays to the strengths of Employee Centrals strong position control.
  • Reporting –  The standard delivered  advanced  CW register report is a good starting point, and filtering off the “Is contingent worker?” field makes adhoc reporting easy.
A bit of work still needs to be done in the singular business configuration -which does not offer country specific fields -forcing all users in different countries share a CW entry portlet.  Without country specific configuration, end users will see all fields, some of which may be unnecessary for tracking contingent workers in their country of employment.
Work Orders are the heart of the Contingent Worker functionality- and contains the start date, end date, pay rate and manager of the Contingent worker.  The Work Order UI is  clean, yet there is a  simplicity that overlooks the sometimes complex ways companies hire and pay Contingent Workers.
By way of example, if a CW has a 6 month Work Order, from 1/1/20 through 6/15/2020- the end date can be shortened or extended by editing the original Work Order used to hire the CW.
However, if a 2nd WorkOrder is added to the same user, say 6/16/2020 through 12/31/2020 at a higher billable rate – the users will be terminated, on 6/15/2020 and then reactivated on 6/16/2020 by the 2nd work Order.
In theory, not a big deal, but it becomes problematic for downstream applications as well as potential termination or compliance inquiries.  To add an additional work order, you are required to have the first Work Order expire – terminating the contractor in order to add an 2nd Work Order.
If attempting to edit the work order to add an additional row, you will get a the following error “Work Order should be inserted only in an existing Inactive Work Order”
Change management is key to effectively managing contingent workers- if the intention is to have the CW’s manager also be responsible for the CW’s Work Order.  Email notifications are sent out to the Work Order owner, at a frequency determined by the (30, 15, 10, 5 days before termination is common) and if the end date is not changed or an additional workorder entered – the CW is terminated, and access revoked.  Managers will forget- especially if this is a new process, so change management is essential.
Reporting – Reporting on a CW’s job information,  is straight forward, just use the “Is contingent Worker Yes/No” in Table (Adhoc) reporting as a filter.   For a more comprehensive look at a Contingent Worker, you will need to rely upon Canvas Reporting (Advanced) to pull in work order information, as a Meta Data Framework (MDF) object.  The standard Canvas “Contingent Worker Register” is useful in this respect, but at the end of the day, is out of bounds for a quick table report.
Rehiring and Transitioning between CW and Full Time employment
Rehiring a contingent worker is simple – just assign a new Work Order to the CW after their original WO has lapsed, alternatively a users Work Order can be extended by editing the WO end date.  However, adding a 2nd Work Order falls short of the mark while there already is an existing work order in place.  In order to add a second Work Order,  you must wait for the original Work Order to lapse, terminating the contractor, and then rehire with a new Work Order
For companies with hiring practices that include hiring someone on a contingent basis, prior to transitioning to full time  permanent employment – this is no inconsequential hurdle.  The user name granted at hire during the CW process – is NOT carried through to permanent employment.  It takes some manual trickery, to bring forward the original user name provided during the CW process to a new hires permanent record, if this continuity of access and identity is what a company determines is best.  In other companies, a new identity is often granted at time of hire as a regular employee, which would fit this model perfectly.
Integrations – a call to the Compound employee API will automatically  filter out Contingent Workers- making it backwards compatible.  To include both regular and contingent workers the condition “isContingentWorker IN (true, false)” can be added.
In closing the Contingent Worker functionality in Employee Central is a strong contender for vanilla installs, but the lack of flexibility may hamper companies with  complex needs.
Found this helpful: