The Source

Aug 27 2020

Lessons Learnt from Implementing SuccessFactors Onboarding 2.0

When I started implementing SuccessFactors Onboarding 2.0 late in 2019 it was very new, only just General Availability and no customers were live as yet. There were definitely a few speed bumps as consultants and customers navigated through this new product! Here’s what I learnt along the way, which I hope will make for a smoother transition for other customers.

Adopt Standard System Processes, Rather Than Customising the System

Be willing to adopt rather than adapt the system. Instead of trying to implement multiple complex processes with the current limitations – keep it simple. The product isn’t at full parity with Onboarding 1.0 as yet and more features and functionality will continue to be rolled out.

When I started to implement Onboarding 2.0 late last year I was very fortunate to have a client who was both flexible and willing to change their processes so they could adopt the standard functionality Onboarding 2.0 provides.

Given the product was so new at that stage, this was really critical to the success of the implementation, and the approach I’d still urge clients to follow. There’s more growth to come in how much we can customise the system to suit individual needs, so be open to starting with a standard process and building out from there.

As an example, to include compliance forms and features (currently only available for Australia and the UK, with some US support planned for release in 2H 2020) you need to use the standard-delivered process variant. The next release will provide enhanced support to tailor processes to your needs while still supporting compliance features.

This will give more flexibility to have multiple processes configured for different scenarios, such as removing the “New Recruit Data Review” validation step at the beginning of the process. This step kicks off the onboardee paperwork and tasks but is really just a validation of the same information already provided, we could streamline the process by removing a potential bottleneck while waiting on a user to action a step that may not add much value.

Less Mapping But Less Flexibility

With Onboarding 1.0 we configure data mapping from Recruiting to Onboarding, then Onboarding to Employee Central, making the data flow slightly more complex and with more effort involved.

In Onboarding 2.0 we map directly from Recruiting to Employee Central, but with the simplification comes less flexibility. The Onboarding data model is configured using the same system functionality as adding contingent worker, apprentice, or other types of employees.

But it’s ONE data model for ALL onboardees.

While Onboarding 1.0 doesn’t support hire of contingent workers either, it did provide more flexibility to define separate onboarding workflows for each type of employee – the limitation being that they all end up in Manage Pending Recruits to be hired as employees.

For some customers this option works fine if they aren’t using Contingent Workforce functionality. For others Discovery has previously implemented a custom development at the end of the Onboarding process to hire contractors in “Add Contingent Worker” rather than an employee hire.

Now we have one set of data that can be captured for all Onboardees, with no capability to show/hide fields, or to include/exclude sections depending on the employee type. This becomes a problem when you consider that you then have National ID, Bank Details, etc included for contractors; information which isn’t usually required for these types of staff.

Support for contingent workers and other employee types is a critical improvement I’d like to see on the Roadmap for release soon, so customers can seamlessly manage all recruits via an integrated recruiting and onboarding process.

Custom Data Collection & Reporting

With Onboarding 2.0 we can create custom data collection objects to capture information from onboardees in addition to the key hire-related data included in the personal paperwork step, such as uniform requirements. This works well to cater for non-standard data scenarios, however, the data captured is only available via:

Reporting in People Analytics Embedded Edition
By mapping into a custom form which is only accessible in Document Management
With a custom extract using APIs or Integration Centre, adding extra effort to the project

Ideally this information would be visible in the Employee File after completion of the Onboarding process, but a system limitation prevents this currently. The next best solution is standard system reporting capability, and to do this you will need People Analytics Embedded Edition.

PAEE is the latest suite-wide reporting and insights tool being rolled out for SuccessFactors, which has a prerequisite of SAP Cloud Identity Authentication (IAS and IPS). If you haven’t already upgraded to these features it’s worth considering as part of your implementation, while the Onboarding/Offboarding Dashboards provide an overview of activities, you won’t get in-depth analysis of your processes.

Notifications & Form Requirements

Onboarding 2.0 delivers “Email Services”, a standard set of notification triggers and preconfigured templates. While it’s nice to have standard content available as a starting point, most customer requirements will include the use of standard and custom tokens (data already captured during the process), attachments to notifications, ability to send to external email addresses, and more flexibility in triggers; none of which are currently available.

Again, this is an adopt rather than adapt approach, while we wait for the product to develop. It looks like attachment support for notifications is expected in the next release and I hope a few more nice surprises here too.

In some scenarios we can work around these limitations, e.g. attachments, by providing documents to the onboardee in a custom homepage tile for easy access. We can also provide policies and documents for review and signature during the paperwork process. SAP’s standard eSignature or integration with DocuSign provides online signature support.

Consider how many policies/forms are required to be included in this step, as the more data to be mapped and the more forms required, adds extra effort to the project.

Existing SuccessFactors Employee Central Customers

For customers already using SuccessFactors Employee Central, factor in time to review and update existing permissions and business rules. One of the big improvements of Onboarding 2.0 is that it utilises platform business rules rather than “advanced conditions” and role-based permissions, rather than the current syncing process for Onboarding 1.0.

This provides much more granularity and consistency in role-based permissions, as well as making it easier for client system admins to maintain, but with that comes more complexity in getting it right. Existing roles need to be updated to ensure that we aren’t giving too much access, or not enough, and that they work in conjunction with any new Onboarding permissions.

Business rules also need to be reviewed. Where we might be validating certain data fields on save when adding a new employee, these same rules will be triggered during onboarding steps and may need tweaking.

Benefits and Upcoming Improvements

What customers will gain from implementing Onboarding 2.0 is:

A user interface and experience more consistent with the rest of the suite
Tighter integration with Employee Central, which should only continue to improve with subsequent releases
Simplified approach with no need for user, permission, and foundation data syncs; use of To Do tile tasks; capability to map standard foundation objects such as Division, Department, Cost Centre, Location from Recruiting.
Improved Offboarding process with new tasks including Knowledge Transfer Plans
On/Offboarding Dashboards to view all tasks in one place and flexibility in assigning those tasks to different user groups, unlike Onboarding 1.0
All UI screens built to be mobile-responsive
SuccessFactors Employee Central and Recruiting modules aren’t prerequisites, integration with third-party systems managed by either SAP CPI or SuccessFactors Integration Center, using SuccessFactors OData API (EC mini-master IS required).

As well as expected fixes and improvements to business rule support and crossboarding processes, the current roadmap for the 2H 2020 release includes the following:

Attachment support for Email Services
Ability to generate person id with EC business rules; currently does not comply with customer requirements for different number ranges
Support for creating custom processes with compliance steps, enabling steps to be skipped or reordered
US compliance support for US Federal (W-4) and state withholding forms, restricted availability for I-9

With future releases it seems unlikely that Onboarding 1.0 will continue to experience much growth, while getting in on the ground floor with Onboarding 2.0 will be the key to gaining benefits from new features.

Final Thoughts

Onboarding 1.0 has no confirmed end-of-support date currently, it’s not going anywhere just yet and compliance updates will continue to be implemented.
Onboarding 1.0 and 2.0 can be run in a hybrid approach, existing customers could implement 2.0 for Australian employees only, with the remainder of countries continuing to be processed with 1.0.
Capability to utilise migration tools is proposed for late 2021, if you’re ready now – don’t wait.

Aug 13 2020

SAP CPI and SAP SuccessFactors Monitoring EP02: The one where CPI writes logs to Execution Manager

This blog post originally appeared in the SAP Community on 12/08/2020.

Discovery Consulting was recently involved in the global SAP SuccessFactors Implementation Design Principles (IDP) workshop on SAP SuccessFactors Integration patterns. Our practice of logging the results of SAP CPI iFlows into SAP SuccessFactors Execution Manager was picked up by the group as a potential SAP recommended best practice! Hopefully, we will see something come out from SAP in the future around this. However, whilst we wait for that to happen – here’s some details about how we at Discovery use this integration best practice to help our clients support their SAP SuccessFactors instances and be better equipped to deal with issues if and when they occur.

This post is targeted at an audience of SAP Cloud Integration developers and the SAP SuccessFactors administrator that they work with. It is a quite technical post and gives some great detail on the solutions that we use with our customers.

Firstly, a little background. Too often in the past I have seen support calls from customers about SAP SuccessFactors to/from SAP ERP (and other systems) integrations and a request to “find out what went wrong.” Many/most of these issues could be solved if only the SAP SuccessFactors administrators had access to any error/success messages that the integrations were producing. The aim of these blogs is to show how easy it is to incorporate logging to SAP SuccessFactors Execution Manager into all your SAP CPI integrations so that admins and developers have a simple way to monitor all SAP SuccessFactors integrations.

This post is the second in a series about this logging – you can read the first post which gives some details about the Execution Manager and using OData APIs to update it here:

SAP CPI and Successfactors Monitoring EP01: The one with the Execution Manager Dashboard

Enough background – on with the show!

From my first post we, hopefully, now have an idea of how easy it is to log information into the Execution Manager Dashboard in SAP SuccessFactors. It is now time to put our knowledge to use. As Dale Carnegie once said,

“Knowledge isn’t power until it’s applied.“,

It’s time for us to finally go ahead and see a bigger picture of how exactly we can harness the Execution Manager to our advantage. In this post, I’ll be focusing on how I implemented the Execution Manager in SAP Cloud Platform Integration iFlow.

Bird’s eye view of the implementation

This implementation consists of an iFlow and a simple reusable groovy script to generate EMEvent payload groovy script. Just to make things a bit modular here, I broke the iFlow into the following integration processes:

Main integration process,
Few local integration processes for the following:
2.1 populating demo data(in external parameters and body) to imitate the process of generating data to be posted to Execution Manager Dashboard, and
2.2 sending data to Execution Manager Dashboard using HTTP adapter
a separate local integration process for exception handling, and
a groovy script to generate EMEvent payload to be sent to Execution Manager Dashboard in SAP SuccessFactors.

Now before I get into the details, I would like to quote an expression by Tess Flanders in 1911 that fits here perfectly,

“Use a picture. It’s worth a thousand words“.

So here, I share with you how exactly the implementation looks like when it is ready to log everything we need in the Execution Manager Dashboard **drumrolls**

Fig.1: iFlow to log data in Execution Manager Dashboard

Digging into the iFlow

Now let’s see what’s really happening here in the iFlow above (I’ll try explaining things in the order I’ve mentioned above).

1. Main Integration Process

Fig.2: Main integration process

a) In this example, every execution of the main integration process logs 3 separate events into the execution manager dashboard, i.e. START – data/error/warning/failure (you can log as many events representing these between a START and END event) – END :Initializing the external properties for EMEvent payload. Here’s what the ‘initialize properties’ step looks like. I have included a sample payload to log a single event from my previous post and how it maps to the properties initialized.

Fig.3: Properties defined for EMEvent and EMMonitoredProcess payload

note: The EMMonitoredProcess payload needs to remain the same, as a single execution of the iFlow represents a process in Execution manager. All the events logged under a single process are clubbed together enclosed within a ‘START’ and an ‘END’ event.

b) Once the properties are initialized, the properties for the EMEvent payload needs to be changed for every event we wish to log. The most important one here is the ‘event_type’ property as it decides the type of event logged into the execution manager. So, the next step here is to change the event_type in a content modifier to ‘START’ as we initially need to log a START event.

c) The next step in line is to log the data that matters in the form of multiple events showing data that is required to be presented in the Execution Manager Dashboard. That is where the ‘log data’ step comes in, which triggers the Log data integration process mentioned in the next section. This integration process can be used to fire multiple events as the iFlow carries on its execution. In this case, the iFlow is designed to log a single event of the type INFO to represent a portion of information.

d) Once, all the data/error/warnings have been logged during the execution, there is another enclosing event that needs to be logged. You guessed it right, END event it is 🙂

If we fail to log the END event for a process, the process in all would have an ‘IN_PROGRESS’ state rather than the expected ‘COMPLETED’ state (please refer to my previous blog if you need a reference to different scenarios and the final process state for each).

2. Local Integration Processes

2.1 Log Data integration process

Fig.4: Generating data to log

This local integration flow is to represent a process/set of processes that execute during the lifecycle of an integration flow where the iFlow does what it is actually designed to do (pick data from source A, transform, write into destination B). This could be a single local integration flow, or a set of flows to get your job done. This is where we log the events depending on what data is really required by the business.

2.2 Execution Manager Logger integration process

Fig.5: Generating and logging payload to Execution Manager Dashboard

This local integration flow is principally responsible for 2 tasks:

Executing a script which generates a payload to log an event by using the external properties and body populated by components before this integration process is called.

Firing a HTTP call to SAP SuccessFactors Execution Manager Dashboard to log the event.

3. Global Exception Handler

Fig.6: Handling errors and exceptions

While working on the solution, there were times when the iFlow during its execution ran into errors such as errors with the script, HTTP connection issues, etc. that caused the iFlow to fail. But how does that impact our logging and why should we care?
As mentioned before, it is important to log an ‘END’ event for every execution to ensure the EMMonitoredProcess does not end up in a ‘IN_PROGRESS’ state even when the actual execution of the iFlow has stopped/failed.

Therefore, this local integration process is to take care of all the errors/exceptions/failures that occur during the execution and ensuring that proper error messages are logged in to the Execution Manager, followed by an ‘END’ event.

4. EMEvent payload generating groovy script

As simple as it should be, this script picks up data from the external properties and populates them into one single JSON payload consisting of an EMEvent and an EMMonitoringProcess.

Script 1: Generating EMEvent payload

*disclaimer: Script provided for discussion purposes only, any attempt to use this script or a variation of it in your own integrations is at your own risk. No fitness for use in any particular purpose is, or should be, implied.**

**this said, some of our experienced technical team would be more than happy to help you work with this framework to build out the best solutions for your SAP SuccessFactors instances if you’d like us work with you!

Reaping the results

Just for the sake of demonstration, I have considered executing the iFlow 4 times, once for each ‘event_type’ and its impact on the ‘final process state’ of the EMMonitoredProcess/execution as mentioned below.

Use Case Scenario	final Process State
Use Case A: event 1- START event 2- INFO event 3- END	COMPLETED_SUCCESSFULLY
Use Case B: event 1- START event 2- ERROR event 3- END	COMPLETED_WITH_ERRORS
Use Case C: event 1- START event 2- WARNING event 3- END	COMPLETED_WITH_WARNINGS
Use Case D: event 1- START event 2- INFO event 3- FAILED	FAILED

Table 1: EMEvent use case scenarios and their impact on final process state

And this is how the scenarios look like when executed one after the other:

Fig.7: Execution Manager Dashboard after logging the events

But how do I debug this? How do I trace a Process/execution back to the message in CPI?

If you scroll back up to Fig.3 and look at the EMMonitoredProcess payload, you will notice an attribute called ‘processInstanceId’. Process Instance ID as the name suggests, is to uniquely identify a single execution/process which clubs together several events under it.
But don’t we have something similar in SAP CPI to identify a particular execution of an artifact/iFlow?

As mentioned in the Developer’s Guide (2020), every message that travels across in an iFlow has a few header fields by default which has information about the iFlow/artifact they belong to. One such header field is ‘SAP_MessageProcessingLogID’ which uniquely identifies a particular message/execution of the iFlow and can be found under the Label MessageID in CPI’s ‘Monitor Message Processing’ page.

Let me show you below, how the ‘processInstanceId’ external property that we populated with the field ‘SAP_MessageProcessingLogID’ in CPI can be correlated with Execution Manager Dashboard’s ‘Process Instance ID’.

Fig.8: Mapping an EMMonitoredProcess to an execution in SAP CPI

Conclusion

With everything in place, I hope you can see how this is an effective and relatively simple way to standardize the monitoring of integration flows in SAP CPI for an SAP SuccessFactors admin. It does this in a way that collates all the integrations associated with your SAP SuccessFactors instance in a single place to enable the developers and admins to monitor everything from a single dashboard.

This not only helps the developers but the business users who need to check the overall performance of the Integrations without having to access SAP CPI and learn how to navigate that platform as well as SAP SuccessFactors.

That’s all Folks!

I hope that you enjoyed these posts. I’d like to thank my colleagues and their collective efforts for helping me pull these together. It’s great to work with a team that continues to innovate, extend and make SuccessFactors integration as easy to use as possible for all our customers.

Thanks for your time!

References

Developer’s Guide, 2020. Developer’s Guide: Managing Integration Content. [Online]
Available at: help.sap.com
[Accessed 11-08-2020].

Jul 29 2020

SAP SuccessFactors Core HR – Employee Central, Employee Central Payroll, Time & Attendance

The undeniable benefits of SAP SuccessFactors Core HR components

Organisations and workforces all around the world are undergoing more change and upheaval than ever before. Leading businesses are expertly managing the evolving landscape with the help of some very smart tools. What’s the number one tool in their toolkits? Without a doubt, it’s SAP SuccessFactors Core HR and its key components – Employee Central, Employee Central Payroll and Time & Attendance.

What is SAP SuccessFactors Core HR?

This cloud-based software system lets you empower and manage your workforce at both global and local levels.

It takes complex, separate, time-consuming processes and integrates them onto one powerful, streamlined, easy-to-use platform that can be accessed on a variety of devices, whether you are in the factory office or company boardroom.

With all essential HR processes centralised and consolidated, organisations can automate, improve and extend all HR services right across the board, locally and globally.

Some of the core processes that SAP SuccessFactors Core HR and its components handle include:

Workforce management
Recruitment
Payroll management
Time and attendance
Legal compliance across 95-plus countries
Work visa management
Organisational analysis
Organisational reporting structures
Service delivery

Why leading organisations choose SAP SuccessFactors Core HR and its key components

From Microsoft Corporation to Jemena and CPA (Australia), organisations all around the world are choosing SAP SuccessFactors Core HR and its components because of the concrete benefits on offer. Let’s zoom in on those benefits from two important perspectives.

Benefits to the organisation

Enables organisations to easily keep track of all essential HR information across their entire workforce
Allows organisations to keep up-to-date with changes to their business and their workforce
Helps organisations model and visualise their workforce and provides data-driven insight into operations in real-time
Creates a modern and engaging workplace that appeals to talented employees
Enhances strategic decision-making and makes a significant contribution to business performance
Drives growth

Benefits to the workforce

Access to a top-quality, user-friendly, self-service experience
A simplified mechanism for accessing, editing and getting information about benefits such as pensions, reimbursements, allowances and insurance plans, resulting in time-savings and greater employee job satisfaction
The ability to easily record absences and attendance – employees can access instant, real-time information about their overtime, premiums and balances whenever they like
Better communication with HR through the employee’s preferred channel.

Employee Central – simplifying and streamlining processes

Employee Central is where all core HR processes come together in your organisation. It’s a dynamic, responsive self-service centre with some pretty impressive applications for mobile devices.

Key benefits of Employee Central include:

Scalability – Equally effective for Australian SMEs or global players, Employee Central is fully scalable and can be adapted to meet the needs of your business now and in the future.
Technologically flexible – The software is cloud-based and updated regularly to keep up with today’s rapid pace of change.
Organisationally flexible – Employee Central lets you define your unique organisational structure. You can also choose which data can be changed and by whom (employees, supervisors or other) and what follow-up steps are involved.
Global and local intelligence – Legal compliance is a headache for many HR departments. Employee Central is designed to ease the pain by ensuring both international and local compliance of regulations. It caters for over 95 geographical locations.
Quality service – Employee Central delivers a high level of service, the kind that people are used to receiving outside of their working lives. This is software that truly engages employees, giving them direct feedback when appropriate and inviting them to give their own feedback in turn.
Greater job satisfaction – The system allows workforce members to be rewarded and recognised, both of which have a direct impact on employee job satisfaction and an organisation’s ability to retain talent.

The clear benefits of Employee Central Payroll

When it comes to payroll management, organisations need a system that is accurate, timely and global. Employee Central Payroll is all that and more.

Accurate

Employees love Employee Central Payroll because they are accurately paid for the time they have recorded, according to their contract and in compliance with local laws. Organisations love it because of its reliability and because it flags potential errors and discrepancies before they become a problem.

Timely

Processing is automated and accelerated with Employee Central Payroll, ensuring employees are paid on time. The system also allows errors to be sorted out swiftly by payroll specialists in real-time.

Global

Employee Central Payroll, just like the other components of SAP Core HR, is built to ensure full compliance with relevant regulations. This is of vital importance when it comes to paying wages across a variety of jurisdictions.

Getting on top of time and attendance

Gaining control over time and attendance is fundamental for all businesses. And, that’s exactly what Employee Central Time Management was designed for. With this component of SAP Core HR, organisations can easily:

Plan, record and approve absences
Keep track of working time
Ensure compliance with all relevant labour laws
Automate the calculation of time and pay for employees
Obtain an overview of time accounts
Edit and analyse employees’ records
Manage notifications and alerts

To learn more about SAP Core HR and its components, reach out to our team today. You’ll be amazed by the benefits.

Jun 23 2020

Using SAP Fieldglass to Set Up Your External Workforce Management

What Is External Workforce Management?

The external workforce is revolutionising the way business gets done. While once upon a time there needed to be an in-house department or — at the very least — an in-house specialist required to handle each role, this has not proved cost-effective. This results in rigid business structures, out of which expansion and evolution were difficult simply because businesses could not draw upon the required resources.

The digital age has brought with it a more flexible approach to the workforce and how this workforce is managed. Surveys suggest that around 44 per cent of the total workforce is now external, and this level is increasing.

How SAP Fieldglass Makes All the Difference

SAP Fieldglass provides an overarching digital solution from which to manage all aspects of your external workforce, from creating jobs and filling roles to filing invoices and paying wages. With Fieldglass, you know:

Who’s working for you
What they are working on
Where they are located
Which of your facilities they are accessing
How much they are getting paid

By answering these key questions, your business will be able to:

Simplify the engagement of the external teams and operatives needed to fulfil key roles within your business
Structure your approach to the external labour force and to payment (supported by automated features)
Ensure security and compliance, even if no direct payment is being made (for example, you know who has access to your facilities)

These are the key tenets of SAP Fieldglass, but there are other benefits you can expect from the solution, too:

Increased efficiency through process standardisation
Cost savings through rate controls on external workers
Full visibility from a single data repository coupled with powerful reporting
Legal and regulatory compliance

Sap Fieldglass 2 Man On Construction Site During Daytime 159306

How to Set Up External Workforce Management with Fieldglass

Setting Up and Getting Started with Fieldglass

The user begins the process by setting up SAP Fieldglass. This is achieved via a four-step procedure.

Register with the Ariba and Fieldglass networks.

SAP uses the Ariba network to handle communication and transfer of files between Fieldglass and SAP ERP. This means that users will need to register for both networks before they can begin.

Set up the Fieldglass account.

With the registration on both networks now confirmed, the user simply needs to complete the set-up on their Fieldglass account. This includes reviewing settings and parameters and making sure these reflect your own needs for Fieldglass.

Provide training and education to users on how to utilise the Fieldglass account.

In order for Fieldglass to be effective, your teams need to be able to process work items in the Fieldglass account. This means individual team members should have the training and support needed to use Fieldglass efficiently and effectively, managing the external workforce in a way that achieves targets in terms of flexibility and agility.

Provide training and education to external teams and other members of the external workforce.

Using Fieldglass to connect with remote workers is a two-way channel. The external workforce needs to be able to respond to support requests and posted tasks, just in the same way as your internal teams need to be able to access the platform to post these tasks. External teams also need to be able to access timesheets and other resources. Make sure that such teams are able to access this effectively.

Follow the Category Management Checklist

Before you can begin to properly manage your external workforce, you need to follow SAP Fieldglass’s category management checklist. Take a look at the following points and ready your business for external workforce management.

Bring the top levels of management onboard.

Upper management needs to be on board with the project from day one, providing their complete support each and every step of the way. Hold initial meetings to make sure that this is the case, and schedule regular meetings in the future to keep all levels of the company engaged in the process.

Manage external talent under a centralised platform.

This is the SAP Fieldglass solution. Fieldglass provides businesses with a centralised platform they can use to keep on top of the external workforce effectively. We’ve already taken a look at the initial set-up phase for Fieldglass, so make sure that this is completed.

Agree on clear responsibilities.

Each member of the team who is cleared to use Fieldglass for work orders and other management tasks must agree on their responsibilities ahead of time. Make sure every duty and every task is covered, and that every member of the team is clear on what they need to do.

Expand strategic cooperation with staffing agencies.

There may be times when your business needs are particularly acute, and you require more external support to plug the gaps. There may also be times when these needs are less intense and urgent. Connecting with staffing agencies via the Fieldglass portal will ensure that your needs are met.

Put each process through rigorous testing.

The category management checklist is almost complete, but you still need to make sure that proper testing has been carried out. Think about how you will be using SAP Fieldglass and put each process through its paces.

Defining Your Supplier Management Level

The next phase is to define which level of supplier management you are currently at so you can chart your progress over time. The levels are:

Decentralised

At the decentralised level, you will have several suppliers that you will manage internally. Procurement will be handled on an ad hoc basis.

Preferred Supplier

At this level, you will have a selective set of providers and contracts or service-level agreements (SLAs) with each of these suppliers.

Master Vendor

At this level, you may only have a single supplier who manages other suppliers on your behalf. This means only one point of contact and direct cost savings on bill rates via customised SLAs.

Managed Service Provider

A business at this level has only one contact point for their suppliers. They will leverage direct cost savings on the billing rate, leading to a better management of total spend.

Total Talent Management

This is the level everyone is aiming for, characterised by a reflexive and agile management set-up that is achieved via the Fieldglass platform. At this stage, suppliers are engaged and managed as and when required, with no gaps or shortfalls.

With your current level defined, you gain a clearer idea of what you need to do to reach the next level. In this sense, working with SAP Fieldglass can give you a better understanding of how your business is operating.

To learn more about how to get the best from Fieldglass or how to make the solution your go-to for external workforce management, reach out to our team to learn more.

May 26 2020

Should You Make the Switch to SuccessFactors Onboarding 2.0?

The long-awaited SuccessFactors Onboarding 2.0 was released in the last quarter of 2019 and being “lucky” enough to have a client keen and willing to implement immediately, I’ve been able to explore the solution in detail. While it’s a step forward in user experience, there’s a lot more to consider, here’s the key points that customers should be aware of when deciding whether to switch.

Overall, how does it rate?

Improvements Compared to Onboarding 1.0

Now part of the SuccessFactors platform, no need for user/ permission/ foundation data syncs, data mapping is simplified, use of To Do tile tasks.
Uses platform permission roles and groups; unified security setup.
Consistent user experience; what your onboardee sees prior to starting is the same as they’ll see once they are an active employee.
Continual change is being rolled out, meaning the product will only continue to improve, unlike Onboarding 1.0 which will remain pretty static.
On/Offboarding Dashboards to view all tasks in one place and flexibility in assigning those tasks to different user groups.
Utilises much of the same configuration as Employee Central, which is good for client system administrators.
More flexibility in process steps used, with further enhancements coming.
Continues to support DocuSign or SAP e-Signature for form signatures.
All UI screens built to be mobile-responsive.
Reporting available with SuccessFactors Stories in People Analytics (formerly People Analytics Embedded Edition), which requires SAP Identity Authentication Services (IAS/IPS).

Future Improvements/Features

US Federal (W-4) and state withholding forms, as well as restricted availability for I-9 compliance forms expected in 2H 2020.
External user type isn’t picked up in the standard sync to SuccessFactors Learning, so learning items aren’t available until the onboardee’s start date.
No migration tools available for Onboarding 1.0 to 2.0, requires new build. Migration expected in a future release but no date as yet.
As for Onboarding 1.0, currently no support for Contingent Workforce Management, or management of any staff types who have specific data requirements, e.g. volunteers, contractors.
Limited email notification functionality and loss of workflow ability for equipment tasks.
No support for business rules during the process steps onInit and onChange, ie. to customise the data captured with rule-based criteria.
No rules supported at all for crossboarding records created from a Recruiting/Onboarding process, as well as system-generated fields not populating. Expecting a fix on this soon.

If your Employee Central configuration is already bedded down and working for you, then Onboarding 2.0 can leverage off your existing solution to improve the end-user experience – both internally and externally. Particularly if you’re not trying to recreate numerous complex processes then put Onboarding 2.0 on your near-future radar. Note: Onboarding 2.0 can be implemented with a non-SuccessFactors HRIS or ATS integration.

If you’re about to start an implementation then I wouldn’t even consider Onboarding 1.0, you will be provisioned with 2.0 by default and that is SAP’s direction forward. Would you buy Apple’s iPad from 2 releases ago, or would you buy the latest version, knowing that it’s been updated and built with the latest technology?

While Onboarding 1.0 will continue to be available for existing customers for quite some time to come, dropping the clunky integration and sync jobs for a new build would be my recommendation unless you have a compelling use-case otherwise.

The flow is quite similar to Onboarding 1.0, with capability to create your own processes, or skip steps as needed. Further flexibility is expected in the 2H 2020 release, giving more options to reorder the process and skip steps. Currently you need to use the default process variant in order for compliance to work, but it will be great to be able to define separate processes with and without this step.

Key points to consider before implementing

If you’re keen to move ahead with the new product, you need to be prepared to accept the current limitations, as it is still under development.

As yet there’s no migration path so it’s a new implementation, with migration tools on the SuccessFactors Roadmap for some time in the next 24 months. If you’re willing to commit to another project and keen for the changes, then go ahead and implement Onboarding 2.0 without those tools.

However, take this as your opportunity to re-look at your processes and simplify them. Don’t expect 100% parity between what you have now in Onboarding 1.0, and what Onboarding 2.0 provides. If you want to implement soon, don’t try to replicate exactly what you have currently. Keep it simple and approach it with an open mind as if you were implementing a new module/process. Because that is exactly what you’re doing.

Consider these questions:

Are the relevant compliance forms available? While you could implement 2.0 just for Australia and keep other countries on 1.0, consider the mixed user experience and supporting both.
What data do you need from new hires? If using Employee Central, are you already capturing it, e.g. visas/permits, national id, bank details.
Review the policies and forms you need populated/signed and consolidate where possible!
Think about who should perform validation steps, onboarding tasks, and the final hiring step – this will affect and inform your role-based permissions.
Who needs to be notified, when in the process, and what data do they need? Consider third-party systems here as well. Can you simplify your existing notifications?

Also consider your future plans for reporting. As mentioned previously, Onboarding 2.0 reporting is provided with SuccessFactors Stories in People Analytics and this isn’t just a case of flicking the upgrade switch and having it working. There’s a load of information in this post in the SuccessFactors Customer Community, and while there’s no Onboarding templates as yet, there will be a standard set of reports available.

You’ll also need to implement SAP Identity Authentication Services (IAS/IPS), even if you already have an identity management system authenticating single sign on (SSO) to your SuccessFactors instance.

Is it worthwhile despite this?

What you WILL gain is a solution that fits much more with the rest of SuccessFactors, both in user experience and integration between modules. And as I’ve previously mentioned, it IS still undergoing development, which means new features and improvements will be rolling out continuously. Unlike Onboarding 1.0 which is unlikely to change much now, except for compliance updates/general fixes.

One of the major showstoppers for many organisations has been the lack of compliance forms in the initial Onboarding 2.0 release. However as of the First Half 2020 release, UK and Australian compliance forms are available (Australian Tax File Declaration and Superannuation), with US compliance planned to commence from 2H 2020.

Customers that I’ve demoed to have found the user experience more appealing and the flexibility to assign the onboarding tasks to different responsible groups is seen as an improvement on the previous version as well.

The Onboarding and Offboarding Dashboards give a visual overview of all tasks in progress, as well as drilldown to more detail on the status of the steps and forms. I’d like to see the Onboarding checklist task more aligned to the other tasks, as it’s easy to overlook, and a fairly key requirement for many customers. In Onboarding 1.0 it was easy to build these types of requirements into panels but that’s no longer the case.

How are existing Employee Central customers impacted?

If you already have Employee Central, then implementing 2.0 means that your data model is going to require changes. Similar to implementing Contingent Worker, we create a Person Type for “Onboardee” and replicate the configuration, depending on what data is required to be captured for Onboardee versus Employee (or Contingent Worker). This will likely require some tweaking of fields and business rules in the hire and ensuring relevant data is mapped from Recruiting.

Leading me to Contingent Workforce functionality; there’s still no integration between CWF and Onboarding. This is on the SuccessFactors Roadmap for sometime in the next 24 months. So while you can recruit a contractor or agency staff via SuccessFactors Recruiting Management and put them through the Onboarding process, they will all end up in Manage Pending Recruits instead of Add Contingent Worker.

Discovery have previously developed a custom solution in Onboarding 1.0 for customers so that these types of hires are removed from Manage Pending Recruits and created automatically as contingent workers, so as not to impact the customer’s licensing. Stay tuned for updates on whether we do something similar for Onboarding 2.0.

Also factor in that for existing clients, role-based permission roles and groups will need re-work, expect and allow for testing to ensure everything is working as expected.

What needs to improve?

One area I’d like to see significantly improved is the Email Services functionality. Preconfigured email templates are provided and while you can personalise the texts, we can’t yet use custom tokens, only the standard set provided – which is very limited.

We also can’t configure custom triggers, so while we can create custom notifications, we don’t get a lot of choice about when in the process they are triggered. Being able to trigger a notification to a user that there are onboardees ready to hire is one example of these limitations.

Existing customers with very customised notifications will really feel the pain of this one, there’s just not the flexibility we are used to in Onboarding 1.0 for generating notifications and workflows for equipment, IT and systems provisioning, etc.

Final thoughts

One other area I’d love to see SAP give more focus to is the interaction between the business and the onboardee, prior to their start date. Many customers are looking for this to be more conversational and interactive, rather than just pushing out a bunch of emails and forms, they want to better engage with their new hire. It’s nice that you can now login from a mobile device for the paperwork & tasks (responsive!) but it just isn’t enough in this competitive market for HCM solutions.

This might look like the hiring manager sending an SMS to ask about their new team member’s favourite coffee or tea and letting them know where the best local cafe is before they start. They might like to record a quick video and send it, without having to upload to the system and create a tile to link it. They might ask for 3 fun facts to share with the rest of their team members.

These are all actual requirements from customers and not something we can currently cater for in the way clients really want. Not everyone reads the many emails we send them and we have to recognise that different age demographics respond better to some communication methods than others.

Once Onboarding 2.0 is more settled, it’s time to consider the new hire’s experience just as much as the business necessity to streamline a data-driven paperwork process. Please put the “experience” in HXM!

Next steps

In my next post I’ll go through the process steps and features in more detail, including screenshots. You can also read more about my lessons learnt from implementing 2.0. Meanwhile, get in touch and arrange a demo and a chat about the new Onboarding 2.0 solution to help you decide if you should make the switch.