Internes ERP für die Teamsteuerung

Gebraucht wurde ein System, in dem ein Antrag nur einmal erfasst wird – und Kalender, Urlaubsstand und Betrag in der Abrechnung automatisch aktualisiert werden und in der Historie erhalten bleiben. Ein Unternehmen mit 30+ Mitarbeitenden passte nicht mehr in Chats und Tabellen: Die Prozesse existierten, waren aber nirgends dokumentiert. Die Regeln steckten im Kopf der HR-Managerin, die Daten lagen an fünf unverbundenen Stellen.

• Urlaubs- und Freistellungsanträge kamen als private Nachrichten. Eine Woche später konnten weder Führungskraft noch Mitarbeiter rekonstruieren, was vereinbart war.
• Der Urlaubsstand wurde von Hand gezählt. Beim Ausscheiden wurde daraus regelmäßig ein Streitfall.
• Stunden aus den Trackern wurden per Copy-and-paste in eine Tabelle übertragen — ein bis zwei Arbeitstage im Monat und dazu Übertragungsfehler.
• Die Lohnabrechnung entstand in einer Tabelle: ohne Änderungshistorie, mit Formeln, die bei Einstellung oder Austritt mitten im Monat zerbrachen.
• Feiertage, Krankheit und Überstunden wurden aus dem Gedächtnis geführt. Der Zugriff auf Auszahlungsdaten beruhte auf Vertrauen.

So ein Aufbau trägt bis zum ersten Streit über die Abfindung, bis zu einem Auszahlungsfehler, der ein Quartal später auffällt, und bis zum Urlaub der HR-Managerin selbst — dann zeigt sich, dass niemand mehr den Monat abschließen kann.

Das Team musste keinen einzigen Tag geschult werden. Die Mitarbeitenden arbeiten ohnehin in einem Messenger, der bereits offen ist: Ein Antrag dauert eine halbe Minute, Login und Anleitung entfallen. Die Führungskraft genehmigt mit einem Klick direkt aus der Benachrichtigung heraus. Die Oberfläche müssen nur HR und Administratoren kennenlernen – also diejenigen, die ohnehin täglich im Panel arbeiten.

Das Herzstück der Architektur ist die fehlende Doppelerfassung. Eine einzige Genehmigung aktualisiert Teamkalender, Lohnabrechnung und Urlaubsstand von selbst, und die Antwort erreicht die Mitarbeiterin in demselben Chat, in dem sie gefragt hat.

Im System stecken Personal und Teamstruktur, Abwesenheiten, Urlaubsstand, Arbeitszeiterfassung und Lohnberechnung. Jeder dieser Bereiche bekommt weiter unten einen eigenen Abschnitt.

Der Urlaubsstand wird als Bewegungsjournal geführt, so wie es die Buchhaltung tut. Jede Änderung des Standes ist ein eigener Eintrag mit Datum, Quelle und Urheber. Früher lag der Stand als einzelnes Feld in der Mitarbeiterkarte und wurde nirgends berechnet. Den Stand als einzelne Zahl zu halten, ist eine typische Architekturfalle von B2B-Systemen: ein Streit beim Ausscheiden verlangt die Historie, nicht eine Zahl. Die Basisnorm liegt bei 28 Kalendertagen.

• Der Anspruch — ein Zwölftel des Jahreskontingents für jeden vergangenen Monat. Die Berechnung läuft jeweils am Ersten des Monats. Nur im Eintrittsjahr wird der Anspruch tagesgenau anteilig berechnet; Abwesenheiten mindern den Anspruch nicht. Naives Runden ergäbe im Jahr 27,96 statt 28, deshalb bucht der Monat die Differenz der kumulierten gerundeten Werte: die Jahressumme entspricht dem Kontingent exakt.
• Der Abzug läuft nach FIFO. Die Regel ist zugunsten der Mitarbeitenden gewählt: Zuerst werden die ältesten Tage verbraucht, deshalb geht der übertragene Rest vor dem frischen Anspruch weg und weniger verfällt.
• Übertrag und Verfall — eigene Journaleinträge: ein nicht genutzter Rest wird für ein Jahr übertragen und verfällt danach, einmal jährlich nach Zeitplan.
• Die Korrektur — ein Eintrag mit Pflichtkommentar und Urheber, zugänglich über eine eigene Berechtigung. Ins Minus geht der Stand nicht: die Prüfung sitzt sowohl im Formular als auch im Service.
• Urlaub über den Stand hinaus blockiert den Antrag nicht: die Tage werden in einen bezahlten und einen unbezahlten Teil geteilt — die bezahlten werden aus dem Journal abgezogen, die unbezahlten mindern die Basis ohne Ausgleich.

Eine Lohnabrechnung entsteht mit einer einzigen Aktion. Das System stellt die Abrechnung aus allen aktiven Mitarbeitenden zusammen, übernimmt die erfassten Stunden, genehmigten Abwesenheiten, Feiertage und wiederkehrenden Zuschläge – und berechnet jede Zeile.

Die Abrechnung durchläuft einen Zyklus: Zusammenstellen → Entwurf → genehmigt → ausgezahlt. Nach der Genehmigung sind die Beträge eingefroren: spätere Änderungen an Stunden oder Abwesenheiten verändern einen bereits abgeschlossenen Monat nicht mehr. Genau dafür baut man solche Systeme — Historie lässt sich nicht rückwirkend umschreiben.

Die Hauptfrage an jedes Lohnsystem lautet „woher kommt diese Zahl“. Hier beantwortet sie das System selbst: jede Zeile klappt bis zur Formel mit eingesetzten Zahlen auf — Basis für gearbeitete Tage, Feiertagsausgleich, Zuschläge, Produktivitätskoeffizient, Minderungsfaktor, Bruttosumme und Auszahlungsbetrag.

Die vollständige Berechnung kann den Mitarbeitenden geöffnet werden. Dieselbe Berechnung geht als PDF an die Buchhaltung.

Das System markiert selbst die Zeilen, die man nicht ungeprüft abschließen darf: null Stunden bei einer Person auf Stundenbasis, eine nicht genehmigte Freistellung im Zeitraum, ein fehlender Wechselkurs, eine feste Zahlung trotz Abwesenheiten. Jede Markierung erklärt, was genau nicht stimmt und wie es sich auf den Betrag ausgewirkt hat.

Fehler stehen im Entwurf, vor dem Abschluss des Zeitraums. Das ist um eine Größenordnung günstiger.

Eine Führungskraft braucht den vollständigen Überblick über einen konkreten Mitarbeitenden. Auf einer Seite stehen die durchschnittlichen Stunden pro Tag, die gesamte Arbeitszeit, der Aktivitätsanteil, Urlaubstage, Krankheitstage und Freistellungen, der Produktivitätsindex, die geltenden Zuschläge und ihre Auswirkungen auf die Lohnsumme sowie der Verlauf der Arbeitszeit und die Auszahlungshistorie.

Gesondert ein Zähler der Tage bis zum Vertragsende: für die Suche nach Ersatz bleibt Zeit.

Die tatsächliche Entwicklungszeit liegt bei etwa 80 Personenstunden. Das sind rund zwei Arbeitswochen eines Entwicklers: darin stecken Personal und Abwesenheiten, Arbeitszeiterfassung, Lohnberechnung, Integrationen und der Urlaubsstand.

Die aktive Phase waren April und Mai: etwa 60 Stunden, drei Viertel der gesamten Zeit. In dieser Phase entstand alles, was mit der Lohnberechnung zu tun hat: der Kern der Berechnung, die Vergütungsregeln, die zweite Stundenquelle und die externen Integrationen. Davor rund 20 Stunden für Gerüst, Personal, Rechte, API und Zeiterfassung: am 25. April 2026 erschienen im Panel echte Benutzerkonten, und das Unternehmen führte sein Personal nicht mehr in Tabellen. Danach gezielte Ergänzungen an einem bereits laufenden Produkt.

Die Zahlen stammen aus der Repository-Historie: Commits sind über die Abstände zwischen ihnen zu Arbeitssitzungen gruppiert, die Stunden sind also eine Untergrenze und kein Export aus einem Zeittracker.

Die Module kamen an, sobald sie fertig waren, nicht als ein Release am Ende. Die gemergten Pull Requests fielen auf April, Mai und Juli, und die Auslieferung auf dem Hauptbranch wurde jedes Mal von Hand gestartet. So lässt sich arbeiten, wenn der Rücksprung auf die vorige Version einen Befehl kostet und auf jedem Branch eine Pipeline aus Stil → Analyse → Tests läuft, drei Schritte parallel.

Zum Start bekam das Team keinen Rohbau, sondern einen arbeitsfähigen Kreislauf — Personal, Abwesenheiten und Zeiterfassung, — und nutzte ihn, während Vergütungsregeln, Integrationen und Urlaubsstand noch geschrieben wurden. Für uns die übliche Reihenfolge: zuerst das, was man morgen benutzen kann, dann das, was Geld rechnet. Auf „wenn alles fertig ist“ musste niemand einen Tag warten.

Das System amortisiert sich durch eingesparte Arbeitszeit und vermiedene Fehler – bevor sie überhaupt auf der Abrechnung landen. Die Stunden sind leicht zu zählen: unten steht die Arbeit, die früher jeden Monat manuel erledigt wurde, und was davon übrig ist. Fehler sind schwerer zu beziffern, doch eine einzige Unterzahlung, die ein Quartal später auftaucht, kostet mehr als ein ganzer eingesparter Monat.

Was das System in einem Jahr und in zwei Jahren bringt. Jeden Monat gibt es HR und Buchhaltung zwei bis vier volle Arbeitstage zurück. Im Jahr summiert sich das auf 24–52 Arbeitstage, in zwei Jahren auf 48 bis 105. Die gesamte Entwicklung samt Integrationen, Urlaubsjournal und Routing der Benachrichtigungen brauchte etwa 80 Personenstunden — rund zehn Arbeitstage —, deshalb kommt die investierte Zeit in den ersten drei bis fünf Monaten des Betriebs zurück, und danach ist es reiner Gewinn.

Die zwanzig Stunden, die das System bis zum Start gebracht haben, waren schon im ersten Monat wieder drin. Danach summiert sich die Wirkung nur: das System gibt weiterhin dieselben zwei bis vier Tage monatlich zurück, solange das Unternehmen es nutzt. Gerechnet wird in Zeit, deshalb lassen sich die Zahlen auf jedes Unternehmen übertragen: Sätze einsetzen, Betrag ablesen.

Am teuersten ist die Last, die im Kopf bleibt. Den aktuellen Stand im Blick behalten, wissen, wem man schreiben muss, wissen, was vor der Auszahlung zu prüfen ist – all das kostet Aufmerksamkeit, auch wenn man gerade mit etwas anderem beschäftigt ist. Das System nimmt diese Last ab.

Drei Kniffe, mit denen das gelingt:

• Das System entscheidet für den Menschen alles, was es selbst entscheiden kann. Arbeitstage, Feiertage im Land der jeweiligen Person und der Währungskurs werden automatisch eingesetzt. Gefragt wird nur, was wirklich eine menschliche Entscheidung verlangt.
• Der Hinweis kommt im Moment der Entscheidung. Tagesstand und Überschneidungen mit Urlauben der Kolleginnen und Kollegen stehen direkt im Antrag, dort, wo entschieden wird. Man muss sie nicht in einem eigenen Bericht suchen.
• Fehler fängt das System ab. Null Stunden bei Stundenbasis, eine nicht genehmigte Freistellung, ein fehlender Kurs — all das ist im Entwurf markiert. Eine Prüfliste vor dem Monatsabschluss muss niemand im Kopf haben.

Ein internes System lebt Jahre und überdauert mehrere Besetzungen des Teams. Verlässlichkeit misst sich hier deshalb an einem: Lässt sich in zwei Jahren eine Berechnungsregel gefahrlos ändern, ohne abgeschlossene Zeiträume zu zerstören. Unten stehen sechs Stützen, jede davon im Code überprüfbar.