Urlaubsverwaltung – was hat sich getan?
Lang, lang ist es her seit dem ersten Blog Post über die synyx’sche Urlaubsverwaltung.
Und inzwischen?
Es hat sich einiges getan. Seit März dieses Jahres wird die Urlaubsverwaltung produktiv eingesetzt. In der Testphase war das Prozedere zunächst einmal immer auf doppeltem Wege Urlaub zu beantragen – also sowohl schriftlich, als auch elektronisch. Inzwischen sind die schriftlichen Anträge glücklicherweise verschwunden, die Beantragung und Genehmigung von Urlaub erfolgt nun ausschließlich elektronisch.
Elektronischer Urlaubsantrag
Was ist sonst so passiert?
Durch das sehr umständliche Formular zum Editieren von Mitarbeitern und deren Urlaubsanspruch kam es leider zu Missverständnissen und somit immer wieder zu Verwirrungen bei den Mitarbeitern bzgl. ihres tatsächlichen Urlaubsanspruchs. In einem einwöchigen Sprint im September beschloss ich also, ein größeres Refactoring vorzunehmen, um solche Probleme ein für alle Mal aus der Welt der Urlaubsverwaltung zu schaffen.
Mitarbeiter haben nun keine Urlaubskonten mehr, sondern nur noch Urlaubsanspruch pro Jahr. (vgl. ER-Diagramm im alten Blog Post) Wieviele Urlaubstage ein Mitarbeiter noch besitzt und ob er einen weiteren Urlaubsantrag stellen darf, wird nun quasi on the fly berechnet – anhand Urlaubsanspruch pro Jahr und Anzahl der bereits genutzten Urlaubstage dieses Jahres. Diese Information wird nicht mehr als Urlaubskonto in der Datenbank vorgehalten. Dies hat den Vorteil, dass der Code sehr vereinfacht wird, da bspw. keine Rollback-Methoden mehr notwendig sind.
Das Formular zum Editieren von Mitarbeitern hat durch das Refactoring sogar ein Zusatzfeature gewonnen. Urlaubsanspruch vergibt man nun nicht mehr für ein Jahr, sondern für einen Zeitraum. Dies hat den Vorteil, dass der tatsächliche Urlaubsanspruch für neue Mitarbeiter nicht mehr manuell berechnet werden muss, sondern durch die Anwendung erfolgt. Man gibt nur noch den Urlaubsanspruch für ein Jahr an (z.B. 28 Tage) und den Zeitraum (z.B. 01.10.2012 – 31.12.2012) und erhält dann den tatsächlichen Urlaubsanspruch. (in diesem Beispiel 7 Tage)
Editieren eines Mitarbeiters (vor dem Refactoring)
Editieren eines Mitarbeiters (nach dem Refactoring)
Auch die Detailansicht für den einzelnen Mitarbeiter hat sich verändert.
Persönliche Übersicht (vor dem Refactoring)
Persönliche Übersicht (nach dem Refactoring)
Wie man vielleicht erkennen kann, habe ich im Zuge des Refactorings Bootstrap eingebunden. Dieses Front-End Framework habe ich in einem Kundenprojekt kennenlernen dürfen und Gefallen daran gefunden.
Was soll in naher Zukunft geschehen?
Neben diversen Bugfixes stehen noch einige wichtige Features aus.
Sehr wichtig ist es, endlich die Anbindung zum Google-Kalender zu realisieren, damit die Urlaubstage von Mitarbeitern nicht mehr händisch im synyx Kalender ein- bzw. ausgetragen werden müssen, sondern dies automatisch über die Anwendung erfolgt, sobald ein Urlaubsantrag genehmigt bzw. storniert wurde. Dieses Feature birgt nicht nur den Vorteil, dass Arbeitszeit gespart wird, sondern auch dass Eintragungsfehler vermieden werden.
Bisher immer wieder nach hinten geschoben, nähert sich nun doch rasant die Notwendigkeit der Berechnung von Resturlaubstagen zum Jahreswechsel. Per Cronjob soll zum 1. Januar eines jeden Jahres eine Methode ausgeführt werden, die berechnet, wieviele Resturlaubstage ein Mitarbeiter ins neue Jahr mitnimmt.
Das Drucken von Urlaubsanträgen ist momentan realisiert durch ein simples window.print();
und einigen Zeilen CSS für die angepasste Druckausgabe. Für die Zukunft soll allerdings eine PDF-Generierung gerade unserer Office-Managerin Rebecca das Leben erleichtern. Liegt ein neuer genehmigter Urlaubsantrag vor, erhält sie eine Email mit dem Link zum Antrag, um diesen drucken zu können. Dieser Schritt erübrigt sich, sobald die Möglichkeit besteht, Urlaubsanträge als PDF zu erzeugen und dieses PDF in eben jene Informations-Email anzuhängen.
Momentan wird davon ausgegangen, dass jeder Mitarbeiter fünf Tage die Woche arbeitet, nämlich Montag bis Freitag. Bei der Berechnung wieviele Urlaubstage für einen angegebenen Zeitraum abgezogen werden müssen, werden immer Samstag und Sonntag als Nicht-Werktage gewertet.
Es soll jedoch irgendwann möglich sein, für jeden Mitarbeiter anzugeben, welche Tage Nicht-Werktage sind. Dies ist bspw. für unsere Kochmuddi relevant, die eben nicht fünf Tage die Woche arbeitet und dafür aber samstags.
Bisher hat ausschließlich Rebecca die Office-Rolle in der Urlaubsverwaltung inne. Die Urlaubsverwaltung soll jedoch in naher Zukunft eine User-/Rechteverwaltung erhalten, damit z.B. Rebeccas Urlaubsvertretung die Office-Rolle übernehmen kann. Gleiches gilt für die Chef-Rolle zur Genehmigung bzw. Ablehnung von Urlaubsanträgen. Eventuell sollen die hierfür zuständigen Personen auch flexibel einstellbar sein.
Wohin soll die Urlaubsverwaltung langfristig gehen?
Langfristig steht die Idee im Raum, die Urlaubsverwaltung als allgemeine Mitarbeiterverwaltung auszubauen. Eine konkrete mögliche Erweiterung wäre die Verwaltung von Krankheitstagen. Dies würde eine bessere Übersicht und leichtere Verwaltung für das Office bedeuten, statt wie bisher nur über den Google-Kalender.
Doch das ist vorerst noch Zukunftsmusik…