Berichtsdatenbanksystem

zur Unterstützung der Personalwirtschaft

- Beispiel -

 

 

Ausgangssituation

Eingesetzt ist ein klassisches Personalabrechnungssystem (z.B. PAISY, IPAS oder SAP HR) auf einem Zentralrechner bzw. Server.

Das System soll durch die Mitarbeiterinnen und Mitarbeiter im Personalbereich an ihren Arbeitsstationen genutzt werden. Das Abrechnungssystem soll dabei auf die Durchführung der Abrechnung und der sie begleitenden Auswertungen begrenzt bleiben. Für weitere Auswertungen zur Unterstützung der Personalwirtschaft soll ein ergänzendes, PC-basiertes System eingesetzt werden.

 

Datenbankmodell

Drei typische Auswertungs-Anforderungen lassen sich feststellen:

Auswertungen können sich dabei sowohl auf einen Stichtag als auch auf einen Zeitabschnitt beziehen. Die Daten lassen sich unter diesem Gesichtspunkt in drei Gruppen einteilen:

 Die Datenbanktabellen sollten folgende Datenfelder enthalten:

Feste Stammdaten
DB-Tabelle Fixstamm
Variable Stammdaten
DB-Tabelle Varstamm
Personalnummer (Schlüsselfeld)
Anrede
Titel
Vorname
Länderkennzeichen
Postleitzahl
Wohnort
Straße und Hausnummer
Geschlecht
Familienstand
Geburtsdatum
Eintrittsdatum anrechenbar
Eintrittsdatum tatsächlich
Eintrittsgrund
Austrittsdatum

Austrittsgrund

Geburtsland

Staatsangehörigkeit

Anrechnungsgrund

Ausweisnummer

Schwerbehinderung Art

Urlaubsanspruch

Dienstort

Kinderzahl

Steuerklasse

Stundensatz

Religionszugehörigkeit
Schwerbehinderungsurlaubsanspruch
Altersfreizeitsanspruch
Datum Anspruch auf vermögenswirksame Leistungen
Kündigungsschutzgrund
Krankenkasse
Tätigkeit (nach Schlüssel Statist. Bundesamt)

zusätzlich die aktuellen Werte:
Abteilung
Kostenstelle
Abrechnungskreis
Abstimmkreis
Entlohnungsform
Einkommensgruppe
Sonderfunktion
Tarifgruppe
Teilzeitsatz
Freischichtanspruch
Personalnummer (Schlüsselfeld)
Jahr und Monat (Schlüsselfeld)
Werk
Abteilung
Kostenstelle
Abrechnungskreis
Abstimmkreis
Entlohnungsform
Einkommensgruppe
Sonderfunktion
Tarifgruppe
Teilzeit/Arbeitszeit-Prozentsatz
Freischichtanspruch

In der ersten Tabelle gibt es pro Personalnummer einen Datensatz, d.h. die Personalnummer ist das eindeutige Schlüsselfeld. Die Tabelle wird hauptsächlich für aktuelle ad-hoc-Abfragen benutzt.

In der zweiten Tabelle bilden Personalnummer-Jahr-Monat den eindeutigen Schlüssel, d.h. die Tabelle enthält pro Person und Monat je einen Datensatz. Diese Tabelle wird hauptsächlich für zeitraumbezogene Auswertungen benutzt. Sie berücksichtigt etwaige zwischenzeitliche Änderungen der in ihr enthaltenen Stammdaten (allerdings nicht, wenn es während eines laufenden Monats Änderungen gibt - die Änderungen beziehen sich immer auf den Abrechnungstag als Stichtag).

Nach den bisherigen Überlegungen werden die Stammdaten also in zwei Gruppen unterschieden:

Als Alternative zu diesem Verfahren käme auch eine Speicherung in Betracht, in der für jeden Stammdatensatz ein Gültigkeitsdatum gespeichert wird, etwa folgendermaßen:

Alternative Stammdatenspeicherung:
DB-Tabelle Personalstamm
Personalnummer
Gütig_Ab (Monat-Jahr)
Gültig_Bis (Monat-Jahr)
Titel
Anrede
Vorname
Name
.... usw wie FixStamm / VarStamm

Die Datenbanktabelle würde alle Daten enthalten, die in FixStamm und VarStamm vorkommen, jedoch die Angaben Gültig-Von und Gültig-Bis anstelle von Monat-Jahr in VarStamm. Gültig-Bis würde zunächst auf 12-9999 gesetzt. Erst im Falle einer Stammdatenänderung würde im alten Datensatz als Gültig-Bis-Datum der aktuelle Vormonat gesetzt und ein neuer Stammdatensatz angelegt, mit dem aktuellen Monat im Gültig-AB-Datenfeld und 12-9999 für Gültig-Bis. Diese Methode hat den Vorteil, daß neue Stammdaten nur bei tatsächlichen Veränderungen zu speichern sind. Sie hat aber den Nachteil, daß bei Verknüpfungen mit anderen Datenbanktabellen zuerst immer der gültige Datensatz herausgefunden werden muß. Dies kann Zugriffszeiten verlängern. Empfehlenswert wäre eine Entscheidung auf der Grundlage eines durchgeführten Testes mit Datenbanktabellen von charakteristischer Größe.

Aus jeder monatlichen Abrechnung werden als Bewegungsdaten pro Person und Monat die Bezugsarten für die Dauer des laufenden Jahres und Vorjahres gespeichert:

DB-Tabelle Monatsbezug
Personalnummer (Schlüsselfeld)
Jahr-Monat Wirksamkeit
Jahr-Monat Gültigkeit
Werk-Kostenstelle-Abstimmkreis-Entlohnungsform
Bezugsartenschlüssel
Stunden Bezugsart
Betrag Bezugsart

Eindeutiger Schlüssel ist in dieser Tabelle Personalnummer - Jahr - Monat-Wirksamkeit oder Personalnummer - Jahr - Monat-Gültigkeit, je nach Betrachtung. Die Unterscheidung zwischen Wirksam und Gültig ist wegen der durch Rückrechnungen ausgelösten Korrekturen erforderlich. Die Monatsbezeichnungen Wirksam und Gültig sind normalerweise identisch, können jedoch bei Rückrechnungen auseinanderfallen. Unter Gültig erhält man Auswertungen mit den "richtigen", d.h. durch die Rückrechnungen berichtigten Bezugsarten, unter Wirksam Auswertungen mit den tatsächlich erfolgten monatlichen Zahlungen, übereinstimmend mit Auswertungen aus der Finanz- oder Betriebsbuchhaltung. Die Informationen Werk-Kostenstelle-Abstimmkreis-Entlohnungsform werden bei jeder verbuchten Bezugsart mitgeführt, weil auch während eines laufenden Monats sich die Kostenstelle und die Entlohnungsform ändern können. Für spätere Auswertungen ist diese Berücksichtigung wichtig, denn bei einer Verknüpfung mit der Datenbanktabelle VarStamm hätte man nur die Information zu einem monatlichen Stichtag, und zwischenmonatliche Änderungen würden nicht berücksichtigt werden können.

Die Datenbanktabelle Monatsbezug enthält pro Person und Monat und Bezugsart einen Datensatz und soll die Daten für das laufende und abgeschlossene Jahr speichern.

Eine zweite Datenbank-Tabelle mit Bewegungsdaten enthält die Monatsergebnisse:

DB-Tabelle Monatsergebnis
Personalnummer (Schlüsselfeld)
Jahr-Monat Wirksamkeit
Jahr-Monat GültigkeitBruttoentgelt
Nettoentgelt
BG-pflichtiges Bruttoentgelt
KV-pflichtiges Bruttoentgelt
AV/RV-pflichtiges Bruttoentgelt
Pflegeversicherungspflichtiges Brutto
VWP-pflichtiges Brutto

Datenquelle für alle bisher beschriebenen Datenbanktabellen der neuen Berichtsdatenbank ist das derzeitige Abrechnungssystem.

Für bessere Übersichten empfehlen sich Auswertungen mit stark zusammengefaßten Bezugsarten, zum Beispiel:

Zusammenfassung der Bezugsarten
UEB1
VR01
VR02
VR03
VR04
VR05
VR06
VR07
VR08
VR09
VR10
VR11
VR12
VR13
VR14
VR15
VR16
VR17
VR18
VR19
VWL
Mehrarbeit
Regelarbeit ohne Provision
Bezahlte Pausen
Bezahlte Ausfallzeit
Handwerkerpauschale
NTZ-Pauschale
Vertreterpauschale
Kontoführungsgebühr
Jahresleistung
Urlaubsschnitt
Krankschnitt
Freischicht-Schnitt
PD-Prämie
Sonstige bezahlte Fehlzeiten
Antrittsgebühr
Nachtzuschlag
Feiertagszuschlag
Samstagszuschlag
Sonntagszuschlag
Ungünstiger Arbeitsbeginn
Vermögenswirksame Leistungen

Wegen der zu erwartenden höheren Häufigkeit von Auswertungen mit solchen zusammengefaßten Bezugsarten empfiehlt es sich, hierfür eine zweite Datenbanktabelle auch physikalisch zu speichern:

DB-Tabelle Monatsbezugsgruppen
Personalnummer (Schlüsselfeld)
Jahr-Monat Wirksamkeit
Jahr-Monat Gültigkeit
Werk-Kostenstelle-Abstimmkreis-Entlohnungsform
Bezugsartenschlüssel zusammengefaßt (nach obiger Tabelle)
Stunden zusammengefaßte Bezugsarten
Betrag zusammengefaßte Bezugsarten

Sollen auch Daten aus dem Zeitwirtschaftssystem ausgewertet werden, so verkompliziert sich die Lage. Bezüglich der geltenden Arbeitszeitregelungen sind oft eine Vielzahl von Bedingungen zu beachten wie z.B.:

  • Es darf nur an maximal sechs Tagen hintereinander gearbeitet werden. Nach sechs Tagen muß ein freier Tag folgen.

  • Innerhalb eines Monats müssen dreimal zwei zusammenhängende freie Tage gewährt werden.

  • Davon muß einmal im Monat ein freies Wochenende sein.

  • Zusätzlich zweimal im Monat muß ein Samstag oder Sonntag frei sein, wobei Tage nach Nachtschichten nicht mitzählen.

  • Überprüfung der Regelung, daß sonntags Arbeitende in der darauf folgenden Woche einen freien Tag nehmen müssen.

  • Überprüfung der Einhaltung des 54-Wochen-Arbeitszeitmodells.

  • Die über 26 Wochen ermittelte durchschnittliche Wochenarbeitszeit muß der tariflichen Wochenarbeitszeit von 35 Stunden entsprechen.

  • Wenn mehr als fünf Prozent der Beschäftigten &Mac179;80 Stunden Zeitguthaben aufweisen, muß eine Meldung erzeugt werden (Auslösen einer Verhandlungspflicht mit dem Betriebsrat).

  • Überprüfung, ob nicht mehr als 13 freie Samstage im Jahr als Überstunden gearbeitet wurde.

  • Überprüfung der Einhaltung einer maximalen Wochenarbeitszeit bei verschiedenen Beschäftigtengruppen (z.B. geringfügig Verdienenden).

  • Überprüfung des Unterschreitens von 28 Stunden beim Arbeitszeitsaldo am Ende eines Ausgleichszeitraums.

  • Überprüfung der Regelung, daß wer zwei Wochen lang täglich &Mac179; 8.5 Stunden arbeitet, drei Wochen lang nicht mehr als täglich 8.5 Stunden arbeiten darf.

Die Fragen machen deutlich, daß ihre Beantwortung nicht durch an einfache Bedingungen gekoppelte Feldauswahl aus Datenbanktabellen spontan möglich ist, sondern teilweise sehr komplexe Programme erfordert. Außerdem leistet ein Reporting ja nur die nachträgliche Überprüfung der Frage, ob die Arbeitszeitregelungen eingehalten wurden. Sinnvoller dagegen wäre es, rechtzeitig entsprechende Hinweise zu erhalten, damit Verletzungen der Arbeitszeitregelungen besser vermieden werden können. Dies aber würde voraussetzen, daß die Informationen dort in den Betrieben zur Verfügung stünden, wo die Entscheidungen getroffen werden, nämlich vor Ort, wo Arbeitnehmer und ihre Vorgesetzte die künftige Arbeitszeit planen.

Um dennoch einen Einstieg in die Thematik zu erreichen, kann der folgende Vorschlag realisiert werden, der zumindest bei einem Teil der denkbaren Fragestellungen für ad-hoc-Abfragen eine Lösung bieten kann:

DB-Tabelle Kontenstand
Personalnummer (Schlüsselfeld)
aktuelles Datum (oder Stichtagsdatum Monatsende bzw. Monatsanfang)
Stand Zeitkonto
Stand Freizeitkonto
Stand Urlaubskonto
Stand Resturlaubskonto (Vorjahr)
Stand Freischichtkonto
Anzahl der im Monat gearbeiteten Tage

 

Datenquelle für solche Auswertungen ist das Zeitwirtschaftssystem. Nur wenn diese Tabelle nicht nur für das aktuelle Tagesdatum für alle an der Zeitwirtschaft teilnehmenden Beschäftigten geführt wird, sondern wenn zusätzlich für jeden Monat des laufenden und abgeschlossenen Jahres die Kontostände zu einem Stichtag (Monatsende oder Abrechnungstag) festgehalten werden, ist die Entwicklung der verschiedenen Zeitkonten über einen längeren Zeitraum beobachtbar. Allerdings ist die Berücksichtigung von durch Rückrechnungen ausgelösten Korrekturen etwas aufwendig, da eventuell zurückliegende Kontenstände korrigiert werden müssen.

Die Architektur des Systems läßt sich nun wie folgt darstellen:

Abbildung 1 

Architektur des Berichtdatenbanksystems

Das Übernahmeprogramm der Daten für die neu zu schaffende Berichtsdatenbank aus dem Abrechnungs-System hat folgende Leistungen zu erbingen:

Alternative A bedeutet das Verfahren mit dem gesplitteten Personalstamm (Daten mit und ohne Interesse an zwischenzeitlichen Veränderungen), Alternative B das Anlegen eines Personalstamms mit zeitlichen Gültigkeitsangaben. Das Übernahmeprogramm kann bereits für das jetzt im Einsatz befindliche System erstellt werden. Beim Wechsel zum neuen System muß es möglicherweise angepaßt werden. Die Berichtsdatenbank bleibt durch die hier gewählte Konstruktion unabhängig vom Abrechnungssystem. Die in der Datenbank gespeicherten Daten können von jedwedem Abrechnungssystem geliefert werden. Lediglich das Übernahmeprogramm muß beim Wechsel des Abrechnungssystems angepaßt oder ausgetauscht werden.

Benutzersichten

Das Berichtssystem soll so arbeiten, daß kein Endbenutzer Zugriff auf die physischen Datenbanktabellen erhält, sondern nur über sog. Benutzersichten auf die Daten zugreifen kann. Bei der Konstruktion dieser Benutzersichten müssen die mit den Betriebsräten getroffenen Regelungen befolgt werden. Diese Regelungen könnten z.B. lauten:

Dabei wäre natürlich zu definieren, welche Bezugsarten als überwachungsgeeignet gelten, z.B. solche, die Fehlzeiten wie Krankheit, Kur, Wegeunfall und unentschuldigtes Fehlen beschreiben.

Zur Verfügung gestellte Benutzersichten könnten dann sein:

Diese Benutzersichten werden untereinander nicht mehr verknüpft und können dann für Abfragen und Auswertungen zur Verfügung gestellt werden.