The onboarding of new starters into an organisation is often a complex process. One of the reasons for that is that it is a process that touches on almost every part of the business - HR doing the hiring, contracts and orientation, Payroll arranging payments, IT setting up accesses and equipment, Facilities organising desks and building accesses, Finance arranging credit cards. There are so many different people doing so many different things with so many different interdependencies that it can be very easy to lose track of where things are up to at any point in time. Meanwhile, the hiring manager is often swamped with a stack of different forms, all asking for pretty much the same information but for different areas of the business, or even for different functions within a single business unit. The process is often onerous, time-consuming and error-riddled - is it any wonder that so often a new starter turns up to work without a computer on their desk or a login to the network? It's pretty clear why so many organisations are so intent on trying to get their onboarding process right - yet the complexity makes it such a hard one to nail.
In this case study, we look at how Lida worked with one large organisation to develop a highly-automated, enterprise-wide onboarding process that sees a new starter's requirements delivered quickly and consistently while offering the hiring manager a clear view of the process of their request all along. As this was a government client we are not able to name them, so for the purposes of this case study, we'll refer to the organisation as ACME.
Lida performed a review of ACME's onboarding process and discovered a number of factors that were contributing to the process consistently failing to deliver the required outcomes:
Hiring managers were leaving it too late to log their onboarding requests, leaving minimal lead time for downstream teams to deliver
The IT Department was understaffed and focussed on break/fix issues, so there was a backlog of several days for dealing with requests
IT processes were not well-documented or followed, so there was a high error rate in delivery of things like network and application access
Other departments, like Finance and Facilities, were often not being engaged at all; hiring managers were assuming the request they logged would cover everything they needed, but in reality it only went to IT. There were other forms on the intranet for engaging other departments (in a whole bunch of different intranet locations!) and they were often not submitted
No one had an overall view of the end-to-end process; there was no visibility to hiring managers at all, the best they could often do was cross their fingers and hope everything would be ok when their new hire arrived
Lida worked with the client to design a new end-to-end, enterprise-wide process that would address these issues. The new process was implemented iteratively over more than a year, which enabled the client to realise the benefits of some early 'quick wins' and build the favour of key stakeholders, helping the project maintain momentum. The key technologies used were Alemba's vFire (for its Self-Service Portal and workflow engine) and VMware's vRealize Orchestrator (vRO) (for its automation and orchestration capabilities).
After a lot of consultation and many iterations, the new process flow was agreed. In the image below, the green boxes represent fully automated tasks. These weren't all necessarily completely automated on day one, but because the automation candidates were identified from the outset, the solution was able to be built in a way that would enable the manual activities to be quickly swapped out with automated ones over time.
Initiated by HR
We realised that it was going to be difficult to get hiring managers to log their requests earlier. It's not like they were intentionally leaving it until the last minute, the reality was that they were busy people with a lot on their plates and it was just one more thing to do that often slipped their minds. So we thought about other ways to initiate the process, and worked out that HR, of course, were right across the hiring as well. In fact, HR were creating a partial record for the new starter in the SAP system as soon as they were hired - that was the earliest record of the hire anywhere in the organisation. So why not tap into that? We built a simple SAP service to take the information from that initial record and, using an API, automatically create a request in vFire on behalf of the manager. Once that was done we were up and running - we now had a record of the new hire in vFire, the system we were going to be using to run our automated workflow!
Now for the manager
The next problem we had was that SAP didn't store enough information for us to fully onboard a new starter. It gave us some basics - their name, start date, job title, manager, department and so on. But it didn't tell us what software they needed, whether they needed a basic desktop or a high spec laptop or an iPhone, what applications they were going to use or whether they needed a corporate credit card. There was only one person who had that information - the hiring manager. So we had our vFire workflow email the manager a link to a form, pre-populated with everything we did know and asking them to fill in the gaps - often sent within an hour of the new starter agreeing to terms. Because we had our request in vFire already, we were in a much better position than before. We could now send automated reminders to the manager, advising them of cutoff dates. We could run reports to identify requests that were waiting on the manager and follow those up directly when we needed to. And we could manage downstream teams' workloads better, because we had a clear pipeline of upcoming new starter requests.
This is a typical form sent to a manager:
We found that typically managers were completing the form within a day of receiving the original email - a huge improvement on where we started!
One of the biggest issues we had to overcome was IT's inability to respond to requests in a timely manner. They had been the victim of downsizing some months before, and had been struggling to manage their workload ever since. While there would be some benefit in documenting and streamlining their processes for account creation, equipment provisioning and so on, that wasn't going to give us big enough gains to enable them to get on top of things. We needed something more drastic.
What we ended up doing was taking them out of the process altogether - well, as much as we could, anyway. There are some things you just can't automate - like putting a PC on a desk - and others that realistically are more effort than they're worth. But we documented what the steps they normally took and looked for things that were viable candidates for automation. And we didn't have to look too hard:
Creating user accounts in Active Directory
Creating Office 365 access
Allocating VoIP telephone numbers
Creating SAP access
Granting access to shared network drives
Granting access to shared mailboxes and distribution lists
We took these activities and set up vFire to call vRealize Orchestrator to perform them on behalf of the IT analysts. If you want a better understanding of how vFire and vRO work together, by the way, you can click on over here. By automating these tasks, we were able to free up several hours of expensive and valuable IT time for every new starter. And we were able to provision basic system access in a matter of minutes, with close to a zero error rate. It wasn't uncommon to have a new starter's network logon details sent to the hiring manager within a couple of hours of them agreeing to terms.
Bringing in the business
The next thing to tackle was engagement with other areas of the business which also had things to do as part of onboarding new starters. We identified four main areas we needed to address:
Physical building access
Corporate credit cards
Learning Portal access
The approach was pretty simple - we made sure we captured any requirements right at the start when we sent the original form to the manager, then we just assigned out manual tasks to the different teams responsible for delivering the services. Those teams used vFire to manage their own queues, and we were able to track the status of individual activities from within the vFire request. Some of their activities might be candidates for automation in the future as well, but the appetite hasn't been there in the business so far.
Making it all visible
Our last job was to make sure that hiring managers could have a clear picture of where their request was up to at any point in time. We made sure request statuses were updated automatically by the workflow as it progressed, so that managers could see where things were up to at a glance in the Self-Service Portal. By automating that, we weren't relying on business analysts to remember to update the status as they completed their tasks. We made sure that the history of the ticket was also updated automatically as activities were completed. And we added automated email updates at key points in the process.
The journey is not over yet with this one. Here are just a few things suggestions that have been made to improve the overall experience.
Initiate the process from ACME's employment agency's website, rather than SAP. This would remove the need for HR staff to re-key information, the new partial record would be automatically created in SAP when the new starter is approved by the employment agency.
Automate business application access. This was originally left out of the automation because each business app tends to have its own rules for provisioning access, so you don't get great 'bang for buck'. But, for many apps, access is based on Active Directory group membership, so there may be the possibility of some level of generic automation possible in the future.
Add a graphical view of the request's progress to the Self-Service Portal for the manager to check at a glance.
Look at automating some of the activities performed downstream by non-IT teams.