Warum wir eine eigene Zeiterfassung gebaut haben

Zeiterfassung ist in kaum einem Betrieb beliebt. Sie muss trotzdem sein, weil Arbeitszeiten aufzuzeichnen sind und weil man bei Projektarbeit sonst nicht weiß, wohin die Stunden geflossen sind. Wir haben über Jahre mit fertigen Produkten gearbeitet und dabei gemerkt, dass jedes davon eine Vorstellung davon mitbringt, wie ein Arbeitstag auszusehen hat. Passt diese Vorstellung nicht zum eigenen Ablauf, dann tippt man jeden Tag ein paar Minuten gegen die Software an. Irgendwann haben wir aufgehört, das hinzunehmen, und eine eigene Zeiterfassung gebaut.

Was uns an den fertigen Lösungen gestört hat

Die meisten Produkte am Markt sind für einen bestimmten Betriebstyp gedacht. Für eine Agentur mit klaren Kundenprojekten, für eine Produktion mit Schichtmodell, für ein Büro mit Kommen und Gehen am Terminal. Sobald ein Betrieb mehrere dieser Muster gleichzeitig hat, wird es zäh. Bei uns sieht ein Tag typischerweise so aus: zwei Stunden Wartung bei einem Kunden vor Ort, dazwischen drei kurze Remote-Eingriffe von je zehn Minuten für drei verschiedene Auftraggeber, am Nachmittag Arbeit an einem Projekt, das über Monate läuft.

In einer starren Maske bedeutet das: sieben Einträge, jeder mit Datum, Uhrzeit, Kunde, Projekt, Tätigkeitsart, Beschreibung. Bei einem Zehn-Minuten-Eingriff braucht die Erfassung dann fast so lange wie die Arbeit selbst. Genau an diesem Punkt hören Mitarbeiter auf, sauber zu buchen, und schreiben stattdessen abends aus dem Gedächtnis. Was danach in der Auswertung steht, ist eine Schätzung, keine Aufzeichnung. Und eine Schätzung taugt weder für die Abrechnung noch für die Frage, ob ein Wartungsvertrag noch kostendeckend ist.

Warum wir trotzdem lange gezögert haben

Software selbst zu bauen ist keine Entscheidung, die man leichtfertig trifft. Eine Eigenentwicklung muss gewartet, gesichert, aktualisiert und dokumentiert werden, und das dauerhaft. Wer ein fertiges Produkt kauft, kauft auch mit, dass sich jemand anderer um Updates kümmert, um Schnittstellen zu Lohnverrechnungssystemen und um gesetzliche Änderungen. Diese Arbeit verschwindet nicht, sie wandert nur ins eigene Haus.

Den Ausschlag gab, dass wir den Aufwand ohnehin hatten, nur an der falschen Stelle. Excel-Listen daneben, Nachbearbeitung am Monatsende, Rückfragen bei Kollegen, was ein Eintrag bedeutet haben könnte. Rechnet man diese Stunden zusammen, verschiebt sich das Bild. Dazu kam, dass wir Server, Datenbanken und Backups ohnehin betreiben, weil das unser Tagesgeschäft ist. Der Schritt war für uns kleiner als für einen Betrieb, der dafür erst Infrastruktur aufbauen müsste.

Was eine eigene Zeiterfassung anders macht

Der größte Unterschied ist nicht eine einzelne Funktion, sondern was fehlt. Fertige Produkte müssen viele Branchen bedienen und tragen deshalb Felder, Module und Einstellungen mit, die im einzelnen Betrieb niemand braucht. Jedes dieser Felder ist ein Klick, eine Entscheidung, eine mögliche Fehleingabe. Wir haben konsequent weggelassen, was bei uns nie verwendet wird.

Übrig bleibt eine Erfassung, die sich an der tatsächlichen Arbeit orientiert statt an einem theoretischen Modell. Konkret heißt das unter anderem:

• Ein Eintrag entsteht in wenigen Sekunden, weil Kunde und Projekt aus den letzten Buchungen vorgeschlagen werden statt aus einer Liste mit hunderten Einträgen.
• Kurze Remote-Eingriffe lassen sich erfassen, ohne dass für jeden davon ein eigenes Projekt angelegt werden muss.
• Die Projektzeiterfassung und die reine Arbeitszeiterfassung laufen im selben Datenbestand, es gibt also keine zwei Systeme, die am Monatsende auseinanderlaufen.
• Auswertungen zeigen genau die Spalten, die für Rechnung und Nachkalkulation gebraucht werden, nicht dreißig, aus denen man sich die richtigen suchen muss.
• Fehlende oder offensichtlich falsche Buchungen fallen früh auf und nicht erst bei der Rechnungslegung drei Wochen später.

Wo die Daten liegen und wer sie sehen kann

Zeiterfassungsdaten sind Personendaten. Aus ihnen lässt sich ablesen, wann jemand gearbeitet hat, wie lange, woran und in welchem Rhythmus. Bei Cloud-Produkten großer Anbieter liegt dieser Bestand auf fremder Infrastruktur, oft mit Unterauftragsverarbeitern in mehreren Ländern. Das ist nicht automatisch ein Problem, aber es ist eine Frage, die ein Geschäftsführer beantworten können sollte, wenn der Betriebsrat oder die Datenschutzbehörde fragt.

Wir haben easy4time auf eigenen Servern in Wien laufen, in derselben Umgebung, in der auch unsere übrigen Dienste liegen. Das hat einen unspektakulären, aber praktischen Vorteil: Backup, Zugriffsrechte und Protokollierung folgen denselben Regeln wie beim Rest, und wir müssen nicht für ein einzelnes Werkzeug eine Sonderlocke pflegen. Wenn jemand wissen will, wer wann welche Auswertung gezogen hat, ist das nachvollziehbar.

Anpassungen in Tagen statt in Wochen

Der Punkt, den wir vorher unterschätzt haben, ist die Reaktionszeit. Bei einem fertigen Produkt ist ein Änderungswunsch ein Ticket. Es wird bewertet, priorisiert, vielleicht in ein Release aufgenommen, vielleicht auch nicht, weil nur ein Kunde von tausend danach fragt. Bis dahin arbeitet der Betrieb weiter mit dem Zustand, der nicht passt, und baut Behelfslösungen drumherum.

Bei einer Eigenentwicklung ist derselbe Wunsch eine Frage von Tagen. Das klingt nach einer Kleinigkeit, verändert aber, wie im Betrieb über Software gesprochen wird. Wenn Änderungen realistisch sind, melden Mitarbeiter auch, was sie stört. Typische Anlässe aus unserer Praxis:

• Ein neuer Vertragstyp braucht eine andere Zuordnung von Stunden, damit die Abrechnung stimmt.
• Eine Auswertung wird für die Steuerberatung in einem bestimmten Format gebraucht.
• Eine Eingabemaske hat ein Feld, das regelmäßig falsch befüllt wird, und wird umgebaut.
• Ein gesetzlicher oder kollektivvertraglicher Punkt ändert sich und muss abgebildet werden.

Für wen sich das rechnet und für wen nicht

Eine Eigenentwicklung ist nicht für jeden Betrieb die richtige Antwort. Wer einen klassischen Ablauf hat, also feste Arbeitszeiten, wenige Projekte, klare Zuordnung, ist mit einem Standardprodukt meist schneller und günstiger unterwegs. Die Rechnung dreht sich erst, wenn der eigene Ablauf vom Standard abweicht und diese Abweichung jeden Tag Zeit kostet. Ein guter Prüfpunkt ist die Frage, wie viel Nacharbeit nach dem Monatsletzten anfällt, bevor die Zahlen verwendbar sind.

Uns hat das Projekt vor allem gezeigt, wie viel Reibung wir vorher für normal gehalten haben. Was easy4time kann, wie es aufgebaut ist und wie eine Einführung abläuft, steht auf der Seite zu unserer Zeiterfassung easy4time. Wir setzen sie selbst täglich ein, was den angenehmen Nebeneffekt hat, dass jeder Fehler zuerst uns trifft und nicht dem Kunden auffällt.

Fazit

Eine eigene Zeiterfassung war für uns keine Grundsatzentscheidung gegen fertige Produkte, sondern die Folge einer nüchternen Beobachtung: Die tägliche Reibung war größer als der Aufwand, sie abzustellen. Entscheidend ist dabei nicht, ob eine Software viele Funktionen hat, sondern ob die wenigen, die täglich gebraucht werden, ohne Umwege erreichbar sind. Wo das nicht der Fall ist, sinkt die Erfassungsdisziplin, und dann sind die Zahlen am Monatsende nur noch grobe Anhaltspunkte. Wer seine Projekte nachkalkulieren oder Wartungsverträge sauber bewerten will, braucht aber Aufzeichnungen und keine Erinnerungen. Ob man dafür ein Standardprodukt anpasst oder selbst baut, ist zweitrangig, solange am Ende niemand mehr gegen die Maske arbeitet.