A SIR web based leave/absence management system.

1. A SIR web based leave/absence management system. By Dave Doulton University of Southampton

2. Agenda • Introduction • What used to happen • The initial SIR System • Give the users what they want. • The current SIR system • Conclusion

3. Introduction • This paper covers the development of a SIR web based leave/absence system for the Information Systems Services department of the University of Southampton. • This is an interim solution before a University wide system is brought in.

4. Introduction • The original paper based system which has been running to my knowledge for 26 years was beginning to cause problems for one and all due to the time the paper took to circulate the several buildings we now occupy. • The first suggestion for automation struck me as so bad I would try and come up with something quickly (in 2 days in fact) that would improve matters. • Unfortunately my system was popular and I have spent a considerable amount of time since making changes to add functionality.

5. Introduction What is a leave/absence system? • It is a system for recording when people have their annual leave. • It also records absence for other reasons e.g. Sickness, Conferences, Doctors appointments etc. • It also records who gave permission for the absence.

6. Introduction What do we need to record? • Whose leave it is. • When it is. • What sort it is. • Who authorised it and when. • How much leave is left.

7. What used to happen? • Sheets of paper of different colours were used. • Pink to book leave • Yellow to Cancel leave • Blue to book time of in lieu • White for conference/training etc

9. What used to happen? • The paper was filled in with the dates. • It was posted to the persons line manager. • The line manager approved or denied it based on their knowledge (or otherwise) of other peoples absence. • The form was then posted to the admin office for processing, which involved filing the top half of the form and returning the bottom half in the post to the user after noting on it how much leave was left. • The person would then enter this into their Outlook calendar so that meetings were not booked with them in their absence. • The admin office emailed a list of who was absent to a mailing list of the interested once a day.

10. What used to happen? • The problems were? • It took too long for the paper to circulate. If you want tomorrow afternoon off the paper saying it was granted could take several days if not weeks to return. e.g. your line manager has just gone on2 weeks leave.

11. What used to happen? • People going off sick after the email had been sent were not known by anyone, but admin, to be absent. • If you did not usually receive the email you had no way of knowing who was off sick. • Booking leave from the next leave year caused all sorts of problems with how many days you had left.

12. The initial SIR System • Web based using sirweb.cgi • Is multi-user but does not use master. • As all writes are quick each action tries to attach the database in write mode and waits if this fails for up to 30seconds.

13. The initial SIR System • It is a case based database with the day as the case id. • The cases for the next 2 years are set up for all working days. i.e. weekends, public holidays and University Closure days are not present. • All case access is old case is or process cases so the calendar is fixed and new dates cannot be created.

14. The initial SIR System • Bookings consist of a record for each person for each half day of the leave • These hold the half day, the person’s username, who authorised it ,what type of leave it is and when it was booked.

15. The initial SIR System • This was a web based system using email. • It contained 3 tables • One holding the users entitlement to leave • One holding requests for leave • One holding the absences

16. The initial SIR System • A web form controlled by username and password allowed the user to • choose whether they wanted to book or cancel. • choose the type of leave. • type in the dates. • choose whole or half days only. • choose who was to authorise the leave.

17. The initial SIR System • Submitting the form entered the details in the request record. • Displayed the request to the user. • Emailed the line manager a link to the form that displayed the request for approval or rejection. • The result of this was emailed to the user.

18. The initial SIR System • There were reporting options to show full details of what leave had been booked for any period. • Most importantly how many days leave were left. • It was all based on user id’s

19. Give the users what they want. • As soon as it went live the requests and suggestions started pouring in. • They still do. • The following are the changes that I remember in no particular order.

20. Give the users what they want. From ordinary users. • Can we have a calendar to choose the dates we want rather than having to type in dates (because we cannot type dates correctly) • Don’t show other people the number of days I have had off sick. • Don’t tell others that I am on Compassionate leave.

21. Give the users what they want. • Let me confirm my request instead of sending straight to the line manager (because I make mistakes) • On the confirmation tell me if my line manager is going on leave soon so I can choose a different manager.

22. Give the users what they want. • Show me my outstanding requests. • Include outstanding requests in totals of days left when booking leave. • On the list of leave I have taken put a cancel button next to leave in the future so that it can be cancelled without filling in all the information again. • Attach a calendar event to the email so I can easily record the leave in my Outlook Calendar.

23. Give the users what they want. From Managers. • Show me who on my staff is off from a given date. • Group my staff on the display of who is off. • Show me who on my staff is off around the dates requests are being made.

24. Give the users what they want. • Show me the outstanding requests I have still to process with a link to call up the request form. • Let me forward a request to another manager if they are more appropriate or I have been chosen in error.

25. Give the users what they want. For Admin Staff. • Send out a list daily of who is absent to a list of managers and other interested parties. • Automatically carry sick over to the next working day. • Remind me of people who are part-time. • Report quarterly on how much sick leave a person has had and in how many occurrences with totals for the year.

26. Give the users what they want. • Add an optional information field. • Can we have real names not userids. • Can we amend peoples starting entitlement and carry over. • For salaried staff include non-working days (i.e. weekends) in the count of days off sick. • Handle part-timers leave/absence correctly!!!

27. The current SIR system • The system now comprises. • The three original records with some extra fields added. • Plus a record detailing who a manager is interested in and in which group they fall. • A second database (MUD Master User Database) is attached to get real names. • An included file containing a recode to mark the few parttime staff.

31. The current SIR system • Most of the requests have been implemented. • Handling of Part-timers correctly is still in progress and may never be fully satisfactory in the case of one person.

32. Conclusion • The system has been working for 5 months so far. • It has taken quite a lot of time to develop. • Especially with things like the calendar using Javascript. Different browsers treat dates in different ways. Some including the browser I was using report this year as 2005 whilst others report it as 105.

33. Conclusion • Things that seem simple can get very complicated and users want everything just the way they want it. • Demonstration.