Fred

FREDWESTON.NET - DevOps: Onboarding and Offboarding Workflow
DevOps: Onboarding and Offboarding Workflow
Posted under Work Stuff on Saturday, April 21, 2018 @ 8:06:16 PM
Show Previous Article 
A big part of the ops work at my place of employment deals with the onboarding and offboarding of staff.  We have around 30-40 new hires / terminations a year, and as a manual process that probably represents somewhere around 60-80 hours of work.

Some of the big challenges we used to face are:
  • No centralized responsibility for notifying IT of employee changes
  • Not getting timely notification of employee changes
  • Not getting the information we need when we were notified of employee changes
  • Constantly having to follow up to get the information we needed
  • No centralized source of truth on the status of employee changes
  • No automated approvals for equipment requests (i.e. PCs, cell phones, peripherals, etc)
We implemented a system comprised of five main components:
  • A "New Hire Form" - this gets filled out by our HR department to notify us of new employees
  • A "Termination Form" - this gets filled out by our HR department to notify us of terminations
  • An "Equipment Request Form" - this gets filled out by the hiring manager and allows them to specify the equipment their new employee requires.  It also automated the purchase approval process (some types of equipment charges back to the hiring department's budget, so we need charge back approval)
  • A web utility used by IT that actually creates Active Directory accounts, enrolls the new employee in our MFA system for VPN authentication, sends notifications to various departments notifying them of the new employee and sends the new hire a welcome e-mail.
  • A set of scripts that run as scheduled tasks on a Windows server.  These are primarily reminder scripts that serve to send nag e-mails to various people when the workflow is waiting on someone to take action.
The New Hire Form

This form uses Active Directory authentication and restricts access to members of our HR team.  It collects all of the basic information we require such as name, contact info, job title, department, manager, office location, and start date.  

It also collects additional information that can be used to kick off additional notifications / workflow tasks.  For example:
  • Does the new hire require equipment (i.e. a PC, cell phone, etc).  If so, a notification will be automatically sent from the person filling out this form to the hiring manager with a link to the equipment request form.
  • Does the new hire require a credential (i.e. ID card)?  If so, a notification is sent to the person that creates our staff credentials.
  • Does the new hire need a keyfob to access our office?  If so, a ticket to issue one is raised in our helpdesk system via an API call.
Fig 1 - The New Hire Form

The Equipment Request Form

This form is filled out by the hiring manager to let IT know what equipment their new employee will require.

The form provides information about the equipment policies (i.e. budget info, etc) and collects information related to:
  • PC requirements (laptop, desktop, etc)
  • Accessories (monitor, docking station, keyboard/mice, USB storage, printer, UPS, printer, etc)
  • Cell Phone
  • IP Phone
  • Should the new hire be added to existing e-mail distribution lists (i.e. a department list)?
  • How should we deliver the equipment?  Leave it in the employees office, deliver it to an existing employee, ship it?
If any of the selected equipment requires budget approval, a notification is automatically sent from the hiring manager to their ELT (exec leadership team) representative (i.e. the big boss).  The ELT rep can approve or deny the request.  In the case of approval, the relevant tickets to procure and issue the equipment are raised in our helpdesk software via an API call, in the case of a denial a notification is sent back to the hiring manager informing them.  The ELT rep can send a comment to note their specific objection and the hiring manager can refill the form and try again.

Some items are handled by different teams (i.e. IP phone provisioning is handled by a different team than PC provisioning) and thus get separate tickets.  Tickets are automatically assigned to the appropriate person / team.

Fig 2 - The Equipment Request Form

The Account Creation Script

The account creation script is a web form used by IT to actually provision accounts.

It performs the following functions via API calls, VBscript and/or PowerShell scripts:
  • Creates an Active Directory account, adds employee to appropriate security groups, adds login scripts, etc.  The AD user is automatically created in the correct OU based on the new employee's department.
  • Sets e-mail addresses
  • Syncs the new user account to Office 365 / Azure AD - assigns an Office 365 user license, creates e-mail box, adds user to selected distribution lists
  • Creates a user account in our Freeradius server (used for VPN MFA via Google Authenticator)
  • Creates a user account and assigns a license on our Box.com SaaS subscription
  • Assigns a fax number to the new employee in our fax server software
  • Provisions a user account in our CenturyLink reservationless audio conferencing system via API call
  • Sends a "welcome aboard" e-mail to the new employee with a copy of our "New Hire IT Guide" document, which serves as a quick reference for IT information.
The Termination Form

HR has a web app where they can enter terminations in to the system.  Since this is a very basic form that only captures a limited amount of information I've omitted a screenshot.  

The HR form collects the following information:
  • Employee to terminate
  • Date / time termination should be effective
  • Manager that should fill out the termination form
Once HR submits the form, a link to the termination form is sent to the terminating manager so they can provide the required information to IT.

The termination form collects the following information:
  • What do we do with the employee's e-mail account?  Delete, auto reply, forwarding?
  • What do we do with the employee's cell phone and/or air card?  Disconnect the line?  Reassign it?
  • What do we do with the employee's computer?  Reclaim and add to inventory as a spare?  Leave it where it is for a replacement employee?  Sell it to the departing employee?
  • Who should be tasked with review of the terminated employee's computer files, e-mail, voicemail?
Once the form is filled out, relevant tickets are raised in our helpdesk software via API call.

When we terminate an employee, we archive their PC files, e-mail (as a .PST) and voicemail.  We then upload this data to Amazon S3 and store it for 60 days.  We have a web form that IT uses to send the terminating manager links to this data and information on accessing it.  The form uses a standard template informing the manager that they have 60 days to review the data before it's deleted.  These notifications are frequently ignored and IT gets requests for employee data, so it's handy for us to be able to tell folks to reference the automated e-mail they received because that prevents us from needing to take on additional work or deal with people (lazy is good).

Fig 3 - The Termination Form

Scripts
There is a collection of scripts running as scheduled tasks.  They perform the following tasks:
  • Sends reminders for pending equipment requests
  • Sends reminders for pending equipment request approvals
  • Sends reminders for pending termination forms
All of the user-facing web forms implement strict JavaScript form validation to ensure data quality.

All in all, this is a collection of systems that have been developed over a period of 3-4 years.  They largely eliminate the need for ops to ever deal with a human being related to employee changes.  It ensures we have all the information we need in a centralized location.

The web components are all developed in classic ASP (that's just what I know, I haven't been a developer in 20 years).  Most of the scripts are in VBscript (same reason), though some needed to be done in PowerShell (i.e. interfacing with Office 365, etc).

I've considered genericizing it and open sourcing, and may do so at some point in the future when I have more time to devote to it.