The human resources department was using Word documents, circulated
via e-mail, as the means for managers to place all types of requests.
The process provided no real controls, no way to track requests,
and was generally confusing. For an organization with thousands
of payroll employees, this was unacceptable. We needed a systematic
way to handle the transactions between staff and managers and the
The first step was an analysis of all HR transactions to determine
which ones required a piece of paper. This revealed that requests
placed directly by staff, with one exception, require
a physical signature on a piece of paper. An on-line request
process is irrelevant for these requests.
The best solution was to put all the printable forms onto one, easy-to-use
intranet page for employees (shown below). Each of the printable
forms has an "info" button, displaying the purpose of
the document in a "mouse-over."
the image above to see the full size image]
and contact information updates
are the only direct staff transaction with HR which do not require
a physical signature. We built a very simple process to collect
these updates. The first step is verifying the identity of the person
being updated, which is done by matching Social Security number
against payroll records (shown below).
current address and contact information,
as stored in the Meditech payroll module, is then displayed for
editing. The employee edits and submits updated information in a
single step (shown below).
Most HR transactions can be grouped into two categories: current
employees and prospective employees:
current employees, all HR requests
are for a modification of some information about that employee.
new employees, there is a clearly-defined
process for posting a position and recruiting candidates.
this, we designed a relatively simple initial screen for managers
(shown below), which gets them started down the right path for an
first step in changing information about a current employee is selecting
the correct employee (shown below). This is accomplished
with the "standard" intranet worker search (a common module
used by all intranet applications). In this case, results are limited
to payroll employees.
found the correct employee, the manager selects the type
of transaction for that employee. Any combination of requests
may be selected (shown below). If multiple types of transactions
are selected, the different requests are processed sequentially
in a single transation. Address and phone changes use the same screens
shown above for staff requests.
first step in modifying the current position for an employee is
selecting the position to be modified.
All positions (primary and secondary) held by the employee are displayed
in a picklist (shown below).
guidelines for modifying an employee
position may be displayed or hidden, at the user's discretion (shown
relevant information about the selected
position is displayed for the requestor (shown below). Because it
is impossible to anticipate every possible variation in requests,
we left the form more or less open-ended, with text boxes where
the manager could describe the desired change(s), and category checkboxes
at the bottom. This design provides a workable balance between flexibility
request must be approved
by a senior manager and by a finance department budget analyst.
The requestor must decide whether additional approvals are needed
and the identity of any approver. (It is impossible to predict every
scenario, so a flexible process works best.) Since some departments
have a financial analyst or business manager who needs to be aware
of any changes with a financial impact, there is a provision to
send a copy of the transaction to anyone selected (shown below).
a confirmation screen summarizes the
transaction for the requestor (shown below).
Teaching hospitals, busy with research grants, have a high percentage
of employees with multiple part time positions. Adding
a secondary position is is a two-step process, with the first
step the selection of the department with the secondary job (shown
a list of all positions in the department
is displayed for selection (shown below). The approval process is
the same for each type of request, as shown above for status changes.
Any manager can initiate the transfer of any employee from
the manager's department or to the manager's department. The first
step is to select the employee to be transferred.
If the employee is not currently supervised by the requesting manager,
a different screen is displayed with fewer options and some alerts
the requestor selects the current position
from which the employee will transfer (shown below).
the manager selects the department
into which the employee will be transferred (shown below). The list
of departments is limited to those where the requestor is the responsible
manager or currently supervises employees (at any level).
the requestor selects a vacant position
(only vacant positions are displayed) in that department (shown
there is a confirmation screen showing
the full details of the transfer (shown below).
Leave requests are an easy, two-step process. First the basic
details are provided (shown below).
a confirmation screen summarizes the
request (shown below).
Since an employee may have multiple positions, the first step is
to select the position from which the
employee is being terminated (shown below).
the details of the termination are
input (shown below).
approvers and reviewers are identified
the termination details are confirmed
Recruitment is handled with a hosted application, originally called
Webhire, now Kenexa Recruiter®.
who wish to post a position use the form below to provide the
on-line approval process is similar to that shown above for modifying
an employee position, with additional approval steps.
approved, the posting is loaded into Kenexa Recruiter by an automated
process, and HR proceeds with recruitment.
Requests has worked well for everyone. It provides an efficient
process for approvals, clear communication with HR, and easy tracking
initially thought we should have managers select the category
of request, so requests could automatically be routed to the correct
person in HR. We quickly realized that managers cannot be expected
to understand the nuances of HR internal processes. We send all
requests to a single "bucket" for HR to triage and redirect
to the appropriate person.
a position was, for several years, a two-part process. Managers
first completed the intranet request to post, and then had to
input the same information into Webhire/Kenexa Recruiter. This
was frustrating, and recently we were able to automate the process
of loading the posting into Kenexa Recruiter. We probably should
have done this initially, but at the time it did not seem feasible.
approvals on-line is a "double-edged sword." It is very
efficient, but if the approval process is complicated and changes
regularly, it can become a time sink for the developer. This has
been a problem with HR Requests. If there's a good solution for
this, I'd love to hear it!
Posted 6 August 2008