Ask your BPM vendor to give you a demo of his/her Leave of Absence Request Process (he might call it a Vacation Request Process or Time Off Request Process, but it is all the same). This is the simplest process in the book, right? Think again. This relatively simple process can be very difficult for lots of so called “top” BPM vendors and is nearly impossible to do correctly for all of the electronic forms providers. Let’s figure out why.
Many vendors will show you a Leave of Absence Request Process which has a Leave Request Form which gets routed to a supervisor and the supervisor either approves or rejects the request. Seems simple. But is that really the way a Leave Absence Request works? No, not at all.
PROCESS MAP
Here is an image of a Leave of Absence Process that has been designed correctly:
Leave of Absence Request Process
This is generally what a Leave of Absence or Time off Request should look like. It is not as simple as just sending a form to your boss. He/She needs to be able to approve or reject the request. But notice that rejecting the request is not the same as killing it and putting it in the trash. A rejection normally needs to go back to the employee so that the employee can correct it, resubmit it, or do something else. The important point here is that this is a decision that should rest with the originator of the request. Think about how it would work with an old fashion paper paper request. If you take a request to your boss and he/she rejects it, does your boss take the request and crumple it up and throw it out? No, your boss will hand it back to you and give you a reason why it is being rejected. At this point, you can make your decision how to proceed. You could throw it out yourself or you could fix it and resubmit it.
Next comes a part of the process that almost everyone leaves out. Once you come back from your time off, the amount of time off you really took needs to be verified. What if you come back a day early? What if you come back a day late? How does the system know this? For this reason, there needs to be another step to “report the actual leave taken.” This then needs to be verified by the boss, and only then can the record be updated.
Now this begs the question about “updating the record.” Do you already have an HRM (Human Resources Management) system, or do you need your BPM system to manage this information. Larger companies will tend to have a separate HRM system, but smaller ones might not. In this case, it is nice if your BPM system allows you to create internal tables. In this way you can associate custom tables with your user tables and maintain leave data for each employee. Of course, you will also need to setup an auto scheduled process which will affect these tables. This process should automatically add additional days to each employee’s account based on their anniversary date. For example, if your policy is to add 2 weeks of vacation time to each employee after they have been with the company for 12 months, then this process needs to happen automatically and needs to automatically adjust the leave taken tables.
Finally, you will need to be sure that your leave tables have an audit log. At some point you will need to look at a record of events that affected this accounting of leave taken.
FORMS
With regards to the design of the workflow, let’s look at a sample initial form:
Leave of Absence Form
The important thing to note about this initial form is that the employee, time, date, employee’s boss, leave available, and leave already taken should all be auto-filled by the system.
APPROVAL AND MANAGEMENT VIA EMAIL
Another feature to ask about is email response/approvals. Management generally doesn’t want to spend time logging into more web based systems. So why not give them the ability to approve or reject a request directly from their within their email. Here is an example of the type of email they could receive for a leave request:
Email Leave of Absence Request Form
As you can see, even for a seemingly simple workflow such as a Leave of Absence Request, there are a number of things to consider in the design and implementation of the process. Failure to consider these issues will result in a system that is discarded within a few weeks and never really used by the company. This is a very common occurrence in the world of software, but one that can be avoided with good planning, testing, and implementation practices.
